It’s time for product management to become lean…

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.

I fully agree with your points, but would also point out that my experience in software development has been that if product managers haven’t adopted lean methods they are already becoming irrelevant. The customer and market needs have been changing so rapidly that development no longer has the time to wait for detailed PRDs, and haven’t for quite some time. Product managers have been the bottleneck in getting problems to software development teams for many years, and those that have already transformed to iterative and lean methods of work have thrived while others have gotten less and less relevant.

To that end I believe that what we need is not a call to become lean, but rather a drive to establish a well defined set of lean product management methods that work exceptionaly well with current development methods that are applicable from company to company and position to position as we inevitably move from opportunity to opportunity.

I agree with Robert that the Lean/Agile wave has been pushing PM’s for some time now and that many have already to a greater or lesser degree, adapted. That said, even leading Lean thinkers like David Anderson are only now focusing on the upstream activities.

“@agilemanager Have recognized need for a workshop on “upstream kanban” for product owners, business marketing, strategic planning…”

Having attended the first ever Lean & Kanban conference in Miami…best conference ever!! (http://miami2009.leanssc.org) I can tell you that there was very little discussion on the topics of “what to build” or “why to build it”. This will not likely be true in 2010.

Regarding Greg’s statement that hiring more PM’s is “NOT” the answer…I’m kind of on the fence…especially when so many organizations are truly understaffed in this area to begin with. I think we have to recognize that product management is a big, diverse and somewhat fuzzy job that typically includes much more than writing PRD’s. Furthermore, when we seek to add greater levels of collaboration with our customers and development colleagues while still honoring all of the other commitments, PM WIP limits will surely be pushed beyond acceptable levels.

Conversly, going along with the NO MORE PM’s idea, perhaps it is time to re-visit the overall team and broader organizational structures (i.e. the system) to see if new roles & responsibilities can be created similar to what has occurred within the engineering organizations.

All in all, i agree with the premise that there is a tremendous opportunity to find better ways of doing work, to focus on what really matters and to put new measurements, tools and processes in place to help PM’s with the whole product management job.

Agree with your concerns. I love your Lean phrasing “PM WIP limits will surely be pushed beyond acceptable levels.” I hope we can all agree that until we start measuring PM WIP it will be hard to know what is acceptable.

As a secondary point, if we’re not measuring PM WIP, do we as PMs have a right to say we need more resources?

Just read this post after the link you provided on my blog. Great post. I especially like the analogy with “large batch processing jobs”. I have been guilty of writing PRD tomes myself! My worry is that business moves so fast, market and customer needs change so fast, by the time we finish capturing all the detailed requirements, and go through the entire development cycle and get to market launch, the product is already too old, because it is responding to customer needs from 12, 6 or even 3 months ago!

Hence, in the software space, I’m curious to see a more collaborative approach between Product Management and UX design. Being able to see visual representations of product concepts is invaluable in validating the product opportunity, and even at times the business model itself. What’s intriguing to me about the Lean Startup framework is being able to move quickly from concept through design, prototyping, coding and then deployment.