I do not like the agile manifesto. It does not resonate with me as a product manager – someone responsible for guiding successful products to market. It’s very focused on the needs and desires of developers, and much less so on my needs and desires, or more importantly, on those of my customers and prospects. But, I love agile, and I believe agile – and its follow-ons, like lean and kanban – are critical to enable people like me to create and deliver new products that create value in the world.
What is it about agile that turns me on, while the agile manifesto itself leaves me cold? I’ve made a stab below (and made other points elsewhere) at a high-level explanation for why I like agile and why I think it works. It’s based on some tenets or axioms that lead to the conclusion that an approach like agile is generally superior for delivering value than more traditional approaches like waterfall. I guess these are my version of a manifesto, one that leads to agile and lean when they are applied to product development:
If you combine those tenets “agile” naturally pops out: Don’t focus on optimizing a large set of work, instead focus on completing the most important piece of that work, as quickly as you can, and deliver it. Since you’re only delivering a small chunk, you don’t have to predict very far into the future. And you’ve chosen the most valuable thing to work on, so you know your market will want it. Because you are working in small chunks, if the market changes its mind, you can quickly change your plans in response. And by always having only a small amount of work in progress, you reduce waste and create more value.
In this analysis, though, it’s not really agile that pops up, it’s lean, or more accurately, “Kanban” (at least as practiced in software development). No matter how long your sprints are, some of your features will take longer than the sprint length to deliver to the 80% level. This is a big problem for agile methodologies, because a feature that’s only at the 60% level (which perhaps you can get done in one sprint) doesn’t provide significant business value, and usually neither you nor your customer gains by delivering it at that point. (There’s clearly another blog post in this topic of 60% value versus 80% value.) And therefore Kanban’s approach, which I will simplify as “take your three most important features and work on each one feature until it’s deliverable, then deliver it, and then start on another feature,” does a better job of delivering value to the market and reducing work in progress.
I’ve used the term “lean” above, and I’m really talking about the concepts that come from lean manufacturing. But these ideas are also intimately tied to the “lean startup” mindset as well. One of the key insights of the lean startup is that instead of guessing or predicting the future (all the things I’ve said you don’t want to do), you create hypotheses and test them, getting real data about how customers respond to your product and its features. Agile and lean and kanban again perfectly align with that approach:
I don’t know why I feel the need to reinvent things, like the agile manifesto, but there you go. I’d love to start a conversation about this, and if other product managers resonate with my ideas here, perhaps we can refine them and put out our own manifesto on how to deliver more value to market, faster.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.
Love this Nils…. great job. One piece that's missing here, that I often share with other product managers is that I feel PM serves 3 masters: Customers, Markets and Sales. You can't develop in isolation and the best things you can direct Development to develop are ones that serve all 3. True the most important features are the ones your customers use – but you're (most likely) solving a problem in a unique way that deserves market attention, and it follows that you need to enable sales to describe why customers need this more than anything else.
Now again – maybe it's outside of the scope of what you're talking about here (which I do agree with by the way) – but you can't do it in isolation.
In short, my job as a PM is to create that bridge across the " 3 masters" of Customer, Market, and Sales – all in an agile way of course 🙂
Tim – I wholeheartedly agree with this perspective. In fact, crossing that bridge (bridges?) is how you figure out what's most important right now (i.e., point #5). Being able to articulate what you are doing to Sales and the customer is kind of a different post (like what I wrote about in today's post, for example), and I assume it just one of the things we PMs have to do. In fact, that's one of the reasons we're here – we like to tell those stories and we're good at it. Maybe I can come up with another post that kind of ties these six points into a more holistic view of the product management role – including communicating with sales and customers. It sounds like a worthwhile effort.