This is the second post in a series about turning metrics into action. Part 1 covered building KPI trees that pass the Tuesday Afternoon Test. You can read both separately but best to leverage both concepts to get the best outcomes.

Thanks for reading RoadToPM! make sure to subscribe to stay up-to-date ✨✨✨

Subscribe now

Your KPI tree shows that 40% of users churn in their first month because they “can’t find the features they need”.

Your team nods knowingly in the quarterly business review.

Someone suggests “improving discoverability”.

Everyone agrees.

The meeting ends.

Three months later, the metric hasn’t moved.

This happens because somewhere between “here’s what we need to measure” and “here’s what we’re shipping next sprint” there’s a massive gap.

We call it strategy, but most teams treat it like magic; throw enough brainstorming sessions at the problem and hopefully something sticks.

I’ve watched dozens of teams build perfect KPI trees that never generate a single useful decision. The tree sits in a deck, gets referenced in planning meetings, maybe gets updated once a quarter. Meanwhile, the team keeps shipping features based on whoever argued loudest in the last roadmap discussion.

The real problem? We’ve gotten good at building KPI trees but terrible at turning them into strategies. We have this diagnostic tool that tells us exactly what to measure, but no systematic way to figure out what to actually do about it.

The Strategy Bridge Framework

The Strategy Bridge transforms your KPI tree from a measurement tool into an action-generating machine.

The core insight: every strategy is just a hypothesis about moving a specific part of your KPI tree.

Phase 1: Node Selection

You can’t interrogate your entire KPI tree.

Pick 1-2 driver metrics or 3-4 input metrics where you have the most leverage.

Two criteria:

• High Impact: Moving this metric meaningfully affects your North Star

• Direct Influence: Your team can actually take actions that affect it

Skip purely lagging indicators or metrics outside your team’s control.

💡 Types of metrics Driver metrics sit in the middle of your KPI tree. They’re the 2-3 key behaviors or outcomes that directly move your North Star. Think “Weekly Active Users” or “Feature Adoption Rate”. They’re not your ultimate goal, but they’re the critical path to getting there.

Input metrics are one level deeper. The specific, controllable actions that feed into drivers. If your driver metric is “Feature Adoption Rate”, your input metrics might be “Onboarding Completion”, “In-App Tutorial Views” or “Feature Discovery Click-Through Rate”.

The tradeoff: Driver metrics have bigger impact but less direct control. Input metrics give you more levers to pull but require connecting more dots to see North Star movement. Pick drivers when you need breakthrough impact. Pick inputs when you need quick wins or when your drivers are stuck and you need to work at a more granular level.

Phase 2: Node Interrogation

For each selected node, ask the Influence Question: “What are 3-5 things that could realistically move this metric in the next quarter?”

Don’t overthink it.

You’re looking for testable hypotheses, not perfect answers.

Example: Your driver metric is “Advanced Search Feature Adoption”. Exit surveys reveal that 40% of first-month churners say your product “doesn’t have the search functionality I need”.

Plot twist: Your product has advanced search. It’s buried three clicks deep.

Users are literally canceling paid subscriptions because they can’t find a feature that already exists.

Your influence hypotheses then might be:

• Adding a prominent search bar to the main dashboard

• Including advanced search in the onboarding tutorial

• Sending day-2 emails highlighting search capabilities

• Adding contextual search hints when users browse large datasets

• Creating a “power user shortcuts” tooltip that surfaces during frustration moments

Phase 3: Hypothesis Prioritization

Most PMs stop here or try to do everything at once. Both fail.

Rate each hypothesis on three dimensions:

• Impact: How much could this move the metric? (1-5)

• Confidence: How sure are we this will work? (1-5)

• Effort: How much work to test? (1-5)

The winners aren’t the highest impact; they’re the best Impact × Confidence ÷ Effort ratio. This is called the ICE Framework.

Phase 4: Hypothesis Packaging

Most frameworks fall apart here. They give you prioritized ideas but no way to turn them into strategies.

Each strategy needs:

• The Hypothesis: “We believe that [specific action] will move [specific metric] by [approximate amount] because [our reasoning]”

• The Test: How we’ll validate this hypothesis in the smallest way possible

• The Scale Plan: If the test works, how we’ll roll it out

• The Success Criteria: Exactly what metrics need to move to consider this successful or what are the outcomes we’re expecting

For the Advanced Search adoption example, a strategic initiative might look like:

• Hypothesis: “We believe that adding a persistent search bar to the main dashboard will increase Advanced Search adoption by 40% and reduce first-month churn by 15% because users currently abandon our product believing we lack search functionality they specifically need”.

• Test: A/B test with 50% of new users seeing the prominent search bar, measuring both feature usage and 30-day churn rates.

• Scale Plan: If test increases search adoption by 25%+ and reduces churn by 10%+, roll out globally based on user behavior patterns.

• Success Criteria: Advanced Search adoption increases from 20% to 30%+ within first week and first-month churn decreases from 40% to 35% or lower.

Making It Systematic

The Strategy Bridge works at every level of your KPI tree.

Stuck on your North Star?

Use Node Interrogation to identify which supporting metrics have the most potential, then dive deeper.

Driver metrics not moving?

Work down to the input metrics where you have direct control.

Here’s what this looks like in practice:

• B2B SaaS: A team struggling with “Active Workspace Usage” discovered their driver metric “Cross-Team Collaboration Events” barely registered in the first 30 days. Node Interrogation revealed that teams invited colleagues, but those invited users rarely engaged because they weren’t shown relevant shared content during onboarding. Their hypothesis: Surface 3-5 workspace items the inviter recently edited during the new user’s first session. Test result: 3x increase in invited user activation, 40% lift in workspace retention.

• E-commerce: Another PM working on “Customer Lifetime Value” noticed their “Second Purchase Rate” was abysmal. Instead of generic retention campaigns, they interrogated the metric and found that customers who bought from 2+ categories had 5x higher repeat rates. Their hypothesis: Show complementary category recommendations immediately after first purchase. Test result: Second purchase rate increased 60% in the test segment.

• Fintech: A team fixated on “Loan Application Completion” was shipping UI improvements with minimal end user impact visible. Node Interrogation on “Document Upload Success” revealed users abandoned during bank statement uploads. Their hypothesis wasn’t better UI; it was letting users link bank accounts directly instead. Test result: Completion rate jumped from 45% to 78%.

The pattern? Each team had metrics telling them something was broken, but no systematic way to turn that knowledge into testable strategies. The Strategy Bridge gives you a repeatable process.

The key is treating each strategic initiative as a hypothesis you can test, not a commitment you have to see through. Most hypotheses will be wrong, that’s expected. The goal is to systematically test your way to strategies that actually work.

Where Most PMs Go Wrong

I’ve seen teams derail this process in predictable ways:

• Skipping Node Selection: Trying to generate strategies for every metric in your KPI tree. You end up with 47 half-baked ideas and no clarity about what matters. Pick 1-2 nodes maximum. Do those well.

• Confusing Hypotheses with Solutions: Writing “improve onboarding” instead of “we believe adding a 3-step tutorial will increase Day 7 activation by 25% because users currently abandon when they hit the blank dashboard”. Vague strategies produce vague results.

• Optimizing for Completeness: Spending three weeks researching every possible influence factor before testing anything. The Strategy Bridge isn’t about finding the perfect hypothesis, it’s about systematically testing your way to what works. Ship your first test within a week or you’re doing it wrong.

• Ignoring the Effort Variable: Prioritizing high-impact hypotheses that require six months of engineering work. If you can’t test it in 2-4 weeks, break it down or pick a different hypothesis. Velocity matters more than perfection.

• Treating Strategies as Commitments: Continuing to build out a strategy after the test shows marginal results because “we already started”. The whole point of the framework is to fail fast on bad hypotheses. If your test doesn’t hit success criteria, kill it and move to the next one.

The teams that make this work are ruthlessly focused on small nodes, specific hypotheses and fast tests. The ones that struggle are trying to boil the ocean.

Your Next Steps

Here’s your challenge: Pick one metric from your KPI tree that’s been stuck for the past two quarters. Run it through the Strategy Bridge this week:

1. Choose 1-2 high-impact metrics where you have direct control

2. Write down 3-5 influence hypotheses for each metric

3. Score them on Impact × Confidence ÷ Effort

4. Turn your top 2 hypotheses into complete strategies with success criteria

5. Ship your first test within 7 days

Not next month. Not after the next planning cycle. This week.

The difference between KPI trees that collect dust and ones that drive decisions isn’t the quality of the tree, it’s having a systematic process to turn measurements into testable strategies.

You built the diagnostic tool. Now use it.

What’s one metric from your KPI tree that’s been sitting in your quarterly review deck for the past six months? What’s your hypothesis about what might actually move it?

This is the second post in a series about turning metrics into action. Part 1 covered building KPI trees that pass the Tuesday Afternoon Test.

Part 2 (this post) shows you how to turn those trees into strategies.

The system only works if you do both.

Thanks for reading RoadToPM! make sure to subscribe to stay up-to-date ✨✨✨

Subscribe now

Early in my career consulting, while working with a client company, I observed something that stuck with me. One of the client's teams was praised internally for dramatically improving a key customer experience metric – think 'After Order Contact Rate' (AOCR), which ideally goes down when fewer customers have post-order problems. They'd cut it by half, a figure that drew significant praise within the company. While impressive on the surface, the sheer speed of the change raised a flag for me; deep-seated user problems rarely vanish overnight. That initial skepticism lingered.

Then came my own experience, a week later. My order, well past its delivery date, status mocking me: "Shipped". Time to contact support. Where was the button? Order History yielded nothing. The Help section was a maze. After minutes of increasingly angry clicking, I found the escape hatch: Account → Settings → Order Support → Contact Us. Buried three layers deep.

The support agent, once reached, casually confirmed it: a flood of complaints since the "new contact process" rolled out. Our app store reviews were brutal, dozens of fresh one-star ratings hammering the impossible search for help.

The team hadn't solved customer problems. They'd made it harder to report them. The metric looked stunning; the reality for customers was worse. They had created what I like to call a "Work of Fiction”.

What is “Work of Fiction”?

There are so many different ways in which “Work of Fiction” could manifest, but I’ve been able to notice that majority of the time it presents itself in one of the following 4 common forms:

1. Appears to solve a problem based on surface-level metrics.

2. Actually shifts the problem elsewhere, masks it, or creates new issues.

3. Often trades user experience for a number on a dashboard.

4. Ultimately serves the creator's narrative more than the user's reality.

These solutions tell a story of progress internally, while the actual user experience tells a different, often frustrating, story. When we celebrate these fictions, we incentivize looking good over being good.

This isn’t unique to e-commerce:

• The appointment availability illusion: A healthcare network claims reduced wait times. The trick? Their booking system now simply says "No appointments available" once a threshold is hit, instead of showing the real, long wait. Patients can't even get on the list.

• The marketing lead mirage: A marketing team hits its qualified leads target with a broad campaign. Sales drowns in unqualified leads, wasting time and closing fewer deals. Marketing "solved" lead generation by creating a problem for sales.

• The Onboarding Velocity Trap: A subscription software company wants to increase its "Activation Rate" (users completing key initial steps). They drastically oversimplify onboarding, removing tutorials for features and skipping crucial settings just to get users through the flow faster.

Think about your own industry. Which metrics get celebrated? Could any recent "wins" have quietly made things worse for someone else?

Why do smart teams write fiction?

Very few teams truly intend to make things worse. Fictions usually arise from the system, not malice.

1. The Pressure Cooker: Quarterly goals demanding rapid, visible wins. Performance reviews tied to specific metrics. Internal competition for resources. Under pressure, the path of least resistance might be optimizing the metric, not the underlying reality. If hitting the after order contact rate target is all that matters, hiding the button becomes a grimly rational choice.

2. The Disconnection Dilemma: Strict team boundaries mean product teams often don't see the ripple effects of their decisions on customers or colleagues in support or sales. They rely on metrics that only tell part of the story, looking good on the surface while missing what truly matters. Data summaries, like averages or totals, hide individual user struggles. In this environment, questioning a metric 'win' can feel like rocking the boat. This disconnection breeds blindness, not bad intent. Sometimes, teams know they're gaming the system, usually in high-pressure cultures where failure isn't tolerated.

Spotting the fiction: Reading between the lines

Develop a nose for narrative illusions.

What are things to watch for?

1. Metric Miracles & Qualitative Disconnects: A key metric skyrockets, but user feedback (support tickets, reviews, social media, NPS comments) screams frustration. If the numbers look great but the mood is sour, dig deeper.

2. Shifting The Burden: One team's win coincides perfectly with another team's pain. Support requests drop, but email volume or social media complaints surge. Marketing leads increase, but sales conversion rates tank. Problems rarely vanish; they just move. Track related metrics together.

3. Requirement Theater: The solution technically meets the requirement but violates its intention. Asked to "make registration easier", a team removes validation, causing downstream account errors. If explaining precisely how the solution works feels uncomfortable or requires careful wording, it's probably violating the spirit.

4. Ignoring The Root Cause: The fix seems too easy, avoiding the messy root cause. It addresses a symptom, letting the real disease fester.

From fiction to reality: How to build real solutions

Escaping the fiction trap requires conscious effort:

1. Use Balanced Metrics (Kill Isolated Metrics): Never track a key metric in isolation. Pair it with a counter-metric or a qualitative measure.

   • Balance Efficiency with Effectiveness: Don't just aim to lower the Support contact rate. You must also track Issue resolution satisfaction to ensure that when customers do need help, their problems are actually solved effectively.

   • Balance Quantity with Quality: Tracking Feature adoption rate (how many people use it) isn't enough. Pair it with Task completion success rate for that feature to understand if people are actually finding it usable and successful.

   • Balance Speed with Overall Experience: While improving Page load speed is often beneficial, always monitor its impact on Conversion rate or User satisfaction to confirm that speed improvements haven't broken something or inadvertently harmed the user experience.

   • Balance Acquisition with Realized Value: Measuring Onboarding completion rate shows users are getting in, but pairing it with 30-day active usage reveals if they're staying and actually getting ongoing value from your product.

   • ✅ Action: In your next metrics review, identify your top ones. Propose a balancing metric for each. Report them together, always.

2. Create Skin-in-the-Game & Embrace Qualitative Insights: Ensure teams feel the impact of their work.

   • Don't just map the customer journey; live it. Mandate regular time for using your own product to achieve real customer goals.

   • Have product managers spend time handling support tickets related to their features.

   • Present customer quotes and video clips alongside metric charts.

   • Don't just rely on quantitative data; use interviews, usability tests and feedback analysis to understand the why.

3. Distinguish Symptoms from Causes: Move beyond surface fixes.

   • For any metric-improving initiative, ask: "Why do customers have this problem in the first place?"

   • Use the "Five Whys" relentlessly to trace issues back to their roots.

   • ✅ Action: Take your current top priority metric. Ask "Why does this metric matter?" five times. Is your solution aimed at the first answer or the fifth?

4. Redefine Success (For Leaders): Reward reality, not just appearances.

   • Celebrate teams that identify and solve root causes, even if it takes longer.

   • Praise honest look-backs that reveal hidden problems.

   • Focus rewards on the actual impact delivered (the outcome), not just on shipping features (the output). Ask 'did it solve the problem?' not just 'did we launch it?'

   • Review how metrics were improved, not just that they improved.

5. Foster Cross-Functional Accountability & Truth-Telling: Break down barriers between teams and make it safe to be honest.

   • Align teams like tech and customer support teams with shared goals focused on improving the overall customer experience or resolving user issues, not just team-specific metrics.

   • Create psychological safety. Can someone flag a metric as "too good to be true" without fear? Celebrate teams that identify unintended negative consequences of their own work.

Not all metric focus is fiction

Let's be clear: optimizing metrics isn't inherently bad. It works well when:

• Metrics directly reflect genuine user benefit (e.g. faster load times leading to less waiting).

• Solutions achieve the same outcome with less effort (true automation).

• The easiest way to improve the metric is the best thing for the user.

The difference is alignment: In genuine solutions, the metric's story matches the user's reality. In fiction, they diverge.

Conclusion: Build reality, not fiction

Works of Fiction is dangerous because it corrupts our understanding of progress. We mistake movement for advancement, narrative for reality.

Product development isn't about telling compelling stories in slide decks; it's about building better realities for the people who use our products. This requires the courage to look beyond convenient numbers, to question our own successes and to prioritize lasting improvement over fleeting applause.

Your Next Steps:

• Audit: Which of your key metrics could incentivize fiction?

• Observe: When did you last silently watch a real customer use your product?

• Question: For your recent "wins," how exactly did the metric improve? What might be the unseen cost?

• Balance: What counter-metrics can prevent optimizing one thing at the expense of everything else?

Let's commit to building products grounded in truth.

Like what you’ve read here? Make sure to share RoadToPM with others ✨

Share RoadToPM

Cheers from your companion along your product crafting journey :) make sure to subscribe to stay updated with the latest ✨ I post every Monday/Tuesday - so make sure to drop your email to receive the latest.

You know that feeling when your team is shipping features left and right, everyone's working overtime and six months later... your business metrics haven't budged? Yeah, that feeling.

The problem isn't that your team isn't working hard enough. The problem is the massive disconnect between what you're building and what actually impacts your business.

Enter KPI trees – your map for connecting what your team builds to what actually matters to the business. Let's break down how to create one that actually works.

What’s a KPI Tree?

A KPI tree is a simple visual framework that breaks down how your high-level business goals break down into the metrics your team can actually influence day-to-day.

The structure typically flows from top to bottom:

• North Star: The ultimate business objective your product is driving toward (revenue growth, profit margin).

• Supporting Metrics: Critical measurements that directly impact your North Star metric.

• Driver Metrics: Specific product levers your team can optimize.

• Input Metrics: Concrete daily activities and decisions within your team's control.

The true value of this really happens when everyone on the team can trace a direct line from "what I'm working on today" to "how this helps the business".

What’s wrong with most KPI Trees?

Most KPI Trees are just sitting somewhere collecting dust. Let’s not pretend otherwise.

You've seen this movie before. Someone spends weeks crafting the perfect measurement framework. Everyone nods approvingly in the big review meeting. Then that’s it. It’s forgotten entirely a month later.

Why? Because most KPI Trees are fundamentally broken from the start.

• Too abstract – Packed with fluffy metrics nobody actually knows how to influence. "Increase customer delight" sounds nice until you realize nobody knows what levers to pull.

• Missing the middle – Great at high-level business goals, great at listing daily tasks, but with zero connection between them.

• Copy-pasted from somewhere else – Some PM found a great article about how Netflix measures success and decided those exact same metrics should work for your completely different business. They won't.

• Orphaned metrics – A beautiful diagram where nobody actually owns moving any of those numbers. "Who's responsible for this?" gets met with awkward silence and averted eyes.

• Abandoned – Created once in a burst of strategic enthusiasm, then left to wither and die.

Here's the truth: If your KPI tree isn't actively influencing decisions on a Tuesday afternoon when your team is debating what to work on next, it's just a pretty diagram that makes you feel strategic. You either build your tree into existing meeting rhythms, use it explicitly when making tough calls on priorities and update it when you learn something new... or don't bother creating one at all.

Let’s actually build one that’s useful just for example

Enough talk about how broken KPI trees can be. Let's build one that won't end up in the digital trash next month.

I'll use a B2B subscription-based business software product (i.e. SaaS). Not because it's special, but because it's concrete. You can adapt this approach to whatever you're working on.

Step 1: Start with your North Star

Start with something real. Not a buzzword, not a vanity metric, not some fancy consultant-speak. The actual, honest-to-goodness measure of whether your business is working or not.

For most businesses, this is dead simple: revenue or profit. Cash in the door. Money in the bank.

Your North Star should be:

• Actually tied to business survival – Not how many likes your product demo got on a social media post.

• Something you can count – Preferably in dollars, not "engagement" or "delight" or other fuzzy concepts.

• Instantly clear to everyone – From the CEO to the newest hire, everyone should get it immediately.

For our example business, we'll use Annual Recurring Revenue (ARR). Simple. Clear. No ambiguity about whether we're winning or losing.

Don't overthink this part. If your business needs money to survive (hint: it does), then measure the money.

Step 2: Find the levers that actually move money

Now we’re getting somewhere, forget the 42 metrics that your analytics dashboard tracks. Ask yourself, what are the 2 to 4 numbers that, when they move, your North Start inevitably follows?

These aren't nice-to-haves. These are the direct pipelines to your bank account.

To spot them, ask two brutally simple questions:

• "If this number goes up, does money follow?" – Not eventually, not theoretically, but reliably and soon.

• "If this number tanks, are we screwed?" – If the answer is "we'd be fine," it's not a real driver.

For most subscription businesses, it's dead simple:

Those basic components of your revenue formula? They're not just math. They're your supporting metrics - the first real branches of your KPI tree.

For our example:

• Customer Count – How many people are paying you money? Plain and simple.

• Average Revenue Per Customer – How much are they paying? No fancy acronyms needed.

• Retention Rate – Are they sticking around or running for the exit?

That's it. Three branches. Not fifteen. Not thirty-seven "critical metrics". Just the honest truth about what moves the money.

If any of these feels like a stretch, you're probably fooling yourself.

Step 3: Get specific about what moves those dials & levers

Now we're getting concrete. Each of those big levers has smaller levers connected to it. Let's give them names.

Don't make this complicated. This isn't the time for creativity or showing off your business school vocabulary. What actually influences these numbers? That's all we care about.

For Customer Count:

• New Customer Acquisition – Fresh new customers coming in the door.

• Reactivation of Churned Customers – People who left but came back.

For Average Revenue Per Customer:

• Initial Contract Value – What they pay when they first sign up.

• Expansion Revenue (Upsells) – Getting existing customers to pay you more.

No theoretical metrics. No "engagement scores" or other fluffy nonsense. Just the honest factors that move the needle.

Our tree is growing now, but with actual branches that matter - not decorative ones that look pretty in presentations but wither when real work begins.

Our tree is growing:

Step 4: Find what your team can actually have control over

Here's where most KPI trees crash and burn. They stop at lofty metrics nobody knows how to directly influence. So let's not do that.

For each driver, what specific inputs can your team actually change through their work on Tuesday afternoon? Not theoretical levers. Real, tangible actions that move numbers.

For New Customer Acquisition:

• Lead Generation – How many potential customers are we getting into our pipeline?

• Demo Request Rate – Are people interested enough to see how the thing works?

• Demo-to-Close Rate – Can we convince them it's worth paying for?

For Customer Retention:

• Support Ticket Resolution Time – How fast do we fix problems when they happen?

• Feature Adoption Rate – Are customers actually using the stuff we build?

Now we're talking! These are numbers real humans can actually move. A marketer knows how to get more leads. A salesperson knows how to close more demos. A support person knows how to resolve tickets faster.

This isn't strategic hand-waving anymore. This is a map that connects what people do all day to the money coming in the door.

Our tree is getting more detailed and actionable:

These are metrics your product and engineering teams can actually impact through their work. If they can't point to which specific metric their current project influences, they're probably working on something that doesn't matter.

Step 5: Make metrics personal or don’t bother

A KPI tree without owners is just a road trip with no driver. The car looks great sitting in the driveway, the map's all marked up with destinations, but nobody's actually driving. Without someone gripping the wheel, you're not going anywhere.

For each metric that actually matters:

• Pick one human being who’s responsible for it - not a department, not a team, a person with a name.

• Write down the honest truth about where you stand today - no sugar-coating, no aspirational thinking.

• Set a real number you're aiming for - not "improve" or "optimize" but an actual figure that either happens or doesn't.

• Decide how often you'll check - and stick to it whether the news is good or bad.

Create a dead-simple table:

Ownership isn't a fancy title on a slide. It's a habit that has to become as normal as checking your messages. Here's what works:

• Start every review meeting with a 5-minute "numbers check" – not as an afterthought, not when there's good news to share, every single time.

• Put the metrics where they're unavoidable – a dashboard on the wall, pinned to the top of your chat app, an automated daily Slack message, wherever people can't pretend they didn't see them.

• Make "how's your number doing?" as casual as asking about lunch plans – the moment it feels like an interrogation, you've lost.

• Celebrate honest bad news over comforting lies – When someone says "My number's down 20%," that's not failure—that's the starting point of progress. The only real mistake is hiding reality.

• Swap who owns what every quarter – fresh eyes catch what veterans have learned to ignore.

This isn't about creating more work. It's about making the important work visible. Without this rhythm, your beautiful KPI tree becomes just another useless artifact – impressive in the meeting where it debuted, forgotten by Friday and completely abandoned a few weeks later.

Like that expensive bike you bought in January that's now collecting dust in storage, your unused metrics framework just becomes an awkward reminder of good intentions that never translated into action.

What makes a KPI Tree useful?

The power of a good KPI tree is dead simple: it connects dots that should have been connected all along. When your tree works, the fog lifts:

• Your PM improving search doesn't have to hope her work matters - she traces the exact path: better search → more product views → higher conversion → real revenue.

• Your engineer fixing payment bugs isn't lost in code - he's directly watching cart abandonment drop and sales climb.

• Your support team closing tickets faster isn't just hitting arbitrary SLAs - they're directly feeding your retention numbers.

This isn't corporate strategy theater. It's Tuesday afternoon and everyone from marketing to engineering can point to exactly how their day's work translates to money in the bank. No more guessing. No more "trust me, it's important". Just a clear line of sight from what you're doing right now to what keeps the business alive.

How to use it to make decisions and not have it collect dust?

Most KPI trees die a quiet death in some forgotten Miro board or Google doc. A useful KPI tree isn't a document - it's a decision-making framework that shapes what happens every day.

Here's how to keep yours alive:

• Put it to work in prioritization meetings

  • Stop asking "is this important?" and start asking "which metric will this move and by how much?"

  • If you can't answer that question, you're probably working on the wrong thing.

  • Let metrics kill projects before they waste everyone's time.

• Treat it as a living document, not a carved monument

  • Your first tree will be wrong in places - that's fine.

  • Update it as you learn which levers actually move your business.

  • Kill metrics that don't predict outcomes, add ones that do.

• Make it part of everyday language

  • Don't just email it out and hope magic happens.

  • Have team members explain how their work connects to specific metrics.

  • Create rituals where people trace their work's impact up the tree.

• Build the simplest possible dashboard

  • For each key metric, show what drives it and what it influences.

  • During reviews, always ask: "What's changing, why is it changing, what should we do about it?"

  • Show trends over time, not just point-in-time numbers.

Reminder ⏰ A KPI tree pinned to your wall but ignored in meetings is just expensive wallpaper. The value comes when it shapes decisions, kills bad ideas early and focuses everyone on what actually moves money.

What traps should you be on the lookout for?

Your KPI tree isn't bulletproof. Here are the 4 main silent killers that will turn your framework into dangerous nonsense:

• Confusing coincidence with cause

  • You launch a feature, revenue spikes and high-fives erupt across the office.

  • Reality check: That "win" was actually from the marketing campaign that launched the same day.

  • Always validate cause-effect with controlled rollouts or segmented analysis.

  • Ask: "What else changed during this period that could explain these results?"

• Drowning in too many metrics

  • The most powerful KPI trees focus on 5-7 core metrics that truly matter.

  • Every additional metric dilutes attention and creates noise.

  • Be ruthless about cutting metrics that don't directly connect to outcomes.

  • When you try to track everything, you end up focusing on nothing.

• Being blind to qualitative signals

  • Your dashboard shows green across the board while users are quietly hating your product.

  • I've watched teams celebrate conversion targets while users rage-clicked through painful flows.

  • Numbers lie when they lack context.

  • Pair quantitative data with qualitative insights (support tickets, user interviews, session recordings) to uncover the truth behind the numbers.

• Creating bad incentives

  • What you measure becomes what people optimize - sometimes with disastrous side effects.

  • Support teams racing to "close tickets fast" while leaving customers with unsolved problems.

  • Sales teams hitting "demo request" targets by misleading prospects about features.

  • Always ask: "How could this metric be gamed in a way that hurts the business?"

Sanity check and lookout for trade-offs: A flawed KPI tree isn't just useless - it's actively destructive. It creates false confidence, rewards the wrong behaviors and blinds you to what's really happening with your business.

What can I do today if my team doesn’t have one?

1. Open a doc and write down your North Star metric.

2. List the 2-3 metrics that directly drive it.

3. Book 30 minutes with a colleague to sanity-check your thinking.

4. Schedule a “KPI Tree Workshop” with key stakeholders:

   • 15min: Align on North Star metric

   • 15min: Identify supporting metrics

   • 20min: Map driver metrics for each branch

   • 10min: Assign initial owners and set next steps

Don't overthink it. An imperfect KPI tree that gets used is infinitely better than a perfect one that sits in a forgotten doc.

What to conclude from all of this?

Let's cut through the fancy talk: a KPI tree isn't about mathematical perfection. It's about:

• Creating clarity where confusion reigns

  • Everyone understands exactly what matters to the business.

  • No more arguing about priorities based on opinions alone.

  • A shared language for discussing impact that transcends roles and departments.

• Connecting everyday work to actual outcomes

  • Engineers see how fixing bugs feeds revenue.

  • Designers understand how reducing friction drives conversion.

  • Marketers know which acquisition channels actually pay off.

• Revealing the truth when things aren't working

  • When you ship features but metrics don't move, the tree shows you why.

  • No hiding behind vanity metrics or activity-based success.

  • It forces the hard conversations that actually lead to improvement.

The next time you're debating priorities or wondering why all your hard work isn't moving the needle, your KPI tree will be there - not as a theoretical exercise, but as an honest map back to what matters.

Build it. Use it. Refine it. And watch as your team's endless activity finally transforms into actual impact.

Cheers from your companion along your product crafting journey :) make sure to subscribe to stay updated with the latest ✨ I post every Monday/Tuesday - so make sure to drop your email to receive the latest.

Claude Desktop is brilliant at many things, but it has one glaring limitation: it can't access the internet on its own. It's like having a genius researcher who's been locked in a library that stopped adding new books in October 2024.

In this guide, I'll show you how to give Claude internet access so it can search for information, visit websites, and access online resources—all without requiring deep technical expertise.

We'll use something called the Model Context Protocol (will be explained later in the post), which is simply a way for AI assistants like Claude to communicate with external tools, in this case, a web browser.

Why this matters

Without internet access, Claude is severely limited:

• It can't tell you about recent events or breaking news

• It can't access updated documentation or references

• It can't retrieve specific information from websites

• It's stuck with potentially outdated information from its training cutoff (of Oct 2024)

With internet access, Claude transforms:

• From "I don't know about that recent product launch" to "Here's what the company announced yesterday"

• From "I can't access that website" to "I've analyzed that webpage and here's the key information"

• From "My knowledge is limited" to "Let me find that for you"

This capability isn't just for developers or technical users — it's for anyone who wants to multiply their productivity through AI.

What you’ll need

Nothing complicated:

• A computer running Windows, Mac, or Linux

• Claude Desktop app installed

• Python and pip installed (I'll explain this simply)

• Basic comfort with running a few commands (if you can copy-paste, you'll be fine)

• Some patience and perseverance in case you get stuck – there’s a dedicated section to help you get unstuck below too

• The MCP Fetch server (will explain how to set it up below, no need to download anything yet)

That's it. No programming experience needed, no complex setup, just a straightforward process that anyone can follow.

Step-by-step guide

Before we start: MCP (Model Context Protocol) is like a USB-C port for AI. Just as USB-C connects your devices to monitors or chargers, MCP connects Claude to tools—in our case, a tool that gives it internet access.

1. Install Python (if you don't already have it)

What is Python? Python is a programming language that's widely used for various applications. Think of it as the engine that will run our internet-connection tool for Claude. Don't worry — you won't need to write any Python code yourself!

If you're not sure whether you have Python installed:

• On Windows: Open Command Prompt and type python --version

• On Mac/Linux: Open Terminal and type python3 --version

If you see a version number (like "Python 3.13.2"), you're good to go. If not, download and install Python from python.org. During installation, make sure to check "Add Python to PATH."

What is a Terminal/Command Prompt? These are apps on your computer that let you type commands directly to your computer instead of clicking buttons in a regular app. Think of it as a text-only way to tell your computer what to do. We'll only use it for a few simple commands.

2. Install the MCP Fetch Server

Open your computer's terminal:

• Windows: Search for "Command Prompt" in the Start menu

• Mac: Open "Terminal" app from Applications > Utilities

• Linux: Use your distribution's terminal application

Then run:

pip install mcp-server-fetch

What is pip? Pip is Python's package installer—it's a tool that comes with Python that lets you easily install additional software written in Python, like our MCP Fetch Server.

What is the MCP Fetch Server? This is a small program that acts as a bridge between Claude and the internet using the MCP (Model Context Protocol). It receives requests from Claude to look up information online and returns the results. This is what gives Claude its web browsing capabilities.

3. Configure Claude Desktop to Use Your Fetch Server

1. Open Claude Desktop on your computer

2. Access the Developer settings:

   • Mac: Click on the "Claude" menu, then "Settings", and select the "Developer" tab

   • Windows: Click on "Settings" and navigate to the "Developer" tab

3. Click the "Edit Config" button, which will open a configuration file – if it doesn’t open automatically in an editor, open the file titled claude_desktop_config.json in your preferred text editor.

   

4. Add the following text to the file:

{
	json"mcpServers": {
	  "fetch": {
	    "command": "python",
	    "args": ["-m", "mcp_server_fetch"]
	  }
	}
}

5. Save the file and close it

6. Restart Claude Desktop completely (quit the application and reopen it)

When you restart Claude, you should see a small hammer icon in the bottom-right corner of the chat interface. This indicates that Claude now has access to tools - specifically, the Fetch tool we just configured.

If you don't see the hammer icon, try these troubleshooting steps:

• Double-check that you saved the configuration file correctly

• Make sure you installed the mcp-server-fetch package correctly

• Verify that you completely restarted Claude Desktop

What to do when you get stuck?

Getting stuck is normal. It doesn't mean you're not technical enough. Even professional developers spend half their time debugging.

If something's not working:

1. Double-check the basics: Is your server running? Did you enter the correct configuration in Claude's settings? Is Python configured properly on my environment? Is Claude using the right Python in the config file?

2. Read the error messages: They often tell you exactly what's wrong – you can find error logs that you can use if Claude is unable to load the MCP server by going through settings > developer tab as we did above.

3. Ask for help: Use Perplexity or ask Claude itself what might be wrong (copy-paste & describe the error message you're seeing as well as some surrounding context).

4. Be persistent: Coding is iterative – rarely does everything work perfectly on the first try. This is why debuggers exist. Be patient and don't give up.

Practical ways to use Claude with internet access

With internet access, Claude becomes substantially more powerful. Ask it to visit the CDC website for the latest health recommendations, fetch current IMF economic forecasts, explain React documentation in simple terms or compare project management tools for your specific business needs. In each case, Claude delivers current information tailored to your level of understanding.

Tell it to fetch! Sometimes when I was trying to get it to search the web and it doesn’t do it automatically, I started being more explicit and stating “Use the fetch server as needed”.

Example below with “What are the latest developments in quantum computing that have happened in the past month? Use the fetch server as needed.”

Claude Desktop app will show you a prompt asking for your permission to allow the tool to perform an action. Make sure to review actions carefully prior to approving them.

Best practices

• Verify important information: The internet contains false information. Ask Claude to check multiple sources for critical facts and cite its sources.

• Security matters: The MCP Fetch server respects robots.txt files by default, which prevents accessing sites that don't want bots visiting them. This is good internet citizenship.

• Use internet access thoughtfully: Not every question needs internet access. Save it for when Claude explicitly needs current information or to check specific websites.

• Chunking large websites: If Claude mentions that a website is too large to process at once, ask it to focus on specific sections or use the start_index parameter to read through content in chunks.

Is this worth it?

Yes.

Setting up MCP Fetch takes relatively very little time and immediately makes Claude significantly more useful. The ability to check current information and visit websites removes Claude's biggest limitation.

Don't overthink it. Don't put it off because it seems technical. With this guide, you can have it running before your next coffee break.

Moving Forward: Learn How to Learn

The ability to access and transfer knowledge with LLMs makes learning more efficient and accessible. This is about more than just giving Claude internet access – it's about embracing a new way of learning and working.

Every AI user should have this capability, not just those paying for premium services. Setting up your own MCP Fetch server is simple democratization of AI power.

Have any questions or feedback? Drop them in the comments below!

This is RoadToPM. A newsletter where I (Adam) will use to write about everything product. This is long overdue and something I’ve been putting off for a while now. I’ve always wanted to start writing about product management, about my personal experience as a product manager & leader, as well guides to help product managers with their ongoing challenges and support aspiring ones to get started.

To put it simply, a companion along your product journey.

Following a strict problem first principle (generally a good rule of thumb for all product managers), I am seeking your input to share with me challenges you’re currently facing, questions left unanswered or anything you’d like to see content catering to your needs.

Share with me your inputs through in this single question form here:

https://forms.gle/cYdeZQSeiKUV9oFW6

—

To stay up-to-date with what’s yet to come, subscribe now :)

Subscribe now