Leveraging prototypes for rapid innovation

A guest post by Fearless Product Manager Jesse Alton

When and why should you build a prototype?

I encourage you to think of prototypes as tools. They come in many different flavors, based on the problems you are looking to solve, and instead of being the solution, prototypes are part of the journey getting there.

You should start building a prototype on the first day of a contract or engagement, instead of presenting a prototype on the last day as a marker of the project’s success.

A day 1 prototype definitely won’t be perfect but you’ll be able to pull information from what the team comes up with and then everyone can iterate and improve from there.

4 Types of Protoypes:

The type of prototype you develop will depend on what you are hoping to discover and what problems need solving.

1. Usability: To better understand user needs
2. Feasibility: To determine if we can we actually build this
3. Viability: To understand business objectives and requirements (often a workshop)
4. Desirability*: Does the client like the general direction we’re going (We created this category ourselves as both an icebreaker and a summary prototype method)

Usability prototypes

This is your most common prototype, we are trying to find out what the user wants, needs, or prefers.

The information we are looking for with usability prototypes:

• Better understand user preference.
• For example, does the user like red or blue.
• Does this actually solve the user’s problem?
• What could be missing?
• Good usability testing doesn’t tell users where a button is a product. Instead of telling, you’re asking: What do you think that does, where do you think the button is, etc.
• Will you use this?

What we aren’t looking for:

• Does the client like how this looks?
• We love our clients, but this is not the space for their opinion. Don’t worry, we’ll ask what you think or want but not in this exercise.
• Can we build it?
• We’re not asking if something is realistic or even possible. If a user wants pie in the sky, then we want to hear it here.

A good usability prototype will tell you what users want and most importantly give you the data to back up your findings.

Feasibility prototypes

Now we can have the discussion of what’s realistic and talk about technology and capabilities. Prove your idea in code. With this type of prototype, we don’t care what the users want or if it’s good for the bottom line. All we are asking here is: Is it possible?

What are we talking about with feasibility prototypes:

• This is a time for technological discussion.
• Get unstuck. If the team has a case of analysis paralysis, then let’s test out options.
• Ask yourself: Can this solve our problem? Can this scale?

What we aren’t looking for:

• Does the user like the way this looks?
• Does this work with the budget we have? Is it cost effective?

The team can now tell the product owner what is possible.

Viability prototypes

Viability prototypes are usually not a stand-alone exercise. Viability is part of the larger conversation of your project.

These exercises are excellent to run when you need a check on the business needs. Requirements, needs, and direction change and it’s foolish to fold your arms, be stubborn and say, “No no the user wants this.” The client’s voice matters, so conversations need to happen. Run a stakeholder workshop with a value proposition canvas or a business model canvas paired with another prototype.

What we want to learn from a viability prototype:

• Better understand business requirements.
• Respond to shifting requirements (i.e. COVID-19 changed a lot of requirements for products)

What we aren’t looking for:

• Does the user like the way this looks?
• Is it technologically feasible?

This is the time to talk about what you’ve learned and relate it to what the client wants.

Desirability prototypes

“The Jesse Alton prototype”

This is usually the first prototype I build when kicking off an engagement. In the first few days of a project, I take whatever information the team can gather and start putting something together.

If we can afford a month of research to get a good footing, that’s great. However, we can adapt desirability prototypes to almost any timeframe to summarize what we’ve learned and what we think we could build. As long as you accept that there is a list, and so long as you accept you can always go back to and add to that list, you’ll gain a baseline for iteration.

How desirability prototypes are useful:

• Perfect for understanding general direction, without getting caught up or shut down by the details.
• Can be the first prototype you show a client, and the last one before MVP
• Should be used again as a final summary before building your MVP (based on our feasibility, viability, and usability testing, we have found that this is the best fit to solve x problem or need)

Prototypes are key tools for testing, validating and decision-making in the product management cycle.

Prototyping should always generate dialogue. Prototyping should never generate shame.

Check out the Fearless product management playbook to learn how to make sure your product solves the root problem, not the side effects.