Product management has always revolved around one fundamental goal: maximizing business value. However, with the advent of Agile methodologies, there’s been a significant shift in how this goal is achieved. While the core tools and techniques remain largely unchanged, the approach to their application has evolved, leading to a more dynamic and responsive process.
Traditional Product Management: The Long Road to Value
In the traditional world of product management, long release cycles were the norm. Consider the case of the Azure DevOps team during the Team Foundation Server era at Microsoft around 2010. Back then, they operated on a two-year release cycle:
New product versions were delivered every two years.
A service pack was released halfway through the cycle.
A beta version of the next product was also introduced during this time.
The goal was to create a product that maximized business value, but the lengthy cycle made it challenging to meet customer needs efficiently. There were several significant drawbacks:
Challenges of Long Release Cycles
Delayed Feedback:
It took too long to get feedback from customers, which meant that issues or gaps in features were only discovered after significant time had passed.
By the time feedback was incorporated, it often ended up in a much later version, such as version three, if at all.
High Risk of Irrelevance:
Building an entire product or feature set based on assumptions without real-time customer validation posed a risk. If the market shifted or customer needs changed, the product could quickly become obsolete.
Competitors who could adapt more quickly often captured market share during this lag.
Complicated Change Requests:
- The lengthy cycle required complex change request systems to manage any alterations to the plan. These systems were designed to protect the investment in the plan but often ended up being cumbersome and costly.
Agile Product Management: A New Approach
Agile introduced a radical change in product management by emphasizing shorter cycles. This shift allowed teams to respond more rapidly to customer needs and market changes. The Azure DevOps team, for instance, transitioned from a two-year delivery cycle to a three-week delivery cycle almost overnight, fundamentally altering their approach.
The Benefits of Shorter Cycles
Faster Feedback Loops:
- With a three-week cycle, the team could get new features or updates in front of customers quickly. This meant that feedback could be gathered and acted upon in just six weeks, a stark contrast to the previous years-long delay.
Reduced Need for Change Requests:
- Since plans were now only three weeks long, the risk of something derailing the plan was significantly reduced. The cumbersome change request system became largely irrelevant.
Frequent Delivery of Value:
- Teams were able to deliver new features or improvements to users every three weeks, ensuring that the product continuously evolved based on real-time feedback.
The Decline of Traditional Practices
As Agile practices took hold, many traditional product management practices became obsolete. For example:
- User Acceptance Testing (UAT):
In the past, UAT was crucial for protecting production from issues introduced by engineering teams. However, with Agile, the focus shifted to building higher-quality products from the start.
As Brian Harry, a notable figure in this transition, famously stated, “There’s no place like production.” This means that despite extensive testing, production issues were inevitable, making UAT less valuable. Instead, teams aimed to build quality into the product from the outset, rendering UAT a cost center rather than a value center.
Building Quality from the Start
In Agile product management, the emphasis is on continuous delivery of high-quality, usable products. To achieve this, teams must ensure that quality is built into every stage of the process. Here’s how:
The Role of a Clear “Definition of Done”
- Definition of Done (DoD):
A clear and stringent DoD ensures that every increment of the product meets the necessary quality standards before it’s considered complete. This includes not just functional aspects but also non-functional requirements like performance, security, and usability.
By adhering to a strong DoD, teams can minimize the risk of defects reaching production, thus reducing the need for extensive post-development testing.
Continuous Integration and Delivery
Agile Product Management: A Strategic Advantage
The shift to Agile product management is more than just a change in process; it’s a strategic advantage. By embracing shorter cycles, continuous feedback, and a relentless focus on quality, organizations can:
Increase Market Responsiveness:
- Agile allows teams to quickly adapt to changing market conditions and customer needs, ensuring that the product remains relevant and competitive.
Enhance Customer Satisfaction:
- Frequent releases and rapid incorporation of feedback lead to a product that better meets customer expectations, driving higher satisfaction and loyalty.
Reduce Waste and Improve ROI:
- By eliminating unnecessary practices and focusing on delivering value, Agile product management helps organizations maximize their return on investment.
Conclusion: Embracing the Agile Mindset
Transitioning to Agile product management requires more than just adopting new practices; it requires a fundamental shift in mindset. Teams must be willing to let go of traditional methods that no longer serve them and embrace a more dynamic, customer-centric approach.
- Key Takeaways:
Agile product management is not about discarding old tools but rethinking how they are used.
Shorter cycles and continuous feedback are the cornerstones of Agile, enabling faster, more responsive product development.
Building quality into the product from the start reduces the need for extensive testing and ensures a smoother, more reliable delivery process.
By adopting these principles, organizations can unlock new levels of efficiency, innovation, and customer satisfaction, ultimately driving greater business value.
Agile product management differs from product management that has been done for many years in actually very subtle ways. So you could say it doesn’t differ at all as well because all of the tools and techniques that you would use in product management and you have been using in product management for many years are the same tools that you would use in agile product management. But the way that you approach the context of the tools and which tools make more sense and which tools make less sense is the bit where it differs because we’re changing the underlying principles of what it is we’re trying to achieve.
So in the traditional world, we’re probably going quite a long time between actual releases, at least to get the first release. And then between releases, we’re probably taking a long time. I’m thinking about the Azure DevOps team at Microsoft when it was Team Foundation Server and Visual Studio, right? That era around the 2010 era, they were on a two-year cycle, right? So they were delivering a new version of the product every two years. Halfway, they would do a service pack, and then halfway into, roughly about the same time, I guess it was roughly about the same time, they would have a beta of the next version of the product.
What really happened was that when you’re thinking about product management, you’re thinking about how do we make a product that maximises the value for our business, right? That makes the most money. That’s what we’re talking about with product management. We have a product, we need to manage what we put into that product, what we take out of that product, how we ship that product, how we market that product in order to maximise the return on investment. That’s ultimately what we’re talking about.
In that world of releasing long releases, right, long time between releases, they found that they really struggled to maximise that value for a number of reasons. It just took too long to advertise the value that they thought their customer wanted. So the first one is you have to build the whole thing, right? You have to, if a customer wants XYZ feature, you have to build XYZ feature because when you ship XYZ feature, you’re not technically shipping again for two years. So if there’s something wrong with XYZ feature or XYZ feature doesn’t have some capability, right, then the customer is going to be frustrated and may go to another product, right? May go to your competitor because they do have that feature.
So that idea of shipping once every two years actually means that you can’t take feedback and get it in front of your customers for four years. Generally, there may be circumstances where you can change what you’re working on, but then it becomes a big issue, right? Because you’ve planned all of this stuff over two years, and somebody makes a change to what it is they want to deliver. What is the impact across all of the things that you’re working on? So that’s why we have change requests, right? We make a complicated, convoluted change request policy system in order to reduce the change coming in because change coming in is high cost because we have to change all of the things that are going on in order to accommodate that change.
So you’ve got this long cycle. I mentioned that it was twice the iteration length to incorporate feedback from your customer quite often. And the reason for that is that you get your product in front of your customer at this point, and then in two years, we’re going to do another ship. But we’ve already had to plan what we’re going to put into that two years, right? So when we get feedback on version one of our product, that’s going to end up in version three of our product if it’s small enough or important enough. It might end up in version two, but we’ll have to kick something out that we were going to deliver. So that’s risk, right? Because we’re not delivering something that we think the market needs.
We end up with that twice the cadence, right? Twice our cadence is the amount of time it generally takes to get new features and feedback that the market desires. So what’s the cost of delay? What’s the cost to our customer of not delivering a feature that they need in order to service their business? And we’re not going to deliver it to them for up to four years, probably a little bit less, but up to four years. That is a massive impact on not only your customer’s ability to innovate and do things differently or fulfil their needs, but on your team and the people doing the work’s ability to see the value that they create being used by the customers because the delay is just too long. They’re not working on that feature anymore by the time the customer gets it.
So one of the fundamental premises that we talk about in agile product management, the agile piece versus the just product management piece, is that we’re going to have much shorter cycles, much radically shorter cycles. For example, the Azure DevOps team went almost overnight, some false starts, but almost overnight from a two-year delivery cycle down to a three-week delivery cycle. So delivering to production every three weeks, delivering to real users out in the world every three weeks. And that enabled them to get closer to the customer, right? So even if we still had that same twice the iteration length, you’re talking six weeks to get something new in front of your customer that they need or tell you that they need. And six weeks is much shorter than two years, four years, right? Up to four years.
So up to six weeks instead of up to four years. And that fundamental change means that a lot of the practices that you might use in product management then become a little bit irrelevant, right? So I’m thinking practices that become irrelevant would be change requests, right? They pretty much become irrelevant because change requests were there to protect the plan and protect the investment in the plan. But since our plan is now only three weeks, we don’t need to protect it so much because the risk of something derailing that plan is much smaller, right? Because we can correct much more often, so we don’t need that change request system.
We would look at portfolio investment, like how much time are we investing in different features, different parts of the product, or do we want to move people? And we can move people in a three-week cadence rather than on a two-yearly cadence. But then we’re also, because we’re delivering more frequently, we’re able to then remove other things, right? That are going to get in the way of delivering more frequently. Can you imagine having to do UAT for your entire product every three weeks? Right? UAT doesn’t make sense. User acceptance testing doesn’t make sense.
There’s a famous quote from Brian Harry. I love that presentation of his that he did, and he had a picture of the slippers from the red glittery slippers from Wizard of Oz, and it was like there’s no place like production. No matter how much testing you do, no matter how much validation you do, you’re always going to find production issues. And that’s where UAT came in, right? UAT was trying to protect production from issues introduced by the engineering teams. But if the engineering teams are delivering new versions of the product every three weeks, where’s the time to do that UAT?
So one of the things we need to fix, one of the agile practices we need to bring in, is much higher quality product, much higher quality code, much higher quality engineering in order to not have those issues in UAT. Your UAT should be a cost centre anyway. It should not be a value centre. If UAT finds something that shows a failure of quality in the engineering system, UAT should never ever find anything. So if you build up quality to the point where UAT is a cost centre, not a value centre, then the people that fund the UAT, that desire the UAT because they find stuff, will start to erode that because you’re demonstrating the quality of your product. You’re demonstrating that that UAT is unnecessary because it never finds a problem.
So you have to apply that thinking to all of the practices that we have in product management. Do they make sense in agile product management versus the way we always used to do things, right? So can we do it quickly? Is it getting in the way of actually getting our product in front of users? Because that’s how we validate that we’ve built something that’s valuable. How do we enable that continuous delivery of high-quality, usable product into the hands of our users? And what of our practices that we use right now in product management make sense in that space and which don’t make sense, right? And they maybe don’t make sense because they become irrelevant or they don’t make sense because they take too long. And what are we going to replace them with in order to effectively maximise the ROI of our product in the market?
