Scenario-Focused Engineering: Take an Experimental Approach

In this chapter from Scenario-Focused Engineering: A toolbox for innovation and customer-centricity, get an overview of the customer-focused, iterative approach called the Fast Feedback Cycle. You will see what it looks like, what the basic activities are at each stage, and how the stages fit together.

To stand out in today’s mature software market, you need to delight customers at an emotional level. A reliable way to delight customers is to deliver an end-to-end experience that solves a complete customer need, even if that means delivering less functionality overall. But how do you build those end-to-end experiences? And perhaps more importantly, how do you know which end-to-end experiences to build in the first place? The secret is staying focused on customers’ real-world needs and desires and taking an iterative, experimental approach to zero in on great solutions for those needs.

In this chapter, we give you an overview of the customer-focused, iterative approach that we call the Fast Feedback Cycle. You will see what it looks like, what the basic activities are at each stage, and how the stages fit together. Subsequent chapters dive into more details and techniques for the work you do in each stage of the Fast Feedback Cycle.

Designing a new mouse

Let’s start with an example of using the Fast Feedback Cycle to build a hardware device—a mouse. This is a case study of Project Bentley, a Microsoft hardware project that was chartered to build a highly ergonomic mouse.

The inspiration for the mouse was simple—when observing customers who were using Microsoft’s ergonomic keyboards, the hardware team noticed that many customers used gel pads or other accessories to make their mice more comfortable to use.1 A highly ergonomic mouse would be a natural extension to Microsoft’s line of strong-selling ergonomic keyboards, and so the project was born.

With a bit of research about situations in which people used a mouse, which buttons and sliders got the most use, and the size of the average hand; a decision to focus exclusively on right-handed users; and a long history of designing mice and other hardware, the team began to brainstorm possible solutions. Here’s what its first round of ideas looked like:

The team made many quick prototypes—about 50 of them in all. Each of the prototypes was made very quickly from inexpensive, easy-to-work modeling materials. None took more than 15 minutes to create, some much less. But take a closer look; many of the prototypes are not finished. In fact, some of them are downright strange. For instance, look at the gray one in the center: Which way do you hold it? Where do the buttons go? Look at the tall one just above the gray one and to the left—it’s sharp on top. Would anyone ever ship a mouse that’s sharp on top? Many of the mockups look like they were abandoned halfway through. Several have thin lips on the bottom that look destined to crack off and would never pass a manufacturing review.

The point is that the team tried out ideas that even in their mind’s eye were going nowhere, just to see whether they might lead to a better idea.

At this stage in the project, it’s cheap and fast to try out a new approach, so the team considered as many different shapes, configurations, and form factors that they could think of. This is a classic brainstorming step, where you cast the net as wide as possible at the very beginning of the process, when your brain is most capable of generating many different ideas. It turns out that some solid neuroscience lies behind why your brain is much more capable of generating lots of ideas when you brainstorm early, as the first step of a project, before you become too mentally committed to any single approach. We’ll go into this in detail in Chapter 7, “Brainstorming alternatives.”

To get some input as to which models were working best ergonomically, the team then showed them to a few customers to touch, feel, and hold. The team also began thinking through which approaches were most likely to be technically feasible. It’s notable that this first round of customer feedback happened just a few weeks into the project.

After considering that feedback, they produced their second round of ideas:

Note that the team didn’t choose just one of their initial ideas to work with in more detail—they were still working on nine alternatives in this round. But this time, instead of using foam and clay, they built CAD models for each mouse and “printed” them out using a 3-D printer to create the physical forms. At this point the details were starting to get worked out. The buttons and precise contours were all there, and you can see that each one now incorporates a scroll wheel, which turned out to be a key request from customers.

The team was now also considering the technical implications of each design. Would it work for manufacturing? Would all the gearing and components fit inside the case? What kind of plastics could be used? In parallel, they continued testing with users to get feedback about how the mouse felt in people’s hands—because, after all, the ultimate goal was to build a mouse with superior ergonomics.

Again, the team didn’t pick just one concept to move forward with. This time they selected four options to prototype more fully—now with functional buttons, real materials, and all the internal mechanisms. Just as before, they debated the technical feasibility of each design and had customers use these mice in real situations to get detailed feedback about what worked and what didn’t.

In the end, here is what they finally shipped, the Microsoft Natural Mouse 6000, released in 2008:

Did you notice that the mouse they shipped is not the same as any of the final four prototypes? While it is most similar to H, look closely and you’ll see that it incorporates aspects of all four of the final models. The same sort of combinatoric mixing of good ideas from multiple lines of thinking happened at every stage of this process. Go back and look at the 3-D models—none of them is exactly the same as any of the original foam models. Similarly, none of the four functional prototypes is the same as any one of the 3-D models. As the team iterated, it combined and recombined the best ideas from different prototypes to narrow in on the combination that worked the best—both for technical feasibility and for end-user ergonomics. In the end, they delivered a product that did well in the market, and really delighted their customers.2

Engineers naturally tend to iterate ideas. As you work through the issues and get feedback from others on the team, your solutions steadily get better and more refined. However, unlike in this example, you typically start with only one seed—one reasonably good idea of how to solve the problem, and you iterate from there, continually refining that idea until you get to a final solution.

However, if you think back to your mathematics background, starting with one seed is a really good way to find a local maximum in a complex plane. If you want a more statistically reliable way to find the global maximum, you need to start with more seeds. This is the magic behind the iterative approach illustrated by the mouse example—combining and recombining the best ideas from multiple lines of thinking within the Fast Feedback Cycle to give you the very best odds of finding the most optimal solution across all of your constraints.

Some of you may question whether this illustration is even relevant to software development. We chose this example because it provides a great visualization of what an ideal iterative process might look like. It’s a good example precisely because it is so physical and easy to photograph and view step by step. For software projects, you don’t prototype with clay and foam, but on paper, with wireframes, whiteboard drawings, storyboards, PowerPoint mockups, prototyping toolkits, flow diagrams, or even by writing prototype code. To capture a similar snapshot of the iterative stages in a software project would take stacks and stacks of paper, and the patterns would be much harder to see at a glance. But regardless of the form factor, the core ideas are exactly the same:

Start with a clear idea of which target customers you are building for.

Understand those customers’ needs and desires in the context of their real-life situations.

Explore many possible ideas, especially in visual ways.

Build several rapid prototypes of the most promising ideas.

Evaluate prototypes with customers to get feedback and learn, while working through technical feasibility in parallel.

Refine prototypes, gradually focusing in on fewer ideas, adding more details at each successive round, and eventually writing production code once your plan has stabilized.

Repeat as needed.

It’s worth taking a short pause to ponder a quick thought experiment. What would it take to actually work with multiple ideas in an iterative approach in your software development process? How different would that be? How close are you to doing these things already in your current team and project? What would the implications be if you recentered your whole engineering system on this approach?