Agile Business Outcomes, Part 2: Investing in Preemptive Risk Mitigation

In this blog series, we explore the world of Business Outcomes; turning what’s important to our business into actionable outcomes, consider outcomes as opportunities to experiment with and improve, and how we meet our outcomes best by helping our customers meet their outcomes.
Part 2: Investing in Preemptive Risk Mitigation
It can be all too easy to get focused on one particular metric, without remembering to tie that metric to a concrete outcome you want your business to achieve. Whether your favorite metric is return on investment (ROI), profit, retention, or anything else, that metric alone is never going to tell you how whether your business is attaining its goals.
In Part 1 of this series, we talked about looking beyond the profit metric, and using multiple metrics to help shift your focus from internal reporting to external outcomes. Here in Part 2, we’ll explore how to analyze those outcomes themselves, and determine whether they’ll actually help your business grow – or whether you should be focusing on different ones.
It all starts when you ask yourself whether you’re selling what you make, or making something your target markets actually want.
Pinpointing and testing assumptions
Say you’re trying to capture a new market. Maybe you’ve got a new customer segment in mind, who you think will prove particularly valuable. The temptation is to immediate slap some standard metrics on that goal: “What’s our timeline for market penetration?” and so on. However, as we talked about in the previous blog, it’s essential to start by asking, “What, specifically, are we trying to do in this market?”
The obvious answer might be “to sell our products” – but that may not always be the best-case scenario. It’s all too easy to fall into the trap of wasting months pursuing an elusive customer segment, never gaining any traction, only to find out in that end that those customers had no interest in your product to begin with. In this scenario, you are focused on selling what you can make, rather than focusing on making what you know will sell.

So, how do we shift our approach?  First step, recognize that all those things you are trying to do are actually assumptions that need to be validated before you do them. In the Lean Canvas model, created by Ash Maurya, the approach is to put all your assumptions about the solution on a canvas, which is a living and evolving document. The next step would be to validate each and every one of those assumptions until you reach a level of certainty that is compelling enough to build the solution.
For example, one of those assumptions is the customer – the people in this market who you think will want your solution. It’s crucial to keep in mind that it’s an assumption, not a data point, because what if your assumption is wrong and these people don’t want your solution? You could invest in building something for a group of people who never wanted to buy it in the first place! So, in order to find out whether that assumption is true or not, you’re going to have to experiment by, in Steve Blanks words, “getting out of the building!” and asking them.
This approach should be followed for all aspects of your solution – customers, problems, solutions, revenue, cost, etc. – ultimately to find out if you have something that is viable before you spend the resources to develop it.  The sooner you find that your assumptions are wrong, the less costly it will be, and the sooner you can adjust your outcomes to ones that matter.

Using viability as a risk metric
A key activity within the Agile model is to pinpoint risks and work on reducing them as early in the process as possible. What we explained in the previous section is a form of risk mitigation, and the outcome was that you are able to shift to a better opportunity (increase revenue) by eliminating the wasteful effort (reduce cost) of that investment.
The ultimate outcome we are seeking through this validation process is to have a product that people will buy. In Lean Startup parlance, this outcome is often called a minimum viable product (MVP), which is the least amount of solution we can build that solves the customer’s problem, sold at a price they’ll buy and built at a cost that still makes us money.
It’s often been said that the minimum viable product (MVP) is not intended to be a product, rather it’s simply a test. This is flawed thinking, because the only way you’ll ever know whether your product is viable is if you’ve already done all the necessary testing before you build it. Jeff Patton says it really well: “If your product dies in the marketplace, it was never viable.” The results of these tests then enable you to come to the conclusion of what your MVP will actually be. This testing is work, but its outcome is risk reduction and revenue maximization!
What are you doing to consider your business outcomes as risk mitigation opportunities? Investments in testing your market can come at a cost – but the alternative is to invest in building a product you think your customer will accept, based on nothing more than third-party market data and your gut instinct. That’s not the smartest way to go. What’s more, it ignores the agile principle of maximizing the amount of work not done, by reducing risk as early in the process as possible.
When you shift into a mode of experimentation around viability, you free yourself from being bound to your market research – which may or may not apply to this specific product – and focus instead on addressing the very real risk that your product might not be viable in the first place. And, if that turns out to be true, you can celebrate the fact that you have more money available for the next investment!
Now that you’ve analyzed your outcomes and what you do to achieve them, we can step up our thinking to the next level and consider the outcomes our customers are trying to achieve.
Read Part 3 of the Agile Business Outcomes series here.
By Michael Moore, Enterprise Agile Enablement Lead, Cox Automotive

Leave a Reply

Your email address will not be published. Required fields are marked *