Why every product manager should be able to prototype
Tags: Prototyping, Stories, Product Management, UX, Product Design

Why every product manager should be able to prototype

Capture your vision for the future… and learn from it

At productboard, we recently got turned on to the This is Product Management podcast put on by Alpha. Each episode discusses some facet of product management through the eyes of a new practitioner, frequently a PM by trade but also sometimes those in professions tangential to the field. In fact, you might say one of the takeaways of the series is many more people are doing product management than have the title “product manager”.

In one of the early episodes, Josh Wexler, head of product at Yieldmo, zeroes in on the practice of prototyping and perfectly encapsulates why it’s so important for product managers to master:

“Prototypes are visions of the future — some way of being able to see and experience the future of an idea [where doing so in words would fall short].”

Seeing and experiencing the future! Isn’t this why all of us got into product management in the first place? At it’s best, the role lets you bridge real world problems with optimal solutions and bring something new into existence that didn’t exist before. Of all the activities that product managers do, prototyping may be the closest to the problem-solution bridge itself. It’s the first step we take toward solving a user’s problem, and when done right, it deliberately reduces risk by ensuring we’re not wasting time designing and delivering the wrong thing.

Your paper prototypes do *not* need to look this nice (source)

Low fidelity prototyping

As Wexler notes, the kind of prototype you use may depend on where you’re at in the process of product discovery or delivery. If you’re simply trying to ensure you understand what need the user has, your prototype could be very low fidelity. In other words, attention to realistic details or aesthetics of the final solution is of little to no importance (and would actually be a waste of time).

For example, if a user was trying to explain what kind of information they wanted to be able to share with their boss out of your app, you might sketch (or mock up) some charts displaying particular metrics trending over time. The sole goal at this stage is making sure you understand the user’s core need, and in our case that means using the prototype to answer two main questions:

What kind of information is the target user looking to share with their boss? How do they need to be able to share this information?

This is too early to work out the specifics of how exactly this area of the app would function or what it would look like. (Red button or blue? 🚫) Spending time on the specifics too early leads to wasted effort because it may turn out that your beautifully prototyped feature solves a problem that users don’t even have.

Maximize learning with minimal effort (source: https://medium.com/galleys/the-prototype-mindset-396c979a356f)

After all, your early prototype might prompt the user to say:

“Actually, these line charts are fine but the single most important thing is tracking the productivity of each one of our facilities and comparing that to a benchmark handed down from corporate.”

And that bit of information could entirely alter your approach. ⚡️💡

Middle fidelity prototyping

As your understanding of users’ needs improves, you can increase the fidelity of your prototypes. This may mean spending more time considering how the final solution will work and incorporating that in subsequent versions of your prototype, testing with users along the way.

Continuing on with our example above, you might extend your early mock-ups by sketching several different application states and shifting paper elements around in real-time during a user interview to simulate a proposed flow. You could also design digital prototypes that users click through using tools like Keynote, Invision, or Axure. On most teams, this would be nearing the purview of the UX designer, but it’s important that PMs learn to prototype with these tools as well. It means that if all design resources are occupied designing features further down the product development pipeline, PMs can avoid a bottleneck by prototyping to kick off the discovery process for new feature ideas. Digital prototyping is also a valuable way for PMs to communicate ideas to teammates, particularly when working on a distributed team. While prototypes are typically based on a written narrative describing a set of user scenarios, abstract concepts can be easier for teammates to grasp when expressed as a concrete prototype.

The key here is to make sure you have the right culture in place so that 1) the design team understands you’re not stepping on their toes by attempting to do their job for them 2) users and teammates alike understand you’re not proposing the final solution, which may look and behave quite differently depending on subsequent learnings.

It’s rarely important for PMs to carry out high-fidelity prototypes that represent the final solution users will enjoy so we won’t discuss those in detail here. These can be created by designers using tools like Invision and Axure, or coded by a frontend developer using cheap code, optimized for speed of delivery rather than production quality.

What can go wrong?

Most of us are products of an education system that trained us not to iterate, that conditioned us to hurl our efforts into a final product that would be graded without incremental feedback along the way. As such, Wexler asserts that the biggest issue PMs face while prototyping is succumbing to perfectionism or otherwise going too high-fidelity too soon. 🎁 ☠ If you get over-excited and start designing the final product, it’s easy to forget you don’t even know what the user’s problem is. And when early prototypes are too polished you’ll lose the opportunity to learn and iterate. That’s because users see fancy interfaces and assume a lot of hard work must have gone into designing it, so everything must be set in stone. And if they sense you’re too attached to it, they’ll only give you feedback on the minutiae out of concern for your feelings. Very nice of them… but not especially helpful if it ends up wasting hundreds of man hours building a feature in the wrong way.

Embellishing certain prototypes over others can arbitrarily bias your team toward favoring inferior ideas:

“Attractive or pretty sketches can actually mask a pretty bad idea…” –Des Traynor

Best to remember that prototypes are for learning. So keep things simple…

“The very second I find myself filling in boxes and shading things, I ask myself ‘what are you actually doing here?’” — Braden Kowitz

Beautifying at this early stage can only hurt the objective at hand.

Go with paper, and practice…

So what’s the best defense against perfectionism? Doing a lot of paper prototyping. Paper prototypes can be created quickly and intuitively without getting absorbed by pixel pushing and they’re easier to throw away so you won’t get as attached. But even if you prefer digitial tools for ease of use and shareability, this calls for a similar approach.

When sharing your simple prototypes…

Avoid giving the impression that the design is anywhere near final.

Avoid acting emotionally attached to your prototype. This is not your baby.

Finally, “get out of the building” early and often. As Wexler points out, tracking down users and getting them to spend their valuable time reviewing your prototypes is hard to do. It often requires coping with a fair bit of rejection before someone even agrees to review your prototype, and even then it’s nerve-wracking to put your ideas out there for others to evaluate. Since this will never be an entirely natural or enjoyable activity for many of us, the best thing you can do is to put your user-testing skills to work on a regular basis with a continuous pipeline of users who’ve agreed to sit for interviews. If you use productboard to keep track of who needs what, you’ll always know who to approach when looking to learn more about certain user needs. (The users who’ve actively reached out to you in the past with feedback and feature requests are also more likely to agree to sit down for an interview.)