See my previous post to understand how I got here. The hypothesis is that product development is messy except for the most disciplined. After talking to a number of great product people, I have a theory for how great product can be developed while being customer centric (aka lean).

The Virtuous Cycle of Lean Product Development

The Product Management Funnel

I think of product management as a funnel. At the top are all of the ideas your team generates. If you’re a lean startup, that’s hopefully driven by customer interviews, website and landing page behaviors and support interactions and of course the occasional green space wild idea.

As product manager, this is the most dangerous step. Once you have more than a few employees, it’s easy to have these ideas overflowing and interfering with the whole product process. Multiple teams I spoke with have been using their project management tools to capture these ideas which leads to a huge mess (one such company had over 4,000 stories in their icebox!) and a major time suck (one vp of engineering is spending an hour + each day managing these ideas).

The problem is project management != product management. The only thing that should be in your project management tool are key bugs to fix and what you’re building now or in the very near future (ie next sprint). Everything should be clearly defined and in a language and structure preferred by your engineers. All the evolution of the product from idea to customer validation to final prioritization should be done outside the project management tool.

The Rest of the Funnel

The Full Product Funnel

Going back to the beginning, you need discipline at the top of the funnel; the best product people I spoke with are requiring a shred of data tied to an idea to make it into their coveted ideas list. They also often expect a disciplined approach to what goes in by having people state, “Feature X will move Metric Y by Amount Z” so it’s clear why the feature needs added. In earlier stages that may be in a “Hypothesis vs. Metric to Invalidate” format instead.

The key of this step is effectively managing the signal to noise ratio; for every 5-10 ideas that come in, you may only make 1 or 2. Even the less disciplined product managers I spoke with have some type of hot-lukewarm-cold system for trying to rank ideas. To avoid the 4,000 stories in your icebox (or anywhere else) you have to be disciplined on dropping stale ideas and focusing on what matters now. When you’re a growing startup, where you were 3 months ago is dramatically different from where you are now so why keep those stories cluttering your system now?

After wrangling the initial feeder of ideas under control, you need to effectively refine the ideas that make it into your system and allow the most important ones to rise to the top of your list. As planning for your next sprint begins, you need to prioritize these ideas and balance with other existing projects, bugs and other demands.

Once you’ve settled on what you’re going to have engineering build next, you need to engage your team on the ideas you want to implement; you may need copy from marketing, stories from support to describe customer complaints, links or screenshots from analytics to show present activity and relevant customer development notes. All of this feeds into the project management tool you have, but now it’s uncluttered and your engineers are much happier and efficient. Unless you’re github or heroku, chances are your engineers don’t understand the customer they’re building for perfectly so all this structure makes it easier for them to see what’s going on and then adapt it to fit the project management tool they’re using to track building.

As an added bonus, there’s transparency for your other employees as they engage in more than just the initial ideation process. It also means sprint planning no longer needs to have all hands at it as they’re already well aware of what’s going on and have had opportunities to contribute as needed to the stories now being generated in the project management tool.

Completing the Virtuous Cycle

We all know this image so well as the core of what lean startups is all about, but how often is this cycle cleanly implemented? The project management tools out today all do a great job on the build aspect, but what about measure and learn?

The funnel process I described above captures the learn aspect as you engage your team for ideas and validation. All that’s left now is to measure.

After you build something new in your project management tool, your engineers will submit it for some form of approval. Once approved, it universally ends up disappearing into the ether, because the project management tool is built to track what you are building or about to build. After building isn’t part of their process.

To close the lean loop, you need to look back and see if that feature actually moved the needle. This needs to happen within 2-4 weeks of building it; sooner wouldn’t be enough data and longer would be distorted due to other things you’ve likely built by then. This last step of learning should help you refine your instincts and feed back into what you build. This is one of the biggest challenges as Eric discusses his principle of Innovation Accounting in his book.

The amazing thing I discovered in so many of my interviews was how rare it was to do this measure step; how can you improve your accuracy without seeing if you hit the target?

—

The Product – Lean Opportunity

What started as an investigation of lean startup opportunities has broadened to helping teams close the loop in managing a product lifecycle. I believe there is tremendous opportunity to build a platform to aide on both sides of the project management tool and much wider than those adopting lean concepts officially (as we all know, being customer centric is not a new concept).

—