18a. Prototyping To Learn, Explained Yet Again

To say it again, prototyping is all about learning.

Source

“Prototyping . . . involves producing an early, inexpensive, and scaled-down version of the product in order to reveal any problems with the current design. Prototyping offers designers the opportunity to bring their ideas to life, test the practicability of the current design, and to potentially investigate how a sample of users think and feel about a product.” Source

Here’s a list of things you might try to learn by building a prototype. This should help further illustrate what prototyping is used for:

• Does this thing actually work like I think it will?
• Does this part fit into that part?
• Does this feature actually provide a benefit to the consumer?
• What will this taste like? (Chefs make prototypes too.)
• Does this app work intuitively?
• Will people actually use this function?
• Does this web application integrate with that one?
• Does this camera take good selfies?
• Will this screen smash into a million pieces if I drop my phone on the ground while taking a selfie?
• As you can see, the learning which prototypes enable can be narrow or broad:
• Narrow: Does this thing function like it should?
• Broad: Do consumers like / need / want this thing?

In other words, you can use prototypes to answer the question, “Am I building the product right?” or “Am I building the right product?”

See the critical distinction between those questions?

Remember, in the waterfall method, where it’s quite expensive to pivot to a new product concept, and prototyping is mostly focused on “Am I building the product right?”

You’re likely more confident in the customer needs. The uncertainties remaining relate to how exactly to meet these needs.

In the lean startup method, where there is likely more uncertainty and less cost to iterating, prototyping is mostly focused on “Am I building the right product?”

You care a lot less about how well the prototype is functioning and a lot more about how customers are responding to it (i.e., has it achieved product-market fit).

People have tried to capture this distinction visually. I think this graphic does a pretty good job:

Source

So . . . why clarify this distinction, . . . especially since we already touched on it in Chapter 16 and Chapter 17?

Here’s the thing; if you’re relatively new to NPD, you’re going to find a lot of writing and guidance on prototyping. It’s everywhere.

It’s important to realize that some “prototyping best practices” may only be appropriate for a specific method of NPD (i.e., lean startup or waterfall).

Understanding that prototyping is handled differently in different industries (or different development methodologies) will allow you to filter/process content that you come across in the future.

That said, the universal thing I can say — and I’ll say it again for the hundredth time — is that prototyping is about learning.

18b. Using Prototyping as a Schedule Mechanism

Source

One of the reasons that prototyping is so important to NPD is that it’s not just a tool for learning . . . it’s also a tool for scheduling.

Scheduling new product development can be a very tricky science. Uncertainty is everywhere. Predicting when a product will be ready for market launch is difficult stuff.

And even if you could perfectly predict when an NPD process would organically complete, we don’t really live in a world where products are launched when they’re ready. Product launches are typically planned years in advance and scheduled to align strategically with the market, seasonal, or corporate rhythms.

In other words, the product doesn’t launch when it’s “ready;” the product launches when it’s due.

The Challenge: How the hell to hit a product launch deadline.

One Answer to this Challenge: Use prototype cycles to manage the development schedule.

The Prototype Cycle as Building Block for the Development Schedule

In most product development methodologies, the product team will divide the development window into a series of prototype cycles. The team advances toward the launch deadline by building one prototype after the other until time runs out.

“ . . . Prototyping — the build and test activities of each design-build-test cycle — is a key management tool for guiding development projects . . . management can use prototyping cycles to guide and pace development projects and to assess their progress, pinpoint unresolved issues, and focus resources and attention.” — Revolutionizing Product Development

Here’s an example of what I’m talking about:

Prototype 1 — Establish technical feasibility and answer some critical questions like “can this actually work?”

Prototype 2 — Build some more functionality into the concept and get some potential consumers involved. How well is the prototype meeting their needs?

Prototype 3 — Prototype 2 broke. Shit. Redesign that feature and build out prototype 3.

Prototype 4 — Now we’re really cooking; this thing is starting to look like something we could launch; this proves we can hit our launch date.

Prototype 5 — A major build-out or tooling is made; pilot run; beta testing; we’re almost launching . . . holy shit!

Launch — This isn’t a prototype . . . this is the real deal. But yeah, we just learned a lot more and have ideas for the next version, so let’s start prototyping that right now . . . 

Most product development schedules are built using prototype iterations as the fundamental building blocks of schedule.

As you can see, prototype cycles can divide a single development window into smaller, more manageable chunks of time. The team sets deadlines to complete each prototype, as well as specific goals for performance at each iteration.

With each round of prototyping, things are built, measured, and learning occurs. The product concept (or concepts) evolve forward, and the team can judge whether the progress made meets expectations.

Prototyping during the product development process essentially allows product developers to visualize how much learning will take place over time. Each prototype is a chance to really examine how “ready” a subsystem or technology or component or element of the product is.

“Generational prototypes, and especially periodic prototypes, are effective for accelerating schedules because they keep constant attention on the schedule. In effect, they allow us to control product, and thus project, performance against time.” — Don Reinertsen, Developing Products in Half the Time.

Most people don’t initially think of “scheduling” when they think of prototyping, but they should. Carefully managing prototype iterations is perhaps the best way to manage the entire NPD process. This information is true across industries, and often regardless of whether you’re a small startup or an enormous Fortune 500 company.

18c. The Trade-Off Between Speed and Fidelity

Prototypes can be made quickly, or they can be made accurately — typically not both.

If you could simply build full-scale products quickly and accurately, you wouldn’t need prototyping.

Prototyping is — by definition — a scaling back of scope or quality in order to achieve speed.

If you’ve ever heard the expression “fast, cheap, and good, pick two,” prototyping is a lot like that.

Source

This somewhat echoes the project management triangle that exists in almost every project: speed (or time), scope, and cost.

Source

Note that the project management triangle is not to be confused with Silicon Valley’s “conjoined triangle of success.”

Source

“Which is more important — speed or fidelity?”

Interesting question. Like most things in NPD, you’re going to get the typical lawyer’s answer: it depends. There’s just no single best practice.

The Case for Speed

Sometimes speed is everything, even if it means building a shitty prototype. One of the mantras of Design Thinking is to have a “bias toward action.” When in doubt, build a prototype.

Folks in Silicon Valley also love to talk about “failing early and failing fast.” Time is money. It’s typically less expensive to fail sooner rather than later, so just start building and go fast!

The Case for Fidelity (Quality)

Alternatively, faster isn’t always better. It is possible to make a prototype so poorly that you can’t learn anything trustworthy from it.

Running an effective experiment is not easy. If the prototype is garbage, or it’s tested in a manner resembling a dumpster fire, you may end up with garbage results and garbage insights.

Speed AND Quality!

There really is no magic answer that works in every situation. If there is any distilling this topic, it would be the following:

A prototype is a means to an end. The “best” prototype is the one that achieves the objective as quickly and inexpensively as possible.

Be thoughtful and deliberate in how accurate and fast you need your prototype to be. Consider exactly what you are trying to learn and build accordingly.

18d. Actually Selecting a Final Product Concept

I know what you’re thinking: it seems unceremonious to have the section on selecting the final product concept buried within a chapter on prototyping.

Shouldn’t final concept selection be a momentous occasion worthy of its own Chapter?!

A typical product developer after completing prototyping, ready to select a final concept

The truth is, in many NPD processes, the final product concept simply evolves through a series of prototypes.

That’s right; not only is prototyping is a learning mechanism and a scheduling mechanism . . . it’s also a decision-making mechanism.

Let’s distill this idea.

Final Product Concept Decisions

Here’s a diagram of a typical waterfall-type NPD process:

Sure, you’ll see a different overall process in agile or lean methods, but that “Build-Measure-Learn” loop is present in every single NPD method out there.

And — in every NPD method — you eventually have to get off the “build-measure-learn” merry-go-round and ultimately make some decisions. It actually might be more accurate to describe the prototype cycle as “build-measure-learn-decide.”

In practice, prototyping is the primary mechanism used to inform decisions related to selecting a “final” concept.

There Can Be Only One

Many NPD methods will involve prototyping a few final product concepts. This concept may apply for the entire “product” as a whole, but it’s probably more likely to apply to subsystems.

For example, a “subsystem” prototype might be whether an airplane component is made from aluminum or carbon fiber. Or maybe you’re considering two or three different methods for powering a scooter or displaying information on an app. Or the on-boarding process of your software.

Prototyping each of these concepts will provide you the insight into which works most effectively. You will learn what works and what doesn’t work.

You may even learn that you need an entirely new concept to accomplish your objectives, and you’ll iterate back to generating new ideas.

The looping / iterating process can happen for as long as you have time for it to happen. But if you want actually to launch a product at some point, you have to make a decision and select a final concept.

Check out this diagram about Design Thinking. Notice that there is no “big decision moment” when a final product concept is selected — the product just evolves forward until it’s either deemed ready or more likely until the NPD team runs out of time.

Iterative learning and decision-making drive the team toward the best concept. Decisions are made through prototyping.

Sure, there are some NPD processes where “Concept Selection” consists of picking one, the final concept at the outset, and then prototyping it until it works right. For whatever reason, it might be too expensive to prototype multiple concepts and compare them to one another.

For situations where that is the case, selecting a product concept is a much more momentous occasion. That might look a little bit more like this:

Different products and different organizations will take different NPD approaches.

In many cases, multiple product concepts are prototyped, and it’s not uncommon for new product concepts to emerge even after “Concept Selection” . . . thanks to the wonderful insights generated during prototyping.

In Summary

Prototyping is going to reveal if the product concept is right. That means that NPD processes should use prototyping to go from a narrow list of possible product concepts to a final one.

18e. The Last Word on Prototyping

Prototyping is a mechanism for learning.

The nature of the learning is really up to you and how you design and run your experiments.

Things you might learn through prototyping:

• Testing hypotheses about customer needs, jobs to be done, target users, the customer journey, and everything else in the problem space
• The connection or causal mechanisms between product specs and features and product performance or customer value.
• The functionality of any kind
• Business implications, like how much you might be able to charge for a product, or how to promote it to the right end-user.
• Simulating user interaction
• Manufacturability
• Durability
• Design effectiveness and how target users respond to the design
• Cost
• Customer reactions
• Yes, this is a long list, and yes, it could be even longer

Prototyping is a fundamental building block of the development process.

The development process can look like one vast, overwhelming window of time. Prototype cycles, on the other hand, are much easier to visualize, easier to schedule, and they provide an effective way to plan progress over time.

“Conceptually, any development project can be thought of (and usually is, at least implicitly) as a sequence of design-build-test cycles.” — Revolutionizing Product Development

Prototyping improves communication.

“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.” — Tom & David Kelley.

The stakeholders involved in NPD are often from a wide range of different backgrounds: executives, marketers, engineers, designers, left-brained, right-brained, big-brained, little-brained. Not everyone speaks the same language. Prototypes reduce miscommunications.

Prototyping enables better Decision-Making.

Better decisions are made when people have more information and more accurate information. For important decisions — like selecting final product concepts — prototyping is the often best way to learn about each option.

Prototyping begets better and faster future prototyping.

Prototyping is a skill that can be improved through practice or study. While we’ve only distilled the topic here in Chapters 16, 17, and now 18, this is by no means the final word on the topic. See the list of resources below for further reading.

Resources

Revolutionizing Product Development has some 65 pages on prototyping: methods, tools, best practices, etc. It’s definitely oriented heavily toward physical products more than digital products.

The Lean Startup and The Lean Product Playbook are both good places to start with understanding lean (and often digital product) prototyping. Or refer to anything written by Steve Blank.

Everything you wanted to know about prototyping. Another good article.

Good online guide for digital and UX prototyping at boagworld.com

A nice infographic on Prototyping

See Product Development Distillery’ Chapter 16 — Prototyping and Chapter 17 — Prototyping in Agile and Lean