The Hidden Skill That Separates Great Product Managers

Why the best PMs think like detectives, not just builders

It’s a familiar story, a promising Series A startup burns through $3M in six months. They had brilliant engineers, a visionary founder, but for all their work they had little to show for it.

Over 12 years in high-growth startups like VEED and Revolut, plus front-row seats at dozens of companies I've invested in and mentored, I've seen this pattern repeat many times. You’re left asking why did the start-up fail? And we often hear replies such as “we were too early” or “we weren’t able to raise enough capital”. These responses tend to flatter the founders. Rarely do you hear a convincing data backed analysis of the issues - and that’s often the core problem - the team weren’t able to accurately diagnose what was going wrong before it did. Get the diagnosis right and the solutions tend to be relatively clear, resources can be focused, tasks prioritised and the team can often do a lot more with less.

This is why I now believe strong diagnosis to be an essential skill when hiring, creating roadmaps or building business plans.

"A week of proper investigation costs a fraction of what you'll spend if you commit engineers to building the wrong thing."

Ben Wynne-Simmons, Senior Director Product at VEED.IO

The Skill Everyone Assumes You Have

We assume “diagnosis” as a given - it’s considered a basic skill such as sending emails or doing maths, but it's actually a tricky craft to master and one I think that separates the great PMs (and CEOs for that matter).

You can think of businesses as a resource allocation puzzle. You have limited time, money, and engineering cycles. Where should your team focus? Which features deserve to be in the next sprint? What's actually moving the needle versus what just feels important?

Getting this right can triple your growth. Getting it wrong condemns you to months of redesigns, technical debt, and soul-crushing pivots. I've seen both outcomes up close, and the difference is stark.

The irony? Diagnosis is often the cheapest part of the product development process. A week of proper investigation costs a fraction of what you'll spend if you commit engineers to building the wrong thing. Yet many teams rush straight to solutions.

My Diagnosis Toolkit

I’ve been compiling a list of tools and frameworks I find helpful for doing diagnosis and hopefully you’ll find them useful too. I actually draw a lot from my engineering degree and early career in private equity. They taught me to break complex systems down to understand how they work and the many late nights wrangling financial models drilled numerical analysis into me.

Control Volumes: Simplifying complexity

Internal combustion engines are bewilderingly complex—pistons firing, valves opening, fuel exploding. When something breaks, how do you even begin to diagnose it?

Engineers use "control volumes"—imaginary bubbles you can draw around different parts of the system. You ignore the complexity inside and just track what goes in versus what comes out. Fuel should equal motion, heat, and noise. If the maths doesn't work, you've got a leak. You then proceed to draw smaller control volumes around subsystems until you pinpoint the issue.

I use this often when reviewing conversion funnels and monetization problems. Instead of getting lost in user journey complexity, I draw control volumes around each major step. You can quickly spot leaks and areas to improve without knowing the specifics of any one step.

Vectors: Why Direction Isn't Enough

Early in my career, a mentor told me: "Good lawyers will argue opposite points and both be right." I thought he was being cynical - surely there was a correct answer. Now I realize most business arguments work exactly this way, otherwise there wouldn't be an argument.

I often find the key to moving forward is assigning magnitude to these opposing forces. Imagine two people in a tug-of-war. It’s hard to predict the winner until you learn one is a rhino and the other, a golden retriever puppy.

This transforms how I view pros and cons lists. Avoid adding up the columns. Instead, look for the side with the rhino on it.

Charts Beat Percentages Every Time

"Our engagement increased 3% this month."

This statement is nearly always useless without any context, yet I hear variations constantly. It forces the thinking back on to the listener and triggers a cascade of follow up questions: Over what timeframe? What happened before this? Is 3% within normal variance?

A simple time-series chart answers all these questions instantly. You see magnitude, volatility, seasonality, and trends at a glance. A picture really does paint a thousand words—assuming you zoom out far enough to see the pattern.

The Fourier Transform of Product Metrics

In the 1800s, Joseph Fourier proved you could approximate any complex wave as a sum of simple sine waves. I often use this as a mental model for product KPIs.

Your monthly active user chart isn't just one number—it's the sum of dozens of product decisions over time. There’s always multiple factors at play and multiple reasons for any one change. But what matters is understanding the relative contributions of the individual changes - to continue the wave analogy - what distinguishes the "ocean swells" from the "ripples."

Which changes drive sustained growth versus temporary blips? This framework helps me prioritise ruthlessly when metrics shift.

The A/B Test Trap

At Revolut, we had an active policy against A/B testing for most decisions. This sounds heretical to many PMs, but the logic is worth considering. The belief was that it’s often possible to do strong analysis up front that may not accurately predict an outcome but should give the high confidence that it’s likely to be positive.

This saved the costs of doing A/B tests which are often not talked about. Tests eat engineering time (as you build multiple variants and testing infrastructure), which delay shippings, encourage incrementalism and may be misleading (for a test you’ll often build an MVP which may well give you different outcomes compared to something that was polished and had the full marketing promotion behind it). Don’t get me wrong - for major changes like pricing structures, absolutely test. But for many product decisions, you should have enough conviction from the diagnosis that the direction is obviously right. The flip side is: should you be building things where you're unsure they'll be beneficial?

The Discipline of Double-Checking

In the rush to move fast, it's tempting to skip the boring work of validation. But building this discipline eliminates most errors before they become expensive mistakes.

Make it ritual and run through a checklist: Do totals add up? Are you analyzing complete data sets or missing 20%? Check min/max values for outliers that skew averages. Watch for survivorship bias. Separate out ratios to identify if changes are linked to the numerator or denominator. Verify statistical significance. Distinguish correlation from causation.

These checks take minutes but prevent months of chasing ghosts.

The Diagnosis Advantage

Great product managers are great diagnosticians first and foremost. They resist the urge to jump to solutions. They think deeply about "what's really happening here?" and then only after they ask  "how should we build it?"

This doesn't make you slower—it makes you precise, efficient and faster in the long run. It’s easy to look busy cycling through features hoping something sticks but it’s far better to identify the real constraint and solve it decisively.

In a world obsessed with shipping fast and vibe coding, the quiet craft of diagnosis has become a superpower. Master it, and you'll soon be ahead.