The Overlap is a newsletter somewhere between product development and organizational development. This will be in your inbox every other Thursday morning.
Starting with an ideal vision of the future doesn’t always produce a strategy. You have to understand your current reality, too.
Most strategies often are just an ideal vision for the future.
“This is the difference we want to make in 5 years.”
“This is how we want to make our customer lives better.”
While I'm a big advocate of crafting a vision for the future, I’ve noticed lots of “strategy decks” just being a vision and missing strategy. This is a problem! Vision ≠ strategy. Vision is where we want to go, strategy is how we’re going to get there from where we currently are today.
This leads to individual contributors whose job it is to execute that strategy feeling like the strategy isn’t actually helpful. To ICs, all the strategy decks and docs they’ve seen aren’t directing them on what to do. Which leads them to believe that strategy is just aspirational, fluff, and devoid of reality.
"Like it's great that we want to pursue this business opportunity, but today we're really focused on maintaining the profitability of our current business..."
This bums me out as a product strategist! Product strategy is supposed to be helpful, yet a lot of product strategy artifacts aren’t. 😢
Most strategies lack a diagnosis
Richard P Rumelt, author of Good Strategy Bad Strategy, writes:
The kernel of a strategy contains three elements:
1. A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.
2. A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.
3. A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.
I've written before how most "strategies" have 3), a smidge of 2), and rarely 1):
Roadmaps and requirements docs
usually describe 3),
sometimes describe 2),
and never describe 1).
These outputs fail to see the problem. They handwave the “approach” to dealing with the challenge, at best.
Strategies need to start with a diagnosis of the challenge! See the problem before you solve it.
There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. "It's great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment... and we're far from where we want to be there."
And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.
The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.
I’ve always thought that the job of an org designer is to “expose the mess.” You should make the dissonance visible.
Make the dissonance visible through a bottom-up strategy
John Cutler shared an exercise he uses with teams called Bet Up.
I like this exercise because there are plenty of top-down tree-based activities; start with a strategy and work __down__ to the day-to-day work. In many ways the North Star Workshop I do is a strategy __down __activity.
With the Bet Up exercise, we flip that. We begin with work in progress. Teams reverse engineer a plausible driver tree, making an implicit strategy explicit. It might not be the perfect strategy—and ideally, we’d work the other way around—but it is what exists now.
It looks like this anonymized real-world example:
John’s post helped crystalize an insight for me: consider arriving at strategy bottom up, rather than top down. Arriving at strategy bottom up helps us create that diagnosis that Richard P Rumelt talks about. We need that diagnosis to have a real strategy.
This is similar to what I’ve written about in broaden your company’s vision after a quarter:
It feels intuitive to define a vision at the start. But defining a vision with no experience is like asking an incoming college freshman to declare their major without giving them a chance to take some classes and explore their interests. How can an incoming freshman know what they want to study for the next four years without having taken any classes?
Same with articulating a vision for where you want your company to be in 1, 2, or 3 years. It’s easier to have a vision when you’ve accomplished some major goal. You have a better idea of how your company can impact your customer after you’ve done some actual work.
I now know why doing a retrospective before strategy work helps. I’ve always started my strategy workshops with a retro. After reading John’s post and thinking about how our day-to-day can tell us a story about our current strategy, I feel I can better articulate why doing retros before revisiting our strategy is important. We want our strategy to be informed by how we’re currently doing. By doing a retro, we can see today’s challenges. We’re doing the diagnosis work as Richard Rumelt says. So that when we revisit our strategy, we have a better idea of how we can move towards where we want to go today.
📝📝📝
By the way, here’s a FigJam template of how I currently run this retro -> strategy workshops.
📝📝📝
Put bottom-up strategy into practice
I got feedback from a sharp colleague (Nicole!) recently when working on a vision & strategy doc for Manhattan Hydraulics. I stated in that doc my vision for Hydraulics to be a vessel for doing weirder, more amorphous kinds of work (though recently, we’ve iterated this to doing ambitious product design work with people who intend to do some kind of good in the world. We’ll be continuing to create a shared understanding here!).
I’d summarize her feedback as: “This all sounds great. But what do we need to do today to get there?”
Her feedback reminded me of how I can continue to get better at creating a strategy from the bottom up. I still have room to improve, even though I write and consult on this!
Maybe you have room to improve too. Notice when you’re too in the clouds. It is literally a leader’s/PM’s job to have a vision for the future and to marshal the resources to get there. So take a moment to be kind to yourself. Then, try the Bet Up exercise or Retro into Strategy workshop or the Product Strategy Canvas exercise with your team.
You will get reality checked! That’s okay. You, your teams, and the leaders supporting you will need the reality check to embark on your ideal vision of the future.
What I’m Reading
See you in two weeks,
–tim
re: "Autonomy is enabled by clear intent and technical excellence" in the reading list, just this week I had to correct in real-time a few middle-managers throwing the "you can self-organize" mantra to their teams.
I raised my "empty buzzword alert" flag and explained that maybe we should not use the term "self-organizing team" so carelessly, and maybe have a discussion about control and delegation, what the teams can and cannot do, and then work our way up from there.
Didn't go as far as telling them that self-organization is an emergent property and not a skill, but will go there for sure soon because they have implied that I can "teach self-organization" to the teams 🤦🏻♂️