The Broccoli of Product DevelopmentThe Broccoli of Product Development

Everybody knows that they are supposed to eat 4-5 servings of fruit and vegetables per day, but how many people actually do it? Some of us try, most of us fail, and we tell ourselves we’ll do it right in the future. There is an analogy in product development that is very similar – building solid requirements prior to development. They are the vitamins and fiber that lead to a healthy product! Anyone who has been building products recognizes the need for a well-written product requirements document (PRD) before starting design and build of their product – most people have been burned by late requirements before. So why do companies continue to throw money at prototypes and design/build cycles before they’ve gathered requirements from stakeholders and customers? 

Pressure leads to bad decisions 

In any product development lifecycle, writing a PRD is one of the first things to do. But the pressure of producing results, or showing something to management, the Board, or a customer, usually results in compressed timelines and quick-turn proof of concept efforts that don’t allow time to follow the normal process. Companies love to throw money at an 8-week prototype because it produces something they can show off. Nobody wants to show the Board or a customer a sparkly new PRD. The problem is, after they show off their new prototype, they hear a ton of things that the customer or manager (the people with the money) would LOVE for that product to do. Maybe it’s something completely different than where the product was going – now the team has a problem. Your show and tell led to eating the meat and potatoes; it’s too easy to ignore the veggies when they are sitting next to a juicy steak.  

Now we are in a hole, so let’s keep digging

The project team now has spent a bunch of time and money, has people excited about what the product can do, but still hasn’t written down all the things the product should and will do. But unfortunately, most companies don’t reach for a salad, they order more fries. They create another prototype to answer all the comments they heard, or worse, they continue to modify the first prototype until it becomes a production unit. Somewhere down the line, they realize they need solid requirements to address, for example, what are they going to test the product against? Hopefully the design hasn’t gotten that far – if it does, you end up with requirements that clearly describe what the prototype currently does – instead of what it should do after researching the requirements with the stakeholders. It looks like an owner’s manual. At this point you regret not eating those vegetables – it would’ve been far easier to do the PRD upfront. 

There’s nothing wrong with a burger now and then

There is a place for prototyping. Even quick and dirty prototypes – if you can sketch one up or cobble one together while you are in Phase Zero (the Concept Phase), it will give folks the visual they need to help you build your PRD. Once you’ve done a few turns on the PRD, then do a design/prototype phase. Feed the results back into the PRD and do it one more time. If you get the PRD going early you will save a ton of rework, late scope changes, and wasted time/budget. Ask any doctor. It’s just a matter of making it a habit.

—Don Biszek