One of the advancement criteria for going from Walk to Run is to present evidence of the efficacy of the solution.
You have conducted experiments to find a way to help stakeholders overcome the problem or achieve their goal. You have a prototype, proof-of-concept (POC), or other high-fidelity demonstration that you’ve used to get feedback from stakeholders on the solution’s efficacy and their willingness to pay for it (though you may not yet have set pricing).
Many teams ask, “how can I prove that my solution works if I haven’t really built it yet?” That’s where prototypes and solution validation interviews come in. At the core, you need to start with something as simple as a sketch and slowly increase fidelity to get sharper validation.
A prototype is a an early, working model that allows for testing and user feedback before the final version is created. A prototype can be used to test features, processes, designs - anything that you may eventually make can be prototyped ahead of time. Prototypes are critical in that they lower the risk of spending a lot of time (and money) building the wrong thing.
Here is a good article on different types of prototypes for product development. New technology (like 3D Printing) introduce powerful new ways to prototype physical products, as discussed in this article.
A goal of a prototype is to make it realistic enough to validate your idea. If it’s not detailed enough, your users won’t be able to offer detailed feedback. If it’s too detailed or has more detail than is needed, you risk wasting time overbuilding or having users distracted by irrelevant issues. Build only what’s necessary to get the answers you seek.
For software prototypes, consider tools like Figma or InVision. For physical products, 3D printers are key (EPIC at BU is an excellent resource for physical product prototyping). For processes, a diagram created with a tool such as Miro can be helpful, and consider an automation tool such as Zapier or N8N to prototype workflows.
Prototypes are used to ask the question, “does the solution solve the intended problem?” But only your users can answer it. A good product process uses an iterative feedback loop:
A solution validation interview is the direct interaction with a user where the user interacts with the prototype to answer the question “does the solution solve the intended problem?” Note, this is not a survey! It’s a direct interaction where the user experiences the prototype and you discuss it.
The most common question we’re asked is “how many interviews is enough?” Unfortunately there’s no single number that is correct in all cases. Too few points of feedback and you might miss critical needs. Too much and you might find yourself with “analysis paralysis” by hearing many subtle different responses. Usability expert Jakob Nielsen famously suggested the “five user rule” where he suggests that “testing with just five users will uncover ~80% of the usability problems in a design.” But often that’s not enough (and we will definitely scrutinize a team that conducts fewer than 5). A rule of thumb is that the sample size for validation should scale with user-base diversity and complexity. If you are solving a very niche problem for a very specific type of user who experiences the problem in largely the same way as other identical users (and there are not many of them), then fewer validation interviews may be sufficient. On the other hand, a very general product intended for a broad consumer audience likely needs many more data points to confirm the solution's efficacy.
For advancing from Walk to Run, you will need to explain how you arrived at your conclusion that the solution is able to solve the problem. Include details about the prototypes you used (and how many iterations you went through) and about the validation interviews you conducted. It’s helpful to share quotes (or even videos) from validation interviews to show the feedback in the voice of the customer.