Strategy as a sweet spot
Welcome to The Overlap, a biweekly newsletter somewhere between product and organization design. It comes out every other Wednesday morning.
Good strategy has a sweet spot. We’ll talk about that sweet spot and share some ways you can find it.
Most strategy outputs don’t help you understand the why
Let’s define what strategy isn’t. Strategy isn’t a plan. It’s not a roadmap. It’s not a requirements doc.
Most people think of strategy as these things. While a plan, roadmap, or requirements doc come out of strategic discussions, they aren’t a strategy. Because they usually miss one thing: The why. Why are we building what we’re building?
I know, I know. This is a very Simone Sinek-y take. But without the why, we build things that don’t solve actual problems.
Richard P. Rumelt defines strategy as three things: a diagnosis, a guiding policy, and a set of coherent actions. From Good Strategy Bad Strategy:
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.
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.
Remember, we tend to jump right into solutioning before seeing the problem clearly. We always assume that technology is the answer:
Product strategy is, for me, the art and science of knowing where you’re trying to get to before you set off. It means transcending the notion that a product is about screens and features. It’s about starting with your user’s desired outcomes and working backward to the technology. This is not new thinking. Steve Jobs was fond of saying this decades ago. But it seems every generation needs to relearn this, as every generation is susceptible to the assumption that technology is the answer.
— Paul Jackson in Product Strategy | The New Toolset
Strategy as an enabling constraint
Maggie Crowley defines strategy as a set of constraints within which your team makes bets.
I like Maggie’s definition because it highlights a paradox. When the constraints are clear, teams feel free to decide how to pursue their goal. Constraining a problem enables (rather than inhibits) autonomy.
It’s difficult to do anything creative without constraint. The designers and developers I work with experience decision fatigue when there isn’t a constraint.
Effective product strategy lowers decision fatigue while simultaneously increases team flexibility
– Adam Thomas in How Good Product Strategy Can Help Decision Making
Good product strategy is what complexity theorist Dave Snowden calls an enabling constraint: a constraint that makes the impossible, possible.
Contrast enabling constraints with governing constraints: constraints that hinder or limit you from what's possible.
Good strategy has a sweet spot
I think good strategy has a sweet spot:
It's detailed, but not 10 pages long.
It's concise, but not vague.
It directs but doesn’t micromanage.
It takes a strong stance but changes its mind as it learns more.
Bad strategy has its anti-patterns:
Strategy as inflexible. We defend our rationale when smart people ask questions. We don’t change our beliefs when we see new data.
Strategy as handwavy. We list features on a google doc, then ask developers to “go implement it.” The doc doesn’t explain how it benefits our business and user.
Strategy as micromanager. A requirements doc shouldn’t decide on the components and layout of each screen. That’s a designers job. A PM shouldn’t decide on the technology used to build the product. That’s a tech lead’s job. Yet, we use strategy as a means to make decisions that aren’t in our area of expertise.
Strategy as indecisive. “We want to change the way content is consumed on the internet” isn’t a strategy. There isn’t enough of a constraint to make any meaningful decisions. Designers and developers feel overwhelmed because it isn’t an enabling constraint.
Avoid these anti-patterns. Find the sweet spot.
How do I find that sweet spot?
Here are four tips that work for me.
Think big, work small. Get your org clear on two things: 1) your product’s North Star metric—the one metric that tells us whether we’re successful or not—and 2) your team's work for the week. This a) gives your clarity yet b) the flexibility to learn and adapt. Don’t work big. And don’t think small. Read more here.
Shorten your feedback loops. Keep your vision ambitious, but tighten your feedback loops. This means evaluating your strategy every 3 or 4 months. Read more about this in The Overlap #6.
Be focused on the near term and flexible in the long term. In other words, don't plan your team's roadmap a year in advance. Some teams plan their week. Other teams plan their month. Invite your team to find the right time length for their context. And hold your 3 to 5 month plans loosely. Read Matt Strom's Responsive Roadmaps for more.
One pagers. One pagers force you to articulate your product's strategy. Draft one! Then ask for feedback from your product team on how to improve it. One pagers are one of the best enabling constraints.
I wouldn’t call myself a strategy veteran. I am still a student. If you have any tips that help you find that strategy sweet spot, I'd love to hear them in the comments.
What I'm Listening To and Reading
Spotify: A Product Story. Spotify just released a podcast series that shares how they became the company they are today. It’s great. Full of product strategy lessons.
Creating Product-Led Strategy with Oji Udezue. I was surprised to hear that it takes at least 3 months to craft a good product strategy. This goes to show that when you start a new role, you don’t want to immediately jump into “fixer” mode. Instead, understand the organization’s context, goals, and needs before creating a strategy.
Uber’s crazy YOLO app rewrite. Great story by the lead engineer who rewrote Uber’s passenger app.
Technically is currently my favorite newsletter. Every time Justin publishes, I feel a little less dumb about software. I just read his posts on Serverless and DevOps.
Tim Throwback
In 2020, I tried to form a point of view on what I thought product strategy was. The one thing I’ve learned since then is that strategy takes a lot more upfront definition than I initially thought. You’re not micromanaging when you pave a path forward and suggest a set of actions. You’re doing strategy!
See you in two weeks,
–tim