Product Discovery

Have you seen this situation before? Your company gets all excited about a product idea, and as product manager you are asked to define it. You are told that the engineers will be finished with their current project in 4 weeks, so that means take all the time you need, as long as you are ready in 4 weeks.

No problem, you say (after all, sometimes you’re only given days, so 4 weeks sounds great). You’ll even use all the best practices Marty is always ranting about. You’ll start with an opportunity assessment to understand the problem to be solved, then you’ll spend quality time interviewing real users, and identify a preliminary set of requirements, and by the start of the second week you should be able to to work with an interaction designer on a prototype, and in the third week you’ll do user testing with the prototype, and in the fourth week you’ll flesh out the details of the use cases and review the prototype and spec with engineering.

These are all great practices. But what happens isn’t usually so great. During your initial user discussions you find that users aren’t as excited about the idea as your management was, and/or you struggle to come up with a prototype that users can figure out, and/or the users aren’t excited about the ideas in the prototype when they test it. But the time is up, the engineers are ready, and the result is that during the next three to six months, engineering proceeds to build that same unusable and unexciting product that you saw in your prototype, and you ship, and then your management is of course disappointed in the results.

The problem isn’t the reliability of the software, so the engineering team isn’t to blame – after all, they just built what you asked them to – so everyone knows it’s your fault as product manager.

You know that it doesn’t help to talk to users, create prototypes, and test with users, if you don’t adjust your course based on what you learn.

This notion of requirements and design as a sequential, predictable and scheduled phase in a product development process is so ingrained in our industry that it’s often one of the most difficult habits for product organizations to break.

But they do need to get past this. Product organizations need to come to terms with the fact that the product invention process is fundamentally a creative process. It is more art than science.

I prefer to think of this phase as “product discovery” more than “requirements and design.” I think this nomenclature emphasizes two all-important points:

First, you need to discover whether there are real users out there that want this product. In other words, you need to identify your market and validate the opportunity with your customers.

Second, you need to discover a product solution to this problem that is usable, useful, and feasible. In other words, you need to design your product and validate it with your customers and your engineering team.

Sometimes this product discovery is straight-forward. Other times it is extremely difficult. In my experience, it’s not so hard to discover and validate the market opportunity, but often it’s very challenging to discover the solution. Even with the help of great designers and great engineers, some problems are just truly hard (at least many of the ones worth pursuing).

The pharmaceutical drug industry provides an extreme example. The market discovery is usually not very hard; no shortage of good problems worth solving (like saving your life, extending your life, or improving the quality of your life). The hard part of course is discovering a product solution. Drug companies go into this “discovery” phase fully aware that there’s no guarantee they’ll come up with anything, or how long it may take. As an industry, they have to come to terms with this element of uncertainty (and this risk is priced into their products).

Yet with software, even though we all know it is very hard, and we know that the majority of software releases fail to meet their objectives, we still insist on scheduling the discovery phase like we’re planning the construction of a house.

Management especially struggles with this notion of product discovery. I think there are two underlying reasons for this:

First, the discovery process just isn’t predictable. Management fears you may spend months and end up with nothing to show for it. At least if they go ahead and build they can say that they shipped something. It’s the same reason why many managers are uncomfortable with Scrum. They want to know how many 30-day sprints it will take before they’re done.

Second, the perceived constrained resource in just about every software product organization is the engineers, and the thought that an engineering team might be sitting around with nothing to do but play Foosball just drives management nuts.

Ironically, it is precisely this reasoning that leads directly to wasted engineering resources.

Realize that almost every company does this discovery process I’ve described here, instead of using one prototyper for a few weeks, they use the full engineering team for full release cycles to build the software that is then QA’ed and deployed into production systems. This is why it typically takes so many companies three or more releases over one to two years to get something usable and useful. They are using the engineering organization to build a very, very expensive prototype, and they use their live customers as unwitting test subjects.

This is also why so many startups fail. Most startups simply don’t have the funding to go two years before they gain traction. So they hire their engineers, take their best shot, and see what happens.

So with startups as well as large companies I try to get them to focus their energies on this much faster product discovery process, and once they discover the solution that works – one that is usable, useful and feasible – then it’s all about the engineering. Until that point, they don’t have to hire so many engineers right away, the engineers they have can and should actively participate in the product discovery process, and to a degree the engineers can prepare the infrastructure while this discovery is going on.

You can help your management to understand the nature of the product discovery process. If you consistently emphasize your obligation to ensure that what engineering builds must be useful and usable, and enlist their efforts to discover a successful solution, you’ll start to move their focus to this most critical stage of the product development process.