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.

Email to a friend

Sign up for the free newsletter here.

How many times have you seen the situation where a sales rep brings to the CEO a proposal from a prospect that says, “if you will just add these seven features to your product then we’ll buy your software and even pay you an extra $X.” Or, lest anyone thinks that this situation is unique to enterprise software companies, for consumer service companies, your ad sales person comes over saying that “a big prospective partner will sign a seven-figure advertising and sponsorship deal with you if you’ll just agree to these site integration and placement requirements.”

Either way, these are what are known as “specials.” A special is when a company gets a big check from a prospective customer or partner with the condition that you build into your product exactly what they say.

It is entirely understandable why large customers and partners may seek this arrangement. And if you’re a small company that’s strapped for cash, it’s also very understandable that your CEO might be more than a little inclined to agree. After all, you’re going to be adding features anyway, so “why not let this customer underwrite these features?”

So what’s wrong with doing a special? Well, one of the surest ways to derail a product company is to confuse customer requirements with product requirements. I’ve written in depth elsewhere about the reasons why you can’t count on customers to describe the product that they need, but to summarize: first, it’s extremely difficult for the customer to know what he needs until he sees it; second, customers don’t have the time to be constantly exploring what’s now possible; and third, customers don’t often interact with each other in order to identify common themes.

But even if the customer doesn’t have these issues, more generally it’s not clear that these are the best things to focus on right now. By pursuing these special features now, what work are you delaying? What is the business cost of that delay?

But even assuming these are not issues, it is still dangerous. How come? Because your job is to meet the needs of a broad range of customers. That’s what distinguishes product companies from customer software shops. If a year from now the market changes, you need to be able to quickly change and adapt. If you are contractually obligated to keep supporting a specific way of doing things, then your business will not be as nimble as it needs to be. Remember that every version of your product will have to be built, maintained, tested, released, documented and supported. It doesn’t take too many specials to weigh down a company to the point where it takes them months to do even the smallest release.

Don’t get me wrong. There’s nothing wrong with custom software shops. They provide an essential service for countless companies that need specialized solutions, and can often deliver that specialized solution at a fraction of the time and cost of in-house developed solutions. But custom software is a very different business than commercial product software.

So how do you avoid the pitfalls of specials? Undeniably it takes corporate discipline and experience to be able to recognize specials and be willing to walk away. This leadership comes from the CEO, but there is much you can do as product manager to help.

First, it is natural for any customer to want to describe their problem in terms of the solution they can envision rather than the underlying problem itself. But as product manager it’s your job to work with the customer to tease out the core issues and needs. You can help them to recognize that there may be other approaches to this problem that provide a solution they would like even better. Most customers do not really want to be running on a custom version of software. They want to be running on your mainstream product, the one that gets the most attention, support and improvement.

Second, consider looking at how you could keep your product general purpose but allow the product to be tailored/customized/extended by the customer or by a solutions provider. And then have ready the names of a couple system integrator/solution provider companies that can tailor your product to meet this specific need. You may need to partner with the solution provider so that your customer doesn’t have to manage two relationships and have to worry about finger pointing if there are issues.

So far the examples have mainly been in the enterprise software space. But the problem of specials is becoming increasingly severe in the consumer internet services space, where for many companies, advertising that is not aligned with the site’s objectives has significantly distracted or even damaged the user experience.

For many advertisers, their main objective is very simply to move traffic from your site to their site. If this isn’t your goal, you’ve got a strategic conflict. For some sites, like directories or search engines, this is fine, but for others, you end up trading short-term traffic for your site’s future. This really isn’t in anyone’s best interest. Consider the revenue model of LinkedIn versus Friendster. LinkedIn is providing value-added services to their members and partners, and keeping them even more engaged in the process. In contrast, Friendster was doing everything they could to get members to go learn about Pamela Anderson’s TV show. I completely understand why Fox might want to reach Friendster’s members, but have a harder time realizing why Friendster would want to make this such a prominent part of their user experience, other than for short-term advertising revenue.

I have found advertisers to be very interested in finding better, more synergistic ways to work together. When you have a strategy and a clear role for them, they are more than willing to work with you. They know that traditional internet advertising is of limited value, and they want something better as much as you do.

Whether it’s enterprise software or consumer internet services, it’s the product manager’s job to ensure that you’re building the right product, and that the product will be applicable to and usable by a wide range of customers.

Email to a friend

Sign up for the free newsletter here.