Product Development – The Great Unknown

Decision making is fundamental to any professional activity. The study of “decision bias” is a fascinating subject. These studies show that the root cause of most faulty decision making is the wrong assumption. One of the most common faulty assumptions in the product development world is that the development budget and time is an obvious thing. This assumption leads to a world of trouble which typically goes something like this: The customer will ask how much to design a new product and the Engineers answer is about $1,000. The customer responds excellent, make it happen.

At some point, the engineer has spent countless hours and is over the $1,000 budget and He is still not done creating the product – which has likely changed many times by now. Customer says “not my problem, you agreed to $1,000″. Engineer says, “I cannot afford to work for free” and then the relationship ends. This scenario is a typical lose-lose situation. The customer does not get what he wants, and the engineer did not get what he wanted. Both sides lose because they both assumed that the product development budget is a knowable thing – it is not. Sure, you can accurately estimate a small portion of the budget – layout a PCB, write a piece of code, do some verification test, etc.; but, you cannot know the budget from day one of product ideation. The actual cost is only knowable after the product is finally in production. Now, I am sure that half of the people reading this are saying to themselves “Steve does not know what he is talking about, I am always on a budget.” I understand this position, and I have had many people try to convince me that they know what a development budget is going to be.

But every time you dig a little deeper into the details, a very different story unfolds (of course, each example given is a “one-off exception,” or about things they had no control of). However, even the diehard skeptics on this issue recognize that it is challenging; therefore, instead of debating the subject, let’s talk about how to deal with it. Maybe it is not impossible, but it is at least difficult, so having a few tools for dealing with it is going to be helpful.

Product development is an investment. You are going to spend money for many months, if not years, in hopes of creating revenue at some point in the future. This investment has some theoretical ROI – that is, the future payments, when discounted for the time value of money, have some return on that investment. Ultimately, the goal of the project is to make this ROI as big as possible, and like any good leader, it is essential to communicate the goal to your team. Reminding everyone that the breakeven number for this project is $XX is a necessary input to decision making. Product Development is complicated, and rarely does any one person have all of the knowledge. Information needs to be pushed to places where the people with the experience have the information they need to make effective decisions, and the goal of the project is indeed necessary information for all knowledge workers on the team to have.

It amazes me how many times I talk to engineers working on a project that is already dead. Strangely, all the engineers know it is dead – it is management who thinks it is still alive. All the engineers can see that the original vision of the project is not going to be achieved, and there is no reasonable place to pivot. Management sees a lot of money already invested and has a “failure is not an option” motto.

Break projects into small steps and make a go/no-go/pivot decision at each stage and do not be afraid to kill a project. All ideas do not turn out to be winners – and sometimes that is not clear until some money is spent. This is normal and to be expected. Make sure everyone on the team understands that some projects will be killed, and this does not mean anything other than it is part of the processes.

It is okay to say “maybe this project will cost $XX and take XX months” – but do not pretend that is something that is anything more than a guess. Do not commit to this number as you will only be setting yourself up for failure. Instead, break the project up and commit to smaller chunks. It is OK to say the Requirements Document will cost $XX and XX weeks, and we will see what we have when we are done with that phase and make a decision to move forward or not.

I know many companies who failed miserably at OPD (Outsourced Product Development). All of these failures had one thing in common – they were all fixed price. If you are using OPD, do not ask for a fixed priced bid. Hire people you trust, and that keep good records of their time. Pay them by the hours that they work, just like any other employee. Fixed price only sets up a situation where the OPD company has no choice but to decrease quality in order not to lose money, and fixed pricing makes them very resistant to a pivot.

Product development is challenging, but as Apple (and many other companies like them) have shown us, it is the path to true differentiation and value creation. It will never be a perfect process, but that does not mean it cannot improve.