Good
Cheap
Fast
Holy Trinity of Product Development…
The dream for any project is that it’s good (as a minimum), quick or on time and cheap.
But for most it remains just a dream.
If you had to prioritise, I’d suggest picking speed…
Working fast gives you time to test and improve which makes you good. Working fast also saves money, as the largest cost in many projects is usually the time based wages of the staff involved.
Once you’ve identified a need, the sooner you can provide a product, service or offering that meets it, the more you’re likely to earn before the need disappears. The more you earn from this project, the bigger a difference you can make with the next project, and so on.
If you are late to a new market, you need speed in order to catch up with the “Pioneers” or the other “Fast Followers” (that we’ll explain in a later section) and their first mover advantage.
It’s good to be responsive to changing customer needs
To maintain a market lead and stay ahead of the competition
It may reduce costs
HP used to take 54 months to develop a new product, they now take 6.
Three ways in which the literature on product development says you can (at the least) halve your development time, so taken all together might see an 8 times improvement in speed:
Having dedicated, co-located and cross-functional teams (all the right people in the same place together without too many other things to be working on).
Interesting to see how the remote working constraints of COVID-19 will effect this one.
Controlling overload so that no one or no team is struggling to keep up with their commitments. People need time to be creative and to find better solutions. They most often cannot do this if they are constantly jumping from one project to another.
However having two projects on the go at once is the best utilisation of time, any more and productivity starts to drop off quickly.
Reducing the “Fuzzy Front End” time between realising something needs to be done and actually starting to do something about it.
The fuzzy front end if your house is on fire is nothing, you would immediately start to react, call the fire service, rescue your family etc… However the front end on a piece of university course work might wait until the panic monster arrives the night before it’s due.
It’s possible to be too fast, the faster you go the more wasteful (or expensive) you can become as you prioritise speed over all else. This will require some thought for each project, but the sweet spot for most projects is to tolerate some inefficiencies in order to gain some speed over your competition.
Intel used to take 12 months to develop a new motherboard, they now do it in 3.
The “Fuzzy Front End” and how to reduce it.
According to Smith and Reinertsen in their famous product development book “Developing Products in Half the Time”, the fuzzy front end is the very wasteful time at the start of any project where nothing value adding gets done. This is due to poor management, a lack of focus, procrastination, a lack of incentive etc… and can be up to 50% of the development time for any project. “Leaving things to the last minute” essentially defines everything up until that last minute as being in the fuzzy front end. As a result it’s the cheapest place to find more time! So for any project, plan ahead, get going early and set yourself deadlines to pace yourself. In the 1980s IBMs internal processes were so slow that their fuzzy front end was 3 years. 3 years from the moment they identified something needing to be done and when anyone would actually start to address it, not solve it, just start to look into it!
Word of warning, some confused definitions
Some researchers (Koen et al, in what I believe to be an ironically titled paper: "Providing clarity and a common language to the 'fuzzy front end’”) unhelpfully expand the definition to be everything from the wasted time at the start through opportunity discovery, idea generation, selection and even technology development. So whilst this part of any project development may be messy and confusing it’s unhelpful to repurpose a term that was already in use and meaning one thing to now expand that meaning to include the entire design and development process.
If you hadn’t guessed, I prefer Smith and Reinertsen’s definition.
Tim Urban, the creator of the much read blog Wait But Why had some great insights into the idea of the fuzzy front end and procrastination, which I believe also supports Smith’s definition. Watch his short TED talk here a summary of the concept on a personal level, but the logic is the same for businesses.
