How to Make Bets That Pay Off: Effective Prototyping for Product Organizations

Many product organizations today face similar struggles: delivery cycles take longer than expected, timeframes are unpredictable, and schedules lead to unforeseen costs and outcomes. Often, designed, built, and delivered features go unused, ultimately failing to achieve the desired business results.

We’ve seen these struggles appear when organizations pursue a solution without understanding critical assumptions about their solution. Unfortunately, these insights only come after new features are released–a slow and expensive way to learn. To address this, product organizations need a way to understand a solution early and quickly. The key to evaluating these assumptions is to build and use effective prototypes.

Discovery Isn’t About a Better Plan

Many organizations have turned to product discovery as a solution to tackle these challenges. As touted in various articles and books, discovery promises several things:

• reduced waste,
• greater predictability,
• lower risks during the delivery cycle,
• and ultimately better business results.

However, despite these promises, organizations often don’t see these benefits.

The problem often lies in the way discovery is implemented. While discovery is meant to identify and define a solution, an overemphasis on crafting the perfect plan can undermine its effectiveness. In that situation, it won’t necessarily reduce waste or mitigate risk during development. Plans are often too speculative, and perhaps the most significant failure is the lack of identification and validation of critical assumptions.

Our solution is to take discovery a step further—it doesn’t end with a better plan. As Mike Tyson famously said, “Everyone has a plan until they get punched in the mouth.” We need to spend time understanding and validating our plans. Rudimentary prototyping or building something that allows us to test or validate assumptions is often missing. Early prototyping in software projects helps uncover organizational issues, internal turf battles, and hidden technical complexities.

At SEP, prototypes are key to the Validate Solutions phase of our product process. This is where product discovery takes place. We focus on a specific opportunity on the product roadmap and figure out what types of solutions are best suited to meet the need. Making and validating prototypes allows us to quickly learn, evaluate risks, and refine our approach before we spend the resources to build and deliver a full feature.

To Truly Understand a Solution, Build Something and Use It

Prototyping is key because we only truly understand the solution once we start building it. Sometimes, we don’t even fully grasp the problem until we step into the solution space. There are various types of prototyping, as identified by Marty Cagan: feasibility prototypes that test technical feasibility, low-fidelity and high-fidelity prototypes, live data prototypes, and hybrid approaches combining these methods (learn more about flavors of prototypes here). The choice of prototype depends on the desired learning outcome, which Marty typically maps to one of four categories: feasibility, usability, desirability, or viability.

In “Testing Business Ideas,” David Bland offers a great resource for thinking through different types of prototypes and methods for learning (what he calls experiments). I’ve summarized some of that here (notice he only uses three categories. In this case, he has combined usability and desirability into one theme).

The Three Truths of Effective Prototyping

To make prototyping successful, we rely on what we call the “Three Truths of Prototyping”:

1️⃣ Adopt a Different Mindset

Not all ideas are correct, and many assumptions remain unstated. As my friend Jeff Patton says, we should focus on “building to learn” rather than “building to earn.” Our prototypes are small, often non-scalable, and sometimes even disposable. This is easy to say but much harder to do in practice.

In my experience, teams struggle to see this when they are deep in the details of the solution space. We must understand there are distinctly two types of work—Discovery and Delivery—and they should be managed differently.

2️⃣ Build Just Enough to Validate

Sometimes, this involves using real code; other times, it might just be a façade or a prop for discussion. The goal is to create just enough to achieve a learning outcome.

Different assumptions lead to different types of prototypes to generate that learning. Be clear about what you’re trying to learn and why. Understand how you’re going to gather evidence and how you will know you have enough to move on. We often use a simple table like this:

3️⃣ Involve the Right People

This means including product, design, AND engineering from the very beginning. Engineering is often excluded due to modern design and prototyping tools, but this is a mistake, especially in enterprise software solutions. Engineers play a pivotal role in determining the technical feasibility of solutions and should be part of the prototyping process.

Understanding the existing enterprise architecture can clarify what’s technically feasible within the given constraints. I’ve observed that understanding the existing architecture can also unlock new and different solutions that could easily be overlooked.

Share the Consequences of the Prototype

Finally, after designing and building our prototypes, we make a concerted effort to present our findings and proposed solutions to key stakeholders. This step is often overlooked but is crucial for creating a shared understanding of our goals and how early assumptions might affect our schedule and commitments.

In summary, this blog post highlights the importance of effective prototyping in overcoming common challenges faced by product organizations. By leveraging various types of prototypes to validate feasibility, desirability, and viability and following the “Three Truths of Prototyping,” product teams can reduce waste, increase predictability, and ultimately deliver better business results.

—

Integrating the practice of prototyping, especially rapid prototyping, early in a project is highly recommended. You’ll find hidden technical complexities through a quick build, unlike when the focus is on features and backlog. Ultimately, all the learning from effective prototyping in Discovery provides more accurate forecasting and results in better project outcomes.

You Might Also Like

• How Product Discovery Maximizes Your Chances of Success
• In Product Strategy, Ideas Are Important, but Execution is Critical
• Case Study: Product Discovery Benefits in a Health and Sports Performance iOS Mobile Application Project