Category business of software

People ask me why we choose to build a prototype instead of building out an entire product from the start. The short and sweet answer is that we would build a product with the wrong features.

I could write a book on all the reasons choosing to build a prototype is better than building the full product, but for the sake of brevity, let’s focus on the most important reasons.

  1. Prototypes take less time
  2. Prototypes have a smaller code footprint
  3. Prototypes are easier to course correct
  4. Prototypes are optimized for experimentation

Let’s take a step back so I can explain what I’ve learned over the last 20 years building software. In the 90s and early 2000s, product development happened very slowly, even for startups.

How Products Used to be Built

It would start with months of market research and analysis to finalize the product strategy. Then, a technical architect, business analysts, and designers would design the entire product over several months. Next, engineering would be handed this design to build out the application according to an aggressive schedule, which happened to be too optimistic. This was followed by the QA department testing the functionality after engineering had finished the product release. Finally, the product would launch, with a large marketing budget behind it, on the pre-specified date.

That might all sound perfectly reasonable as it was the basis for how products were assembled for decades. What’s missing is user testing and feedback. This key piece led to much waste and failure. Some would do a beta launch to ask for feedback and to see how the product was used. Even then it was too late to avoid wasted development efforts if assumptions were off the mark.

This flaw in how products were built is why many applications included features that had no value to the customers. Whatever time and budget went into those features were wasted.

Generally, the process of building products is better today. But I frequently see and hear of projects where too much trust is placed in the original product’s vision and there is little attempt to validate the product’s assumptions prior to launch.

On one project, I witnessed the full development of a module only to find that customers wouldn’t use it because it didn’t match their workflow. It took this team 8 months to develop this module that would never be used. Why did they build it? The product owner made an assumption that he never validated with his customers.

This wasn’t just one unlucky project either. My peers have been saying similar things for decades. So how and why does this happen?

Product’s Mental Model

The why is perhaps the most interesting aspect of it. When a founder dreams up a product, they’re in fantasy land and building a mental model of what the product can do, how useful that is, realities of the market, and who the customers are.

This reminds me of a house of cards. A house of cards, if you’re unfamiliar with the term, is where we stack playing cards upon themselves to build a tower. The challenge is how tall can you build this tower before one of the cards slips and the entire structure collapses.

House of Cards

We can think of this product’s mental model as a house of cards. It’s made up of assumptions. These are the product owner’s interpretations of the world. For instance, some assumptions could be huge ‘leap of faith’ assumptions such as mainstream consumers would be willing to pay $10 per month for this service to as small as what to put on the label of an important button.

For a complex and rich product, there could easily be 100-200 assumptions that the product team will make. The issue is that many of these assumptions will be false. They might be slightly off or completely wrong. Perhaps the product’s foundation won’t be as shaky as a house of cards, but consider how many false assumptions will the product bear before it fails?

The Gamble

The gamble we make is that we will be right most of the time and can adjust for any false assumptions. How big of a risk is that?

Let’s say you spend 6 months having the team build out your product in stealth mode and then launch with a huge marketing and PR push. How quickly will you learn which assumptions are true and which ones are false? Will you know if slow adoption is due to lack of marketing, the wrong mix of features, or a market that isn’t ready for your solution?

The reality is you rarely know. If you’re lucky, you’ll get immediate and clear feedback. You’ll fail fast. A worse outcome is that things will grow slowly but it won’t be enough to sustain your business. How do you know what to adjust? How long can you slowly bleed cash before you find and address the false assumptions?

This sounds bleak because it is. We’ve all heard the statistics. Only 1 in 10 startups are successful.

So, here’s a question, when would you prefer to learn which assumptions are true or false? If you could test and validate the riskiest assumptions early in the process why wouldn’t you? This is the reason we advocate a lean prototyping approach.

Prototyping to the Rescue

A prototype is a vehicle to experiment with. Its purpose is to allow a product owner to validate their assumptions in the quickest, most efficient manner. They still have their product vision, but the roadmap is guided by proving that the product vision is based on reality, not fantasy.

With prototyping, you can control which assumptions you test and when. You can measure and use the scientific method to know whether the assumption is true or false. I recommend starting with the biggest, scariest assumptions and validate those first. Pick the ones that have the biggest impact on the direction of your product.

As you see the results of your experiments, you can evaluate if you need to pivot your strategy or if you should proceed as planned. As prototypes are lightweight, you can adjust them easily. If you discover a false assumption that would kill your product early, then you are able to save all the time and money you would have invested in a full product build.

What’s really cool is that you can turn this prototype into a production-grade application that you launch as your product. No need to throw everything away and rewrite it from scratch.

I have yet to encounter a client that didn’t care about their time or money. Prototyping is better for both. Furthermore, for long-term success, I see prototyping as the better bet.