I think it is time for us product management professionals to take a good look at ourselves and ask how are we measuring up as a discipline. Further, we need to ask how are we going to evolve to address the business challenges over this next decade. As I look into my crystal ball, I think the 2010’s will be the decade that we as a profession will move from adolescence to adulthood (the alternative being to cease to be relevant.)
There have been a lot of changes over the years, from the advent of the Internet, ever cheapening bandwidth and processing power, the ability distribute products with little transaction costs, and hosted services where we can gather usage metrics and push updates on our schedule. But if I had to pick one change, Agile development (including test driven development and continual integration) stands out to me as the most significant innovation for product management that has occurred during my career. I truly admire our development peers who have worked for the past fifteen plus years to realize these improved methods for building software. Yet, as beneficial as Agile development has been to our ability to create successful products, it has also left many of us facing the reality that we are now the bottleneck.
When development cycles were six to nine months or more, product management had plenty of time to figure out what to build next. Due to the long queue time to get any new feature realized, there was usually a large backlog of worthy projects. We are now much more nimble. We can exploit emergent opportunities, accelerate our learning, and adapt our plans quickly. Deciding what to build and gathering the necessary requirements has moved from being a periodic activity to a continual process. How do we catch-up to the increased demands on our time? I can tell you, the answer is NOT to hire more product managers. Instead, we must learn how to work more efficiently and match the productivity gains that the development community has made in the last decade and a half.
I believe many of the answers are to be found in the body of work called “Lean.” Lean was pioneered by Toyota but has been widely applied to service industries, healthcare, and, most importantly to us, product development. There is even a growing movement specific to software development. Lean starts with identifying customer value, something which we as product managers are pretty good at, and then looks to “flow” value to the customer. It is therefore focused on cycle time (e.g. how long does it take us to go from idea to market demand?), reducing queues, and shrinking batch sizes. It employs work in process (WIP) constraints to balance cycle times and throughput through the system. This smoothes the work load and prevents backups and large variability in the time to complete tasks.
In contrast to Lean principles, Product Management has traditionally been a large batch processing job. For example, we write lengthy PRDs that represent months of work for the development team. We then study how these large releases do in the market place and gather many more requirements to fill our next product requirements volume. Instead we need to think about creating a framework for the product but providing detailed requirements in small increments as engineering capacity becomes available.
Another major element is identifying inefficiencies, known as waste or “muda” in Japanese, that can be reduced or minimized. Waiting is considered one form of waste. Thus creating a large PRD that is not worked on for weeks or months is waste. A few other types of waste include specifying a requirement that is deferred from the release, a developed feature that is never used, and a product that is developed and tested but not released to the customer. This last one sometimes causes confusion. Think of it this way, if you have developed a product but not deployed it to your customers, you have inventory. You have effectively tied up your company’s money in the creation of this product, and it is not creating a single cent of value for your customers or your business.
This is why I say “It is time Product Management became Lean.” We need to learn to work more efficiently, and I mean 100% more or better. We need to experiment and adjust our methods. We further need process measures, such as cycle time, WIP, and throughput, so we can understand what works and tune our output to match development and other downstream processes. Lastly, we must realize we are breaking new ground. To succeed will require an open mind, a willingness to experiment and adjust, and lastly the courage to persevere. I look forward to an exciting decade of change and improvement for the product management professional.
GREG COHEN is a Senior Principle Consultant and Trainer at the 280 Group. He is a certified Scrum Master, former President of the Silicon Valley Product Management Association, and trainer to product managers from around the world on Agile development methods.