Recently, a long-term client of mine sent me an email with the question below (scrubbed for anonymity) after we’d spent close to a year together building a set of objectives and key results (OKRs) for the entire organization along with, what I believed to be, a clear sense of how to at least start working towards achieving them and how they impacted and drove the organisation’s agility. What follows the question was my response to my client and, as you’ll see, focuses squarely on how product strategy is a hypothesis, like everything else we do at work, and without an org-wide emphasis on using OKRs (with customer-centric key results) to measure our success, we’re right back into the old waterfall ways of working.
My client’s question:
“While in theory we should allow experimentation and the build > learn > release cycle, in my experience what happens is business stakeholders (usually focusing on delivery not product) assemble a strategy that says e.g. “we need to start selling in the US.” What this means to our teams is we have to build and launch our services in the US, and there is no need and room for anything within a 9-12 months time period, other than to do this work. While this way of working can be aligned nicely with the concept of OKRs, what really happens is we go into this super-waterfall delivery mode, where the “strategy” is an order for a piece of work, which has to be delivered within the shortest time frame.
After we are done, then the next “strategic initiative kicks in”. Not just C-level strategy, but a lot of other senior managers also mix in their own strategy and OKRs into this top-down waterfall, ultimately filling the backlogs with work for the next 24 months by the time it gets to the teams and product management. This leaves no room for any agile thinking, stories out of customer engagement are left untouched for years within the backlogs, and product managers and product owners quickly descend and are asked to behave as junior business analysts. Not really caring about whether what we release has what kind of impact, but be proud of delivering more stuff, and looking at customer behavior is non-existent or only vaguely understood.
So how often is the above a problem in large organizations? Is this a problem with how strategy is formulated? Do you see a correlation between the occurrence of the above and how the business/roles are organized?”
You nailed it on the head when you called it strategy. That’s what a statement like, “start selling in the US” is or at least what it should be. This is the leadership team’s job and they can and should decide to do things like, “expand our market to the United States in 2020.” That’s all well and good IF (and this is where it breaks down in reality and in your story) this strategy is treated like a hypothesis AND it comes with clear OKR’s for success.
There’s a great article in HBR that talks about this from business professor/guru Roger Martin called The Big Lie of Strategic Planning. In that article, Martin details exactly what your leaders are doing with the US-“strategy” and why they’re doing it. Instead of this approach, he offers a better way to rethink strategic planning that boils down strategy to two questions:
- Where you’ll play? (who’s the target market)
- How you’ll win? (what’s the value proposition)
I actually think there’s a third question missing:
3. How will you know you’ve won? (your Key Result)
The problem is that this kind of leader-level discussion doesn’t happen often enough and it’s not happening with your leaders either. They have made a decision on what they are going to do (a plan!) and how they will do it and when it should be done (a roadmap!) and then predicted the financials from it (cost-based thinking as Martin calls it). This makes the broad assumption that they’re right about the strategy, the execution and the revenue prediction.
In that world there is no room for course correction, agility or customer-centricity. In fact, the customer has been erased from this conversation completely. OKR’s in this context are often discarded as you point out because they get in the way of feature delivery.
This is what’s called “deliberate strategy” – a term coined by Henry Mintzberg (mentioned in the Martin article) where management has all the answers and dictates the work to teams. The agile, customer-centric, continuous improvement ways of working struggle (at best) in this reality.
Instead, if the leadership team addressed this strategy as a hypothesis using Martin’s 2 questions and my additional third question the teams would have the bandwidth and the mandate to do the kind of work necessary to determine the best path forward for the company and its customers while continuously learning and improving on that strategy as new information comes in.
For example, you could rephrase the deliberate strategic challenge as:
We believe we should expand into the US markets in 2020. Specifically, we’re going to target large-scale real world events first with our [awesome ability to do X, Y and Z] eventually moving downstream into smaller events like [blah, blah and blah]. We will know our strategy has succeed when we see $X revenue derived from [these types of events], 25% market share in [the relevant US market(s)] and a cost per acquisition that is at least 15% lower than our European businesses.
This has all the components of the 3 questions and, in theory, allows teams to come back with market-based evidence to prove/disprove this hypothesis. This is called emergent strategy because as new evidence emerges from the market and the teams’ work the strategy inevitably will evolve. Without that, we’re back to waterfall/manufacturing style production.
As you can see the point I was making was that every aspect of the way we run our business is our current best guess about how to succeed. If we phrase that guess as a requirement, our teams will execute without a guarantee that this execution or the idea even was valuable. However, if we rephrase our product strategy as a hypothesis we ensure that a customer-centric, agile approach to delivering value happens because it’s the only for the best possible approach to emerge.
What have you seen work well in these situations? How does your organization determine product strategy? Leave your answer in the comments.
2 thoughts on “There’s no guarantee your product strategy will work. Here’s how to de-risk it.”
Good article, only one comment that the strategies could be more elaborated with examples
Excellent article and a notion that many leaders don’t take into account: how to reduce risk in a strategy before executing on it.
That is exactly what Charles and I address in Presumptive Design: how to test a strategy before marshaling all the resources needed to execute on it.
Thanks for writing about this.
Comments are closed.