Startup Product Management

I’ve been working with quite a few startups over the past few years, usually in an advisory capacity, but sometimes more directly involved. Startups are essentially all about new product creation, so they’re a terrific place for product managers to do their thing, and it’s why I love working with startups so much. Yet I believe that the prevalent model for how startups go about coming up with their first product is terribly inefficient, and why so many otherwise good ideas never get funded or make it to market.

Here’s how it typically works. Someone with an idea gets some seed funding, and the first thing he does is hire some engineers to start building something. The founder will have some definite ideas on what he wants, and he’ll typically act as product manager and often product designer, and the engineering team will then go from there. The company is typically operating in “stealth mode” so there’s little customer interaction. It takes much longer for the engineering team to build something that originally thought because the requirements and the design are being figured out on the fly.

After 6 months or so, the engineers have things in sort of an alpha or beta state, and that’s when they first show the product around. Things rarely go well in this first viewing, and the team starts scrambling. The run-rate is high because there’s now an engineering team building this thing as fast as they can, so the money is running out, and the product isn’t there. Maybe the company gets more funding and a chance to get the product right, but often they don’t. Many startups try to get more time by outsourcing the engineering to a low-cost off-shore firm, but it’s essentially the same process with the same problems.

Here’s a very different approach to new product creation, one that costs dramatically less and is much more likely to yield the results you want. The founder hires a product manager, a product designer, and a prototyper. Sometimes the designer can also serve as prototyper, and sometimes the founder can serve as the product manager, but one way or another, you have these three functions lined up – product management, product design, and prototyping – and the team starts a process of very rapid product design and iteration.

I describe this process in detail in “How To Write a Good PRD,” but there are two keys: 1) the idea is to create a high-fidelity prototype that mimics the eventual user experience – it’s just fine if the back-end processing and data is all fake; and 2) you need to validate this product design with real target users.

In this model, it is normal to create literally dozens of versions of the prototype – it will evolve daily, sometimes with minor refinements and sometimes with very significant changes. But the point is that with each iteration you are getting closer to identifying a winning product. This process typically takes between 3 weeks and 2 months, but at the end of the process, you have a) identified a product that you have validated with the target market; b) a very rich prototype that serves as a living spec for the engineering team to build from; and c) you now understand at a much greater degree what you’re getting into and what you’ll need to do to succeed.

Now when you bring on an engineering team, they’ll start off with a tremendous advantage – a clear understanding of the product they need to build and a stable spec – and you will find that the team can produce a quality implementation much faster than they would otherwise.

This model of prototype-based product experimentation is increasingly becoming the norm in the manufacturing world, but for some reason this hasn’t taken off in software. I think we’re such an engineering-driven culture that we just naturally start there. But any startup has to realize that everything starts with the right product – so the first order of business is to figure out what that is before burning through $500K or more in seed funding.

I believe this model applies beyond startups to much larger companies as well. The difference is that bigger companies are generally able to underwrite the several iterations it takes to get to a useful product, but startups often can’t. But there’s no reason for the inefficiencies that larger companies regularly endure.

So on your next startup or new product development effort, give this approach a try.