This site is about everything digital, giving an update on new things as I learn

Book review: What Product Managers Need To Know About Rapid Prototyping

“What Product Managers Need To Know About Rapid Prototyping” by Mike Fishbein and Josh Wexler is a great ebook for any product manager keen on prototyping before building the actual product. Mike Fishbein is a content manager with Alpha UX and Josh Wexler is a solutions director at Originate. In this book, they’ve collated their learnings and tips with regard to rapid prototyping.

I’m currently learning how to create prototypes, using tools like Balsamiq, Illustrator, InVision and Sketch. Reading “What Product Managers Need To Know About Rapid Prototyping” felt very timely. These are the main things I learnt from it:

Why do we need a prototype!? – Fishbein and Wexler point out very early on in the book that experiments are critical to alleviate risks inherent in new product or feature development. Prototyping is at the core of experimentation; it provides a quick way to validate your assumptions with real users and tackling key product risks early on in the process. It can be as simple as using a piece of paper with a sketch of a new feature for initial product validation. The main thing is that you use a prototype to mitigate risk by getting feedback early and often in the product (development) lifecycle.

Why do product managers need to know about prototyping? – Building on the importance of experimentation, Fishbein and Wexler argue that “the product manager’s primary role becomes enabling experimentation as a seamless capability. At the core of experimentation is rapid prototyping.”

Generative vs evaluative experiments – The distinction between generative and evaluative experiments is an important one. Typically, new products or features will start with “generative” experiments, where it’s all about identifying and assessing customer pain points or problems. In contrast, “evaluative” experiments are used to evaluate different options for a product direction. You’re evaluating a number of ways to resolve a customer pain point that you’ve established during a generative experiment. Rapid prototyping is critical during evaluative experiments.

Consider constraints when prototyping – Using the words “prototyping” and “constraints” in one sentence might sound like a contradiction in terms, as you might think that prototype means having a free rein. In contrast, it’s important to pay attention to constraints when creating prototypes. The book suggests a number of important questions to ask before creating a prototype (see Fig. 1 below).

Use a Learning Model, plotting ‘perception of value’ vs ‘simulation of value’ – Fishbein and Wexler describe the perception of value (‘PV’) as “a conglomeration of of metrics that together provide insight into comparative user feedback.” In other words, the higher the PV the better. Simulation of value (‘SV’) shows how close the user is to actually experiencing value. Going back to my earlier example of a simple sketch on a piece of paper; this might generate a high PV, because the user gets the value, but the SV is likely to be very low in comparison. It’s fair to say that higher SV values will generate more reliable user learnings and insights, as the prototype delivers more concrete value to the user.

Plotting goals and constraints – It was really interesting to learn about plotting goals and constraints when thinking about creating a prototype. A good example of a constraint is “risk-threshold”, which represents the minimum amount of data you need to collect before your business gives the green light for a product. The ‘goal’ element covers the ‘why’ and perceived value of a product.

Don’t forget about the ‘story’ – In addition to perception and simulation, Fishbein and Wexler also suggest looking at the ‘story’. The story dimension represents a continuum of the user’s narrative and how they might interact with the value proposition of a product. The book talks about about a so-called ‘double dip effect’, This effect typically occurs when product managers succeed in unlocking the ‘story’ element; when iteration cycles are so short that, following positive experiment results, product teams can run another experiment to understand the “why” behind the initial results. The key point here is that when prototyping becomes a rapid process, the product manager will be able to fully learn the narrative of her (target) users.

Balancing simulation of value with iteration time and resources – Fishbein and Wexler also address some of the tradeoffs inherent in rapid prototyping. They point out that “prototyping lower simulations of value costs less and has shorter iteration cycles than prototyping higher simulations of value.” However, the insights you typically get from lower simulations of value are likely to be less reliable and detailed compared to high simulations of value. I’ve included Fishbein and Wexler’s pointers on how to manage these tradeoffs in Fig. 2 below.

Main learning point: I recommend “What PMs Need To Know About Rapid Prototyping” to any product person who wants to use prototyping as a way to learn quickly and often. Fishbein and Wexler have written a very comprehensive book which provides product managers with a great overview of dos and don’ts with regard to rapid prototyping. This book has definitely helped me in thinking about prototypes in a much more structured way!

Stay in scope – It’s not about creating beautiful designs for your prototype, the goal is to learn about the user and their interactions with a product’s value proposition as early and often as possible. Staying in scope is therefore a key notion.

Adapt the methodologies – No (prototyping) methodology is set in stone. Instead, Fishbein and Wexler recommend understanding the high-level purpose of each prototyping step and then adapting it to your organisation.

Select technology that supports your best practices – When it comes prototyping, there’s a thousand and one tools to choose from. The important part is to make sure that prototyping is an efficient and waste-reducing mechanism for learning about users and validating new product concepts.

[…] needs, ideally before a single line of code has been written. It’s important to do generative research to understand the scale and nature of a user problem before evaluating potential solutions […]

[…] deliberate. Knapp, Zeratsky and Kowitz explain that the more time you spend on creating a prototype the more likely you are to become attached to it, and less likely to make any changes based on […]