I consider myself a fan of Agile and the values and principles that the Manifesto states. In fact, I’ve been using agile for many years and I saw how many teams changed and improved over the years through this practices.
I’m currently working on an agile transformation at the organization level, trying to bring agile practices to the entire company (including marketing, customer services, sales, etc).
This transformation also includes taking the IT teams to a new level of “agility” trying to take more advantage of the values and principles it proposes. To me, this meant getting back in contact with the roots of Agile and its foundations.
So I’ve been re-reading the manifesto and reflecting on its principles again. And to my surprise, I found one that I feel is completely wrong for modern product development:
- Working software is the primary measure of progress.
Focus on outcome instead of output
The underlying idea of this principle is that prototypes, documentation or any other artifact that is not something working cannot be counted as real progress. I agree with that.
But it is not enough.
Delivering working software that nobody wants or reaches no purpose is useless. Just delivering puts the focus on output rather than outcome.
The primary measure of progress when building innovative product should be {core metric} improvement!
Usage, retention, lifetime value or any other KPI that you define as your core metric and you can measure to see if people are valuing your product should be the way to track progress.
Just to give the right credit to the Agile Manifesto, the 7th principle was completely logical some time ago when they were trying to get away from the waterfall model and move to early delivery. And also considering that the role of software developers was more oriented to deliver what the “business stakeholders” considered important.
But when we moved to a product innovation world, where no one really knows what will work, and the entire team should take responsibility for the outcome, it’s not enough to just deliver working software.
And also track learning…
When we move away from the Software Factory model, we need to focus on understanding what is the right product to build. This is where Product Discovery plays an important role.
Product Discovery contains all the activities we do to learn and validate what is that “right product” that we must build. Based on lean principles and customer development, a set of tools is used to quickly interact with the users to learn what they need before we move to building the solution.
So as a measure of progress we need to focus on both metric improvements (for the delivery cycles) and learning (for the discovery cycles).
NOTE: this relates to dual-track agile which I hope I can write about soon.
Since the entire team should be somewhat involved in these activities, keeping track of learning helps you measure the progress the team is making towards an innovative product.
Final words
Actually, if we take a look at the first principle (“1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”), it focuses on serving the customer through valuable software. I believe that already covers what the 7th principle is trying to do and with a better focus on the outcome.
Anyway, this just was a great excuse to talk about discovery and outcome-focused product teams, so I jumped at the opportunity :)
Originally published at leanexperimentation.com. If you enjoyed it and want to receive more tools & tips on Product Discovery, you can subscribe here.