"Be more strategic" might be the most common and least actionable feedback a PM ever receives.
Part of the problem is that strategy sounds like something that happens above your pay grade. The VP sets it, the board approves it, and you execute it. Under that model, a mid-level PM's job is translation, not strategy.
That model is wrong. Every PM who owns a product area needs a strategy for that area, whether or not anyone asked for one. Here's what that means in practice and how to build one that survives contact with reality.
What Strategy Actually Is
Strip away the mystique and strategy is three linked things:
- •A diagnosis: an honest read of your situation. What's happening with customers, competitors, and your own product? What's the critical challenge or opportunity?
- •A guiding approach: your chosen way through it. Where you'll play, how you'll win, and implicitly, what you won't do.
- •Coherent actions: the bets and moves that follow from the approach, reinforcing each other rather than scattering effort.
(That's Richard Rumelt's kernel, and it's held up better than any framework since.)
Notice what's not in the definition: ambition, mission statements, or a list of goals. "Grow revenue 40%" is not a strategy; it's a desire. A strategy explains how, and its power comes mostly from what it rules out.
The test of a real strategy: it makes some decisions for you. When two reasonable options appear, the strategy should usually pick one. If every option is compatible with your strategy, you don't have one.
Strategy at the Team Level
Suppose you own the onboarding and activation area of a B2B SaaS product. Company strategy says "move upmarket." What does strategy look like for you?
Diagnosis: Enterprise trials convert poorly. Digging in (data plus interviews), you find enterprise evaluators hit a wall: setup requires admin permissions they don't have, so trials die waiting on IT.
Guiding approach: Win the enterprise evaluator before IT gets involved. Make the first hour valuable with zero admin dependency, and make the IT handoff effortless when it comes.
Coherent actions: Sandbox mode with sample data. Permission-free trial paths. A one-page security packet the evaluator can forward to IT. Deprioritize: SMB onboarding polish, this quarter.
That's a real strategy, built at the team level. It interprets the company direction, it's grounded in a diagnosis you did yourself, and it makes decisions: when someone proposes an SMB onboarding improvement, the answer is "not now," and everyone knows why.
This is what "be more strategic" actually asks for. Not grander plans. A written, defensible logic connecting what you know to what you're doing.
Building Yours: The Inputs
A strategy is only as good as its diagnosis, and diagnosis comes from four inputs you should already be gathering:
- •Customers: What problems matter most, and to whom? Where does the product delight or fail? (Customer interviews are the backbone here.)
- •Data: Where do users drop off, retain, expand? What do the metrics say about where value is created and lost?
- •Competition: Where do you win and lose, and which losses matter? (See our competitive analysis guide.)
- •The business: What does the company need from your area? Revenue, retention, a strategic capability? What constraints (team size, tech, brand) are real?
Most PMs have partial versions of all four. Writing the diagnosis forces you to notice which parts are assumption rather than knowledge, which conveniently generates your discovery agenda.
Set aside real time for this. Diagnosis squeezed into the gaps between sprint ceremonies produces the strategy equivalent of a rushed exam answer. A focused week of pulling these threads together, even part-time, pays for itself many times over in the quarters that follow.
Writing It Down
Keep the artifact short. One to two pages:
- •Where we are (the diagnosis, with evidence)
- •Where we're going (the approach: target customer, the way we win)
- •What we'll do (the three or so big bets, and explicitly, what we're not doing)
- •How we'll know (the metrics that would confirm or refute the bet)
Two pages is a feature, not a limit. Length hides fuzziness. If you can't state your approach in a sentence or two, the thinking isn't done yet.
From this document, everything else hangs: your roadmap is the strategy laid out over time, your OKRs are the quarterly instrument panel, and your backlog decisions become mostly derivable instead of freshly debated.
Getting Buy-In From the Middle
Here's where PMs without a VP title worry: who am I to write strategy? Practical answers:
Don't ask permission to think. Nobody objects to a PM who shows up with a clear-eyed diagnosis of their own area. The presumption problem only arises if you skip evidence and declare direction by fiat.
Socialize the diagnosis before the strategy. Share the "where we are" section with your manager, engineering lead, and design lead first. People who helped shape the diagnosis rarely fight the conclusions that follow from it. This is stakeholder management 101: agreement on facts before debate on choices.
Frame it as a proposal. "Here's my read of the situation and what I think we should do. What am I missing?" is both genuinely open and hard to dismiss. Most managers are relieved when a PM does this; strategy vacuums are stressful for them too.
Expect and welcome edits. If leadership redirects your strategy, you've still won: you now know the actual strategy, stated explicitly, which is more than most PMs ever extract.
Keeping It Honest
Strategies fail in two boring ways. They're ignored, or they're never updated.
Against being ignored: use the strategy out loud. In prioritization meetings, in spec reviews, in roadmap discussions, tie decisions back to it explicitly. "We're saying no to this because our bet is enterprise evaluators" trains everyone that the document is load-bearing.
Against going stale: revisit quarterly, but only rewrite when the diagnosis changes. New competitor, surprising data, a bet clearly failing: those justify rework. The calendar alone doesn't. A strategy that changes every quarter isn't a strategy; it's a mood.
And watch for the failure nobody admits: a strategy that never says no. If every stakeholder request fits comfortably inside your strategy, it's a horoscope, written vaguely enough that everyone sees what they want in it.
A practical habit that keeps strategy alive: keep a short decision log. Every time the strategy settles a real question ("we passed on X because of the enterprise bet"), add a line. After a quarter, that log is the best evidence you have, in both directions. Either it shows the strategy earning its keep in concrete decisions, or it's nearly empty, which tells you the document is decorative and needs sharpening. It also makes your quarterly review trivially easy, because the evidence is already gathered.
Why This Is Worth It for Your Career
Strategic thinking is the sharpest dividing line between mid-level and senior PM roles. We see it constantly in job postings: senior roles ask for "owns product strategy for their area" almost verbatim. And interviews for those roles probe exactly what this post covers: can you diagnose a situation, commit to an approach, and explain what you deliberately didn't do?
PMs who practice this at the team level, before anyone gives them the title, are the ones who get the title.
Ready for a role with more strategic scope? Browse senior PM openings at productmanagerjobboard.com.