Developing Products in Half the Time

By Preston G. Smith, Donald G. Reinertsen (1997)

We are reminder of the story if the wise man who was approached by a youth who asked him how king it would take to walk to Athens. The wise man simply replied, “Get going!” The youth, disappointed, concludes that he would not get a straight answer and began walking in the direction of Athens. After the youth had taken about 20 steps, the wise man called out, “About four hours!” The youth turned and said, “Why didn’t you tell me that when I asked before?”

“First I had to see how fast you walked,” said the wise man.

My Notes

Faster isn’t always better (e.g., higher quality or lower costs may derive a higher benefit) although it means more flexibility.

💡 Do the math. Create a baseline model, starting with these key values:

Then, create some variations:

Then use these numbers to help support decisions/discussions. E.g.,

☝️ Conclusion: let’s take the hit on the costs overrun and avoid the delay

The rest is fairly lean/agile/servant-leader/etc: incremental dev, staying flexible, changing plans, contact with customers, not freezing specs, small teams, team cohesion, focus, generalists, involving the whole team from the beginning, removing critical paths, queue management, continual improvement…

💡 Great questions for everyone to be aware of all the time:

Let people fail:

Nothing saps innovative more than someone’s second guessing the decisions made. This is doubly true when that person correctly spots mistakes. Second guessing must be controlled, and the team must be supported so that it will develop its own new operating style and the skills that go with it.

A Native American proverb says that good judgment comes from experience, and experience comes from bad judgment.

💡 Projects should deliver two outcomes: the product, and learning about the process.