Applying \"Good Strategy / Bad Strategy\" to Product Roadmaps

I reviewed my notes on Rumelt's "Good Strategy / Bad Strategy" before our last quarterly planning session. It was a useful exercise, because the roadmap we had been building was exactly the thing Rumelt warns about: a list of things we wanted to do, organized by priority, with no connecting logic.

We had 14 items. Features, infrastructure, integrations, a vague "AI exploration" item nobody could define. Every stakeholder had contributed something. The list was comprehensive and completely useless as a strategy, because a list of features is not a plan -- it's an inventory.

Here's how to apply Rumelt's three-part kernel -- diagnosis, guiding policy, coherent actions -- to quarterly product planning.

Step 1: Diagnosis -- What Is the Real Challenge?

The diagnosis is the hardest step because it requires honesty. Not the polished version for the board deck. The uncomfortable truth about what's actually holding your product back.

Most teams skip this entirely. They jump straight to "what should we build?" without first asking "what problem are we solving?" The result is a roadmap that addresses symptoms, not causes.

Bad diagnosis: "We need more features to compete."

That's not a diagnosis. That's anxiety dressed as analysis. It doesn't identify a specific challenge, so it can't guide specific actions.

Good diagnosis: "Users churn at day 7 because onboarding is confusing. 62% of trial users never complete setup. Our most common support ticket is 'how do I connect my data source?' -- a flow we designed in 2021 and haven't touched since."

Notice the difference. The good diagnosis is specific, evidence-based, and names the actual constraint. It's uncomfortable because it says "we built something that doesn't work well." But it gives you something to act on.

How to get there: Pull retention data, read the last 100 support tickets, talk to five churned customers (not the happy ones), and ask your engineers what they'd fix first. They know -- they've been living with it. The diagnosis should fit in one or two sentences. If it takes a page, you haven't distilled it enough.

Step 2: Guiding Policy -- The Approach

The guiding policy is not a solution. It's the strategic direction that constrains which solutions you'll consider. It's the decision that eliminates entire categories of work from your roadmap.

For our onboarding example:

Bad guiding policy: "We will improve the user experience." Too vague. Everything is "improving the user experience." This eliminates nothing.

Good guiding policy: "We will prioritize retention over acquisition this quarter. No new features for prospects until existing users can successfully onboard without support intervention."

That's a guiding policy because it makes a choice. It says "we will do this, not that." It tells sales that the integration they want is not happening this quarter. It tells marketing that the landing page redesign is deprioritized. It creates discomfort -- and that's how you know it's a real decision.

The test for a good guiding policy: Does it make at least one stakeholder unhappy? If everyone smiles and nods, you haven't made a choice. You've written a platitude.

Step 3: Coherent Actions -- What You'll Actually Do

Coherent actions are the specific, coordinated moves that implement the guiding policy. The key word is coherent -- the actions must reinforce each other. A set of random improvements is not coherent action, even if each improvement is individually useful.

For our retention-focused quarter:

1. Redesign the data source connection flow -- the top support ticket becomes the top engineering priority. New wizard-style flow with validation at each step. Ship by week 4.
2. Add in-app onboarding guidance -- contextual tooltips and a progress indicator that shows users where they are in setup. This only works if the underlying flow (action 1) is clean.
3. Build an onboarding health dashboard -- track setup completion rate, time-to-first-value, and support ticket volume for new users. This lets us measure whether actions 1 and 2 worked.
4. Run a re-engagement campaign for users stuck in setup -- product-triggered emails to the 62% who dropped off, offering a guided walkthrough with the new flow.

These four actions are coherent. Each one supports the others. The flow redesign makes the guidance useful. The dashboard measures the impact. The re-engagement campaign applies the improved flow to users we've already lost. Remove any one of them and the strategy weakens.

What's not on this list matters as much as what is. The sales-requested integration? Not this quarter. The AI exploration? Killed. The mobile app redesign? Deferred. Not because those are bad ideas, but because they don't serve this quarter's strategy.

Why Most Roadmaps Are Strategy-as-Wishlist

I've reviewed dozens of product roadmaps from the startups we work with. The pattern is consistent:

The stakeholder buffet. Sales wants integrations. Marketing wants a landing page. The CEO wants AI because a competitor announced it. Engineering wants to address tech debt. The roadmap becomes a buffet -- a little of everything, satisfying nobody fully.

The priority matrix illusion. Teams use RICE scoring or MoSCoW to rank items. Feels rigorous. But ranking a wishlist is not the same as having a strategy. You can RICE-score 30 items and still not have a coherent plan, because the items don't connect to a diagnosed challenge.

The quarterly feature factory. The roadmap becomes a production schedule: "In Q4 we ship features A through E." No diagnosis, no guiding policy, no explanation of why these five features together address a specific problem. The team ships all five and the core challenge remains unaddressed.

How to Say No Using the Strategy Kernel

The strategy kernel is the best tool I've found for saying no without it feeling arbitrary. When a stakeholder pushes for their pet feature, you don't say "it's not a priority." You say:

"Our diagnosis is that users churn at day 7 because onboarding is broken. Our guiding policy this quarter is retention over acquisition. Your request is an acquisition feature. It's a good idea for Q1 when we've stabilized retention, but it doesn't serve the strategy we've committed to."

This works because it's not personal and it's not vague. It connects the "no" to a specific, shared understanding of the problem. Most stakeholders will accept a well-reasoned "not now" if they understand the logic. What they can't accept is "we just decided to prioritize other things" -- that feels arbitrary, and they'll keep pushing.

Document the kernel. Write it down. One page. Diagnosis, guiding policy, coherent actions. Share it with every stakeholder at the start of the quarter. When feature requests come in mid-quarter (and they will), point back to the document. "Does this serve our diagnosed challenge? If not, it goes on the Q1 consideration list."

The Planning Meeting, Redesigned

Here's how I've restructured quarterly planning:

1. Week 1: Diagnosis workshop. Product, engineering, and customer success in a room with data. One output: the diagnosis statement.
2. Week 2: Guiding policy. Leadership reviews the diagnosis and makes the hard choices. Debate expected, alignment required.
3. Week 3: Coherent actions. Engineering and product translate the policy into coordinated deliverables. Scope, sequence, dependencies.
4. Week 4: Communicate. Share the kernel with the whole company. What you're doing, what you're not, and why.

This takes longer than ranking a spreadsheet. The quarter becomes focused instead of scattered.

At Conectia, the senior engineers we embed into client teams don't just execute roadmap items -- they challenge the roadmap itself. They've seen enough products to recognize when a roadmap is a wishlist masquerading as strategy. That pattern recognition, combined with the discipline to ask "what's the actual problem?", is what experienced engineers bring to a team.

---

Need engineers who challenge the roadmap, not just execute it? Talk to a CTO -- our senior LATAM engineers bring the strategic thinking to turn feature lists into focused product execution.