The book Scenario-Focused Engineering describes a customer-centric lean and agile approach for developing and delivering software-based products. It provides ideas to understand customer needs based upon end-to-end experiences and for designing products in a customer-focused way using a fast feedback cycle.
You can download a sample of Scenario-Focused Engineering to get an impression of this book.
InfoQ interviewed the authors Austina De Bonte and Drew Fletcher about why end-to-end customer experiences are more important than features, blending scenario focused engineering with lean startup and agile approaches, using specific stories to frame situations, getting fast feedback, and using multiple prototypes, and adopting scenario focused engineering in organizations.
InfoQ: What made you decide to write this book about Scenario-Focused Engineering?
De Bonte: There are a lot of books out there about user-centered design, but most of them are written by designers for designers, and don't always make sense for engineers. This book is the "secret decoder ring" that explains the most essential concepts and techniques in user-centered design; in a way that makes sense to highly analytical thinkers. By teaching these topics to entire teams over five years at Microsoft, we learned how to explain the logic and the science behind these ideas, which is crucial for this audience, and believe that this is an important and unique contribution to share with the rest of the industry.
Fletcher: We were both very proud of the work we had done at Microsoft. We directly felt the impact SFE had with many teams at Microsoft. We saw how sharing a vocabulary and process around focusing on customers not only affected the products that were being built, but perhaps more importantly, changed the team’s culture to one of collaboration centered around the customer’s needs. If you’ve ever had the opportunity to work in an environment like that, you know what a rewarding experience it can be. We wanted to help others have that experience – to enable more teams in the world to have shared ownership of delivering outstanding products for customers.
InfoQ: In the book you explain the importance of end-to-end customer experiences. Can you give some examples of such experiences?
De Bonte: An end-to-end experience is another way of saying, "What real-world job is the customer trying to accomplish with your software?" Rather than looking at engineering in terms of features and functionality, you focus on start-to-finish usage scenarios. This allows the engineering team to stay focused on the customer's needs and expectations rather than on building islands of individual features that don't interrelate with each other.
A customer’s end-to-end experience may be short and straightforward, such as a parent reading a text message from a friend while standing in line at the grocery store, a developer writing a few lines of code to fix a bug, or an event planner sending an email to advertise a charity auction. An end-to-end experience can also have many moving parts and be quite complex, such as an event planner using a database, spreadsheets, email, online meetings, mobile phone, and word processor to organize and put on a charity auction event. Or a software developer on a project team who uses bug tracking tools, source control, API documentation, and a development environment to fix a bug, check it in, and mark it fixed. Or, consider a teenager who buys a piece of music online and wants to listen to it and the rest of his music library first on his phone, later on his laptop, and again in the evening as background music in his living room as he plays his favorite Xbox game.
But what most assuredly is not an end-to-end experience is someone changing the view of his or her Word document from Draft to Print Layout. Clicking the button to buy an app in the Apple AppStore is not an end-to-end experience either; the total purchase experience must include how that app will be discovered, chosen, and then made available to use on the customer's devices. Individual actions like these are too small in scope to capture the essence of a customer's real-life usage situation; they are a part of a larger customer scenario.
However, these examples do illustrate that you can consider potentially multiple scopes of the same experience. You can zoom out to see the larger, end-to-end job being done, or you can zoom in to focus on a specific end-to-end task—but be careful that you don't zoom in so far that you no longer see the customer's real-life situation, context, and motivations. The important step is to align your perspective with the way the customer perceives the task at hand. If the customer sees it all as one connected job—or really wishes it could be all connected—then you probably should be thinking about it that way also.
Fletcher: The key idea behind an end-to-end experience is that instead of focusing on getting a particular piece of technology to work, or focusing on delivering a specific set of features or requirements, that the team focuses on the real-world job the customer is trying to complete. I’ll give three examples here – each one at a progressively higher level of granularity.
As a first example, I can describe the end-to-end experience I’m having right this moment, as I write and format the answers to the questions posed in this interview. This experience probably includes a dozen or more features that I’m using to get the job done with my word processor. But, as a user I really don’t want to focus on, dwell on, or even be aware of all these features that I’m using (that I’m sure are backed by very sophisticated technology, coding, and algorithms). Instead, what I really care about is the end result – getting a document sent to InfoQ in a timely manner (that hopefully someone like you enjoys reading). I just want the word processor I’m using to work, and I want it to easily provide for me the capability I need, when I need it, without me having to hunt and peck and stitch it all together. One way to look at this particular experience, is to consider everything I do – from opening (or creating) a document, to writing, formatting, spell/grammar checking, saving and collaborating with Austina, and finally sending off to InfoQ.
As I think more about the entire experience I’m having authoring this answer, I realize that the end-to-end experience goes beyond using the word processor. If I think about my entire journey as a complete end-to-end experience – I have to include the email I’ve sent back and forth to Austina, to Ben and to our publisher. There’s a collaboration experience I have with Austina in creating and sharing and co-editing a document. Finally, there’s the experience of submitting these answers to Ben, having them published on the InfoQ site, and then enabling and moderating some community discussion afterwards. This larger view of an experience is sometimes referred to as a complete user journey, or a ‘cradle-to-grave’ experience.
A recent personal example of such a cradle-to-grave experience is that I had to travel across the country to Boston to see my daughter perform in a show (she’s a theater major at Boston College). And I had to return in a couple of days in time to perform in my own show (I’m a budding rock star J). It took a lot of players and a lot of software to enable that experience for me. That full experience encompassed everything from finding and making travel reservations, parking at the airport, checking baggage, boarding the plane, getting some food along the way, logging and tracking my frequent flyer miles, lost & found, customer support, renting a car and/or getting to my hotel, and maybe even an incentive for my next trip, or a follow up from customer service to make sure everything was wonderful. Again, that’s an example of an entire user journey. You can image that each stop along the way of that journey can include many smaller, more granular experiences (like booking a rental car, or going through the payment process).
When thinking about experiences, it’s important to first identify the job you (or your software, or systems) are trying to accomplish. And then to understand and be specific about the lens with which you are going to analyze that experience. You can look at an experience as a few software features working together to perform a simple task. Or you can look at an entire user journey that encompasses a cradle-to-grave experience. As the industry matures, we are seeing companies be successful by delivering complete solutions for larger end-to-end experiences, and we expect that trend will only intensify with time.
InfoQ: What is it that makes end-to-end experiences more valuable than features for customers?
Fletcher. To me, the interesting and challenging thing about these high level end-to-end experiences that I talked about earlier is that they almost always include multiple teams. And I think it’s fair to say that when disparate teams in an organization are responsible for an entire end-to-end experience, it’s all too rare to see these separate teams work together to build a cohesive experience for the customer that crosses their respective domains. Organizational structure, egos, team cultures, etc. all make this coordinated focus on the customer difficult. And therein lies the problem. Because the actual user desires a connected and compelling experience where all the pieces magically work together – as if they were built so that the user can get their task accomplished easily and seamlessly. Whether that task is to write a document, or get to Boston in time for a show – the customer's desire is for all of that to just work, without being aware of all the technology and teams involved in making that happen.
While it’s possible to build solutions that have all the features a user needs to get their job done, it’s the end-to-end experience of using those features that has the potential to give the customer that tremendous feeling that the product perhaps read their mind, that it was actually built just for them. And creating that emotional connection between your product and your customers is a key ingredient for customer satisfaction, repeat business, customer loyalty and getting ahead of the competition.
Another benefit of focusing on end-to-end experiences is that by understanding the high level journey your customer is taking, it’s possible to paint a picture of that journey in such a way that all the teams involved share a unified vision of what success looks like when all of the pieces finally come together. I’m not talking about creating a list of thousands of detailed requirements that are divided up and coded. Just the opposite actually. I’m talking about creating a high level description of what the customer's real life situation is, along with the key attributes that spell a successful outcome for the customer, and metrics to measure progress along the way. In our book, we detail the mechanism of using a set of scenarios to establish a common North Star. Those scenarios are used to help guide the team to work towards the same customer goals such that in the end, all of the features and functionality of the solutions connect into a cohesive end-to-end experience for the customer.
InfoQ: Can you give some examples of how you can blend scenario-focused engineering with a lean startup and agile approach?
Fletcher: SFE, Lean Startup, and Agile are all highly compatible. They are all fundamentally iterative processes that have a common grounding in the scientific method – you form a hypothesis, you create a test, measure, view the results and make adjustments as appropriate. Repeat. In order to figure out how to use the best each of these approaches has to offer, it’s important to understand where each shines.
I’ll go out on a limb here and generalize that the essence of Lean Startup is all about using iteration to identify a viable business model, before you take on all of the expense and effort of creating the business. And the essence of Agile is to use iteration to get the right code written with higher quality and efficiency while minimizing bureaucracy. On the other hand, the essence of SFE is to use iteration to identify the needs a customer has, to put a measurement system in place, and to focus on customer satisfaction.
Many of the techniques we describe in SFE – techniques for observing and understanding the unspoken needs of customers, techniques for building sketches, mock-ups and quick paper prototypes can all be used very early on, especially in a Lean Startup environment, when your goal is to try out different business ideas and find a set of customer needs that real people are willing to pay for. Once you have a handle on your business model, and you can describe your target customer and a core value proposition, that is a natural place to jump full on into SFE techniques and start generating specific product and feature ideas and test them with customers.
My simplistic view of using Lean Startup, SFE, and Agile approaches together is to start by figuring out what business you are in, and exactly who the customer is that you are targeting. In fact, during our SFE workshops we always state that having that knowledge is the cost of entry (into the SFE workshop). And Lean Startup gives lots of tools, advice and ideas on how to iterate, identify, and validate a viable business opportunity. So I would begin a project with a Lean Startup philosophy and approach. I’d try to be curious, experiment and test many ideas until finding one that proves to be a viable business. Along that early path of discovery, I would utilize some of the SFE techniques (especially those focused on observing customers and understanding their innermost needs). I might also look at SFE for some ideas on how to prototype, test and measure ideas quickly as these methods work well when testing high level ideas as well as when testing very specific usage scenarios. Once the business model and target customers are identified, I’d use SFE techniques to further observe the customer and begin the creative process of inventing and testing specific solution ideas. For all of these activities, I would use Agile sprints as the overall project management approach. The main twist being the artifacts you create early on during your sprints will most likely not be code, rather things like customer insights, mockups and prototypes, or descriptions of scenarios and user journeys. And at some point in the process when you understand your customer and their needs, and you have a high level (and tested) idea of the experience that will delight them, you continue your Agile sprints to efficiently write the code to deliver those experiences.
Finally, it’s important to build and track a set of metrics to see if you are indeed on track towards your goals. Most engineering teams we’ve worked with already have a set business metrics in place, as well as a robust set of metrics to track development progress. We suggest adding a third set of metrics to track how well your developing product resonates with your customers – a customer experience metric. Success requires that you perform well in all of these areas: business, technology, and experience. You can use the best of Lean Startup, Agile, and SFE to help you accomplish that.
InfoQ: You talked about using stories to frame situations so that teams can build a common understanding on what needs to be accomplished. Can you explain why specific stories are often more useful than generic stories?
De Bonte: It's not possible to create a truly optimal solution for every kind of generic problem. Different types of customers often have conflicting needs. A soccer mom who receives five email messages a day likely prefers a super-simple view in which to read her email without any confusing bells and whistles. A knowledge worker who receives 150 emails per day regularly uses folders, automatic sorting rules, and message flagging to stay on top of his daily workload. How do you build one email service that optimizes the experience for both usage patterns?
If you want to achieve true delight for anyone, you have to focus. So you pick specific target customers to optimize for, and for those chosen customers, specific stories about their most important real world problems. If you only told your team, "Build an email client," that is pretty vague. Practically speaking, you are leaving it up to the team to interpret which customer and which situations they should be optimizing for, and which features are most important for those situations. And in fact, different people on the team will have differing opinions about what is most important, and so you will likely end up with a hodge-podge that isn't optimal for either type of user. However, if you give the team a specific customer and a specific story to optimize for, everyone is aligned and can spend less time arguing and more time focusing on really nailing a solution for that customer.
It's worth mentioning that it's essential to pick your target customers and target scenarios strategically - to maximize the carryover you will get to adjacent segments who have similar (but not identical) needs. Pick the right target customer, and you might get huge carryover, or tap into a lucrative niche. Pick a couple different target customers with complementary needs, and with carryover you might get a surprising amount of coverage across the market. Pick the wrong targets, and you might make a couple users very, very happy - but still be irrelevant in the broader market.
InfoQ: Can you describe how the kind of feedback that you are aiming at changes when your product evolves during the iterations?
Fletcher: It’s really important to understand that creativity, innovation, and delighting customers is not a linear process. You can’t just outline a pre-determined set of steps to follow that lead to brilliant new ideas that customers love. If it were that easy, everyone would be doing it. There are just way too many decisions, investigations, reactions, and twisty little paths all leading nowhere to put into a linear set of procedures. That said, there is a predictable pattern that occurs.
We present the pattern of delivering great products as looking like a funnel – one that is wide at the top, and gets narrower and narrower towards the bottom. Kind of like this:
You can think about the top of the funnel as being the beginning of the process and the bottom as the end, where the final product comes out. In the beginning, the world is your oyster, there are infinite possibilities, there are an overwhelming number of things you could do. And at the bottom of the funnel, the ability to change becomes very narrow. You have already honed in on exactly what you are building. In fact, you’ve likely already built it and are using iteration to do some last minute fine tuning.
Along this continuum, there are different stages where what you build, and what feedback you look for, changes.
What does the customer need? Early on, perhaps you are using Lean Startup techniques, your biggest concern should be, have I identified a set of needs that customers care about, and are they willing to pay for a solution? At this stage, you don’t care about menus, or UI, or customer support – you want to get the feedback from customers that indicate whether or not they would pay for something that solves the needs you have identified.
Do I have the right solution? In this next stage, you get feedback on the ideas you have for solving the needs you have identified. What form does the solution take – is it a web site, a mobile app, a device, an add-on to something else? Can you mock something up quickly and see how potential customers react? Are the ideas you are testing viable technically? Will customers pay for it? Remember that you haven’t built anything yet, you are still getting high level feedback on basic ideas using very rough, often non-code, prototypes.
Does it work? You’ve begun to actually build out something that is functional – either in code, in rapid prototypes, or both. But now you have enough of the solution defined or built that you can observe customers using it and you can get feedback on the actual mechanics and flow.
How are the details? This is stage when you provide the details, and you ask for feedback on the details. Do all the parts work well when put together, is the color scheme helpful, do all of the parts of the UI flow well, is the language appropriate and consistent, is the installation and support seamless?
The intent is not for your entire application to go through all of these stages, all at the same time, in an orchestrated manner. Using an Agile process it’s entirely possible (and desirable) that different parts of the product are built at different times, in different sprints, at different levels of doneness, by different teams. The importance of understanding these different types of feedback is that you focus on the right level of feedback at the right time. For example, in the early stage when you are trying to see how customers react to the idea of you solving a set of problems for them, getting feedback on the color scheme would probably be more distracting than helpful. More insidious, is if you want high level (hey – would you buy this?) feedback and you present the user with a lot of pixel perfect detail, they will most likely give you feedback on the detail…and that’s not what you want right at that moment. So it’s important for you to understand what type of feedback you are looking for, and how to go about getting the level of feedback that is most important to you depending on what stage you are at.
InfoQ: Your book suggests to build multiple prototypes for getting feedback on product ideas. What is the additional benefit that you can get from multiple prototypes. Does it outweigh the costs?
De Bonte: The big mindshift to make here is to stop thinking about prototypes as working code. Yes, occasionally you will write a prototype with working code, but most of the time when you are building multiple prototypes, you're doing it super early on, and you're almost always making rapid prototypes out of bailing wire and bubble gum, so to speak, and so they are very cheap and fast to make. The most common early approaches are to draw out UI screens (or whatever your interface looks like) on paper as a paper prototype, or for a service situation, acting it out as a skit, or if you need to represent some set of data to create a mockup using HTML and some JavaScript. The goal is to get your proposed solution concept across to a customer with only a couple hours of effort, so that you can get course correction feedback from customers super early. You show multiple of your ideas because you don't know which ones will resonate best - and because psychology says that human beings (your customers) do a much better job giving valid feedback if you give them a small number of things to compare. Your goal in these earliest iterations is to make sure you're solving a problem that matters, that at least one of your solution ideas is in the zone, and generally that you're on the right track - long before you've invested in writing specs, production code, or anything else remotely time intensive. Our rule of thumb for most projects is to do three quick iterations with rapid prototypes - and get three quick rounds of customer feedback on those prototypes, even if informally - before you commit to a specific solution direction. If you don't take the time to do this early vetting of your ideas, you're in great danger of picking a solution path that will not work for one reason or another, and you may not realize it until it is much more expensive, or possibly impossible, to fix later on. If that means the project failing, the product getting cancelled, or the company folding, you simply can't afford not to take a few days up front to make sure you're on a viable track. Think of it as an insurance policy against the biggest risk every project has - building the wrong thing.
InfoQ: Iterations should be short to get benefits from the fast feedback cycle. Can you give some examples of such iterations, and the benefits that they have brought?
Fletcher: A while back Austina and I worked with a team that was faced with a new business problem – to embrace the shift towards mobile computing. The architects got together and came up with a brilliant scheme for running all of their software remotely, including transactions, security, the works…and all to be optimized for a small screen. "Perfect!" they thought. It was indeed very clever technology. Having just gone through an SFE workshop, the team decided to check in with some customers on this revolutionary approach. They were certain the customers were going to love this stuff – their concept was just so cool, so brilliant, and quite unique. So they built a rough prototype (a one day effort, using HTML) and showed it to a handful of customers. And you know what the customers said?
“Huh? Why’d you do that? I’d never use my phone that way. All you need to do is notify me that a sale is pending – just send me a text message. If you can send me a text message as soon as a certain transaction occurs, wow – that would be great – I’d be sooooo happy.”
And so the team went back and rethought their approach. This feedback from customers that was received after literally spending one day mocking up some HTML screens, and a couple days of in person interviews, literally saved them tens of man-years of engineering effort. Had they not received this feedback at this early stage, the development team likely would have begun to build out the brilliant new mobile technology platform that the architects had envisioned. They would not have realized the customers didn’t care about that solution until some ‘beta’ when the actual debugged code was released to customers. But doing a quick feedback loop early on, they were able to easily shift their brains to think about the problems they were solving for the customer with a much different perspective. And yes, after they had a come up with a new set of creative ideas for solving the customer’s “mobile problem”, they built another quick prototype. This time the customer feedback validated that they were on a path towards delighting their customers - with a much simpler architecture.
InfoQ: In the book you talk about holding a sketchfest, also called a charrette, to come up with solutions. Can you elaborate how this works?
De Bonte: The idea is very simple, and can have many variants. The basic approach is to gather a whole bunch of people related to a project, representing many different perspectives - designers, stakeholders, customers, partners, and anyone else you can cajole into participating. You refresh everyone on the problem statement, perhaps expressed in terms of a few scenarios, and then hand each person a stack of paper and a marker. The goal is for everyone to lock themselves in a room and sketch out various possible solution ideas against that problem statement. In a short amount of time, the group brainstorms many ideas from many different perspectives, maximizing the chance that you consider all of the relevant perspectives and constraints that will need to be brought into a successful solution. In the best case, pairs or groups of people review each others' sketches, mix and match the ideas, and come up with "blends" that no one person would have come up with on their own. This can be a powerful way to kickstart a new project, surface important solution constraints that may not have been articulated, as well as build consensus among all of the stakeholders, letting everyone contribute their ideas in a tangible and productive way.
InfoQ: Can you describe how teams typically adopt Scenario-Focused Engineering? Which steps do they take to deploy this way of working?
Fletcher: When we first engage with a team on coaching SFE practices, we always start out by having a series of meetings with the leadership team. This allows us to make sure the leaders know what they are signing the team up for, and gives us more context so we can customize content for that specific team. During those meetings we always ask the leaders how well they feel their team executes on delivering products with high customer value, and we ask them to rate their team’s creativity and innovation skills on a scale of 1 – 5 (we present a simple model to help with this). We then ask them where they would like their team to be in a year. Inevitably, most leaders proclaim, “on a scale of 1 – 5, we want to be a 6. We want to be just like Steve Jobs and Apple within a year!” We hear this all the time.
The fact is that it takes a lot of time, a lot of hard work and a lot of intentional focus to change the culture and best practices of a team. It does not happen overnight. In answer to your question, I can tell you that we have seen some common patterns emerge as teams embrace an iterative design practice such as SFE. We did include a couple of case studies in the book that detail two teams' journeys through this maturation process. We also include a self-assessment tool in an appendix that helps teams assess where they are currently and help them think about and quantify opportunities for improvement.
Here’s a brief description of some typical stages we see teams go through as they venture into a customer-focused culture.
Strategy. One of the first changes we see is that leaders and teams get crisp about the business opportunity they are pursuing. If the leader doesn’t offer this up soon after our workshop (or preferably beforehand), it’s typical for the team to demand to know, from the leaders, what is the underlying business strategy behind the product they are about to build, and who are the target customers. You may be surprised to hear that many of the teams and leaders we work with do not have a strong articulation of the business value they offer, or specifically which customer segment(s) they are targeting and why. This has been especially true for products that have been in the market for a while where the general team strategy seems to be “do it again, but a bit better this time.”
Alignment. The next stage we often see is that teams take the business direction from leaders, then go on to do an amount of customer research and observation and craft product scenarios to describe at a high level what success looks like, and how it will be measured. This is a very important stage, because it is the one that provides alignment amongst the entire team on what is important and how it will be measured. It is an especially valuable step to take when the products and services being built require coordination across multiple and disparate teams.
One benefit we’ve seen from having entire teams take the SFE workshop, is that the team starts to build a shared vocabulary and understanding around both concrete things they will build (eg: everyone has the same understanding of what is expected from a scenario), as well as vocabulary around emerging cultural norms (For example, I am not the customer, do a few things right, write SPICIER scenarios, generate ideas when the ‘snow is fresh,’ etc).
Iteration. This is the stage where teams work out the specifics and details of their iterative process. Of course, if a team has already been using Agile practices, they are already well down this path. However many teams are Agile in name, but upon closer inspection look more like "scrummerfall," and have a ways to go to truly build iterative rhythms and regular feedback into their daily work. Getting all the infrastructure in place, and a truly iterative rhythm in the work schedule is the next important milestone.
Adaptation. A pattern we’ve seen that encompasses all of these stages is one of adaptation. Teams set out to achieve certain goals (maybe like those listed in these stages), and they find themselves continually adapting the methods and mindsets that work best for them. SFE presents a toolbox of options, and successful teams modify and evolve how they use SFE to find what works best for them.
Culture. Creativity, design, innovation and creating products customers love is indeed a team sport. There are certainly a lot of mechanics that can be learned, but teams that thrive tend to have their very own, very strong culture around customer-focused product development that emerges over time. Throughout our book we call out some of the more prominent values that we’ve seen and that is supported by research. I’m talking about things like rewarding failing fast, the discipline to generate multiple ideas before making any decision (or even better, blending the best of several ideas together into a new one), embracing diversity (the idea that you’ll have better results if you get many different perspectives), or making the shift to leaders acting more as facilitators than as deciders or task masters. These are just a few, we outline many in the book and indeed there have been many outstanding books written on this topic. As a gross generalization, we’ve observed teams taking about two years to get from early stages of embracing iterative design, to the point of seeing deep cultural changes take place.
InfoQ: You devoted the last chapter of your book on the lessons that you learned from teaching Scenario-Focused Engineering and observing teams. Can you give some examples of your learnings?
De Bonte: Probably the single biggest lesson is how difficult it is for teams to adopt these ideas - not because any of the techniques are particularly hard to learn, but because a customer-focused, iterative approach runs counter to the standard way of doing engineering that teams have been doing for years, even teams that claim to be doing Agile. We found that leading a team through this shift was much more about leadership and change management than it was about processes, tools, and techniques. No surprise, the teams that made the most progress the quickest and saw the strongest ROI were the ones with strong, determined leaders who unwaveringly saw customer-focused iteration as a strategic advantage for their business.
About the Book Authors
Austina de Bonte is a trainer, coach, consultant, and change agent. During her16-year career at Microsoft, she was an intimate part of Microsoft's first forays into online services. She led program management of the first versions of the popular MSN Messenger Service, where she experienced the value of a user-centered design approach firsthand. Austina conceived and founded the Scenario-Focused Engineering initiative in 2008 to help accelerate Microsoft’s shift towards dramatically more customer-focused, iterative design and product development approaches, which trained more than 22,000 Microsoft engineers and their leaders in these practices. Austina has a Bachelor's and Master’s degree in Computer Science from MIT.
Drew Fletcher is an educator, speaker, and consultant currently living in the Seattle area. Drew spent 20 years at Microsoft, where he led teams that delivered many innovative products, including the first versions of Visual Basic, Visual J++, Visual C++ and Visual C#. Drew has a BSBA in International Management from Boston University. As an avid back country climber and skier Drew volunteers as a rescuer with Seattle Mountain Rescue and serves on their board of directors.
