Too many product teams are stuck in a mish-mash of waterfall and agile. And even amongst agile dev teams, it is time they leveled up from agile 1.0.
A waterfall/agile mish-mash is where the dev team attempts to be agile, but the business thinks in waterfall terms with feature roadmaps, time-based estimates, and time-based deadlines.
What do I mean by Agile 1.0? Agile 1.0 is all about production, i.e. shipping features in an effective manner. In Agile 1.0, the stakeholder is called the “customer” (which is crazy when you think about it). In Agile 1.0, dev is too often an order-taker, not a strategic partner in the business.
Using metrics to determine whether a shipped feature is succeeding is important, but that’s only part of the battle. The real mental shift for older organizations comes with incorporating experiments and MVPs into their thought process and product activities. It is hard to do, and I have to push myself constantly to do it better.
It’s not about shipping features. It’s about creating value.
It’s not about meeting deadlines. It’s about delivering real value as quickly as possible.
Your team’s goal (aligned across product management, UX, and development) should not be to ship X-feature by Y-date. Your team’s goal should be to hit X customers as quickly as possible, or raise the conversion rate to X% as quickly as possible, or reduce customer support calls by X amount as quickly as possible. The imperative moves off of shipping ivory-tower features to deeply understanding and then creatively solving problems. It’s still about execution, but smarter execution.
But what about marketing, some might protest: “Marketing needs deadlines!” My response is this: marketing is indeed still critical, but it has changed. You can’t brute force products anymore with marketing. You need the product to be right first, and that cannot be predicted very well, so marketing needs to learn how to be flexible and marketing and product need to communicate closely.
The key question is, can you make room in your process for experiments and MVPs?
Experiments:
For every feature initiative you have in mind, what lightweight experiments can be run to:
1. validate our belief in the initiative
2. inform our knowledge of the problem and customer so that our actual product is better out of the gate
(for example, before building a feature, try adding a button to see if anyone clicks on it, and while you are doing that, do qualitative UX research with real customers. Note: it’s really hard to do experiments unless you are live in the market, even if under a “labs” label; it also would be helpful to invest in A/B test infrastructure)
MVPs:
Every feature idea is a hypothesis that doing A will deliver B in value. But chances are high that you can start delivering value with a little “a” as you iterate to the big “A”. Just keep in mind the actual words in the acronym: minimum, viable, product. Each one is important.
So how do you convert an organization that prioritizes features and deadlines to one that prioritizes value creation?
Next week I’m going to lay out some detailed tactics that might be helpful in doing exactly that.