How To Know Which Prototype To Build
& A Breakdown of My AI Business Prototype
In the previous article in this series, I walked through how to define & validate a winning product strategy.
With the presentation automation product I am currently working on, we managed to get 39 signups on our Beta waiting list from one single LinkedIn post following this approach.
This gave us the confidence to say,
“This offer - building engaging presentations in minutes - seems to be something our target market values. Let’s now move to the next step of building a solution.”
But where to start?
And what to build?
Why the MVP Model is Dangerous
Before jumping into simply building anything & everything you can think of, prototyping effectively requires discipline.
It requires you to avoid the mistakes that many product teams fall into when building an MVP (Minimal Viable Product):
Rarely minimal, as team jump straight to trying to build a full version of their product, which takes months, rather than days
Rarely viable (i.e. actually delivers the value you promise in your offer), as teams see the MVP as an excuse to push a crappy version of what they eventually want to build
Usually focused on the wrong type of risk: Teams tend to commit to a certain solution (e.g. a meetings bookings app) & then test out small usability issues, such as the text of a button, or the info hierarchy on a page). Instead, they usually should be focused on far more important things: Whether the user even cares about the solution as a concept, or whether we can actually build the thing
Usually digital-focused: Rarely do I see teams hack together an early prototype with different, pre-built tools, or doing some things manually, or being happy to test out something a bit messy. Instead, most teams try to jump straight to building a full, custom-coded solution
My Team’s Story
As an example, as my team start working on our first presentation prototype, it would be easy to try to build not only the automation of creating the presentation outline & content, but also, all the features of editing a presentation, such as editing an image, or adding a graph to a slide. Instead, we had to be disciplined in what we felt we needed to address first - a topic I’ll come to shortly.
A New Approach to Prototyping
Instead, rather than using clever-sounding words like “MVP” or “Agile”, prototyping is actually surprisingly simple.
It can - and should - be stripped down to focus on the most important part of product management:
Managing risk.
Specifically, there are 3 key risks we need to be laser-focused on:
Viability risk: Does somebody actually value what we are offering them? And how do we know that they will actually use - and ultimately pay for - this product?
Feasibility risk: Can we actually deliver the value we are promising them? How do we know we can overcome possible technical or operational challenges?
Usability risk: Can they actually get to the value as they go through the user journey? Or are there too many usability issues preventing them from doing so?
For multi-product businesses, we also have business risk, which is essentially: Does this product tie into our broader business strategy? Is it relevant to us as a business?
But why is understanding risk so important to prototyping?
The risk we think is most important to address at any point in time will determine what our prototype should look like.
i.e. If feasibility risk, we should pick a prototype that validates feasibility risk.
Because effective prototyping is not about how to build a prototype.
What’s important is selecting the right prototype to work on.
My Team’s Story
For our first presentation prototype, for example, my team see all of these risks as important to address, but are focused initially on viability risk. Why?
There are great presentation tools out there already (e.g. Powerpoint). There are also great AI presentation tools out there (e.g. Tome or Gamma).
We therefore need to validate that our unique value proposition of focusing on storytelling when building a presentation is something our target audience actually value. If not, we’ll end up building a nice presentation tool that lacks differentiation, won’t attract an audience and that will ultimately fail.
5 Prototype Models
Once you’re clear about the main risk you need to address, it’s time to select a prototype model that best addresses that key risk:
Smoke test: If we’re not clear that the user will actually value our product, we want to focus on delivering the value in some way to them, then see their reaction. That could be a simple MVO, where we put our offer on a landing page, reach out to our target market & see whether they sign up. It may be that we even deliver the value of our product manually. For example, if you’re building a garden planning tool, why not just use a simple form, create a plan yourself, send it back to the user, then see whether they use/pay for that plan or not
Feasibility prototype: Where we are confident in the value we are promising, or see everything depending on feasibility (i.e. can we actually deliver), we might build a feasibility prototype. Say we’re Grammarly, a Chrome extension for correcting your grammar. We can be pretty confident in our value prop i.e. that people want to communicate better. But we don’t know whether we can actually analyse their writing (emails, Slack messages, etc.) in a way that gives them useful, accurate suggestions & corrections. We therefore might build our language analysis tool, feed in lots of text & see whether it seems useful & accurate or not.
Low-fidelity prototype: Even simple paper mockups can be useful at times. Although too far away from a real product to validate risk, they can be powerful as a way to align internally on what we aim to build, or to get some initial feedback on value & usability risk
High-fidelity prototype: A Figma prototype, showing realistic looking screens that you can even click through, .can be a great way to validate usability risk &, to some extent, value risk. Why? If done well, many users will assume this is the real, functional product. You’ll therefore get a good sense of what they understand (usability) and seem to value in your product (viability). Beware though! Too many product teams jump to this model as a default option, assuming that just because someone seemed to enjoy the Figma prototype they will use & buy the real thing. Unfortunately, there is a big difference between a user saying they like something whilst you test it with them to them using the real thing on their own, without you breathing down their neck. We therefore only validate viability risk to a small extent with a high-fidelity prototype
Live data prototype: If it doesn’t require a huge upfront cost of time/money/effort, then a live data prototype is the gold standard. This could be a no-code prototype with full functionality, analytics & database. It could also be a quick, hacked together coded solution. Live data prototypes are, in the eyes of the user, the real thing, with real functionality and an ability for them to use it on their own. Say we want to build a parking app, we may hook up to a real, live traffic API & put it in a simple interface, before allowing Beta users to download & actually use the app for real
Our Presentation Product: An Example Blended Prototype
As with everything with product, sometimes it makes sense to break the rules.
To follow the principles, rather than blinding selecting from a checklist (like our list of models above).
For my team’s presentation automation product, we started by asking ourselves:
What is the most important risk to address?
In our case, viability, because of strong competition in the presentation creation market.
Because we are basing our product on ChatGPT’s API, we realised that ultimately viability was closely aligned with feasibility.
I.E. If ChatGPT could give us what we felt was useful output to plan a presentation, we could try to get that into a user’s hands & see whether they thought it was useful
We therefore proposed a blended prototype:
A high-fidelity prototype made in Figma to walk the user through the key steps in the journey, including:
Setting a presentation objective (text input + some suggestions)
Defining the audience
Defining a storytelling framework to follow
Text input to add any additional info
{Skip to Prototype 2}
View an example presentation outline they could edit
A feasibility prototype:
Custom built ChatGPT-based app with pre-defined prompts (reflecting what we ask in Figma)
Test examples to see what output we get from ChatGPT
Blended together, this is almost a live data prototype, as it delivers real value with providing a unique presentation outline, but within a generic Figma prototype that doesn’t actually then show this unique outline.
(Instead, it’s more a smoke test where we try to deliver the real value in a more messy, manual way.)
Once you build, how to test it?
For running our first few user tests, we asked the user to walk through the Figma prototype & their thoughts. As they did so, we were looking for signs of what they seemed to value (if anything) and picking up any usability issues.
As they input options for defining the presentation details, Conor, our data scientist, was manually typing this into his feasibility prototype.
When it got to the Figma screen showing a loading bar stating it was “Generating the outline…” for the presentation, I asked Conor to screen share & show the results of his ChatGPT prototype that he had loaded up in the background.
We then asked the user to share their thoughts on the outline it generated, before switching back to Figma to see what they thought of the outline editing process.
And, by doing so, managed to hit upon all 3 risks in one prototype experiment:
Viability risk: Was the output seemingly valuable to them? Did they suggest they might use this in their next presentation?
Feasibility risk: Were we able to generate a useful presentation outline?
Usability risk: Were there any blockers in our Figma designs that prevented them seeing the value of the product?
As I write, we’re gathering feedback & running a few more tests before the next key step:
Iteration.
But how to iterate? And how to iterate methodically, in a quantitative way?
That’s a topic for next week’s blog post.