One of the go-to business books in the 1990s was Reengineering the Corporation by Michael Hammer and James Champy. At the time, Business Process Reengineering was all the rage, and the book became the bible for thousands of consultants crawling around large companies looking to cut costs. Its impact to industry at the time was like the impact today of Four Steps to the Epiphany by Steve Blank and Lean Startup by Eric Ries combined. I was reminded of this book when talking with some clients this past several weeks about innovation and their product development processes. In their cases, they were aware that their product development process had grown too bureaucratic and complex.
Having been a product manager at multiple levels at both large and small companies, I have come to view the product development process primarily as an exercise in mitigating risk in strategy, schedule and/or technology. Generally these processes grow organically as a company matures, incorporating additional metrics, documentation and meetings to address issues that have cropped up in past releases.
Unfortunately, that's where the problem begins. As the development process blossoms into something more and more complex, it starts addressing corner cases — issues or situations that occasionally occur. Soon, product managers have 40+ page PRDs to write, engineers spend an increasing amount of time in meetings rather than developing, and marketing becomes an afterthought in the whole thing. Releases become gigantic burdens, and start to feel unmanageable.
Agile development and lean startup were in part a reaction to this overloaded waterfall approach to development. However, what I'm starting to see is that even companies that begin with lean philosophies are slipping into using aspects of the heavily-documented waterfall approach, because, well, that's generally what happens when issues aren't caught during the release cycle.
I get it. What companies want is predictability in the product development process. However, when the measurements are focused on the process (the how) and not the product (the why), you end up with incremental "innovation" with dubious prospects in the market. What's being done is primarily for the sake of the process, and not for the success of the product itself.
The people involved focus on following the letter of the process rather than the spirit.
Where we should be focused is on whether the product being developed is the right product with the right features for the right market.
How do you know when you have gotten to that point?
- People tout the large number of releases they have done in a given time period
- Long, complex templates that are rarely read in detail by the people who approve them
- Massive documentation for the process that requires a lot of resources to maintain it
- Marketing strategy and launch seen as only a handoff at the end of the process
- Regularly scheduled, epic hours-long meetings with spotty attendance to review status and signoff on too many product releases
And when you get to that point, it will be time to step back and reengineer your development process.