Let the numbers do the talking

Throughout my career in Product Management, one truth has remained constant. Numbers speak louder than words.

A compelling story for why a product or feature should be prioritized is only as good as the metrics that support it.  Senior leaders, and in particular, the C-Suite, don’t want to hear all the details about your customer interviews, competitor analysis, epics, stories, and so on.  What they want to know is this: how will your idea help them meet their goals?  How will this idea impact the north star metric?  How does improving that north star metric help us hit our revenue targets?  How does meeting those revenue targets unlock future opportunities?  If you want the board and the C-Suite to understand your reasoning, you need to speak their language.  And they talk numbers.

As a consultant at Product People, I’ve gotten to peek behind the curtain at multiple organizations throughout Europe.  Regardless of industry or operating model, the companies that make the most consistent progress are the ones that understand the impact of their decisions.

I learned this lesson early in my career and partly by luck, having worked for leaders who steered my focus back to financial metrics.  Here’s how I learned to let the numbers do the talking.

“Stop, this isn’t a good use of my time.”

Early in my career, I was given a huge opportunity.  I was promoted to Project Manager at a Fortune 1000 company after only working for about 18 months.  I was assigned the number one priority project in the company.  This was my first job after college.  I was 25 years old and felt up to the challenge.  Or so I thought.

After gathering data, interviewing relevant stakeholders, and putting together a plan, I faced the first phase gate. I needed to present to our divisional President to get budget approval.  I created slide after slide after slide of context.  I had a compelling story.  I was ready. 

And then, reality hit me.  Less than 3 minutes into the presentation, the President held up her hand and said, “STOP, this isn’t a good use of my time.  I know you’re new to this, so it’s not your fault.  Someone work with him on how to effectively present to me.”

This sounds like a nightmare scenario for so many young professionals. And in the moment, I felt like a fool.  But in hindsight, this was the best thing that could have happened to me at that stage of my career. 

‍

“Would this move the needle?”‍

After the meeting, our Director of Product pulled me aside and offered his guidance.  He explained to me that executives aren’t interested in knowing all of the details.  They put me in that position because they trusted I would get those details right.  What they wanted to know was simple.  Would this move the needle?

What followed was a master course in crafting a narrative around outcomes and ROIs.  I was taught how to properly define costs and benefits.  How to link leading indicators to lagging metrics.  How to reduce the story to the core points the President actually cared about.  And how that all boiled down to bottom-line economics.

We rebuilt the deck together.  The original 20-slide, text-heavy deck was reduced to three slides focused on the business problem, the costs, the expected return, and a simple execution plan with rough timelines.  I was invited back to present a week later, and the budget was approved.

That lesson paid off a few years later.  I was now a Product Manager at a company with a shared pool of developers.  In the pre-AI world, developer time was like gold.  And all PMs were grabbing for their fair share.

We had to pitch our roadmaps at quarterly planning meetings and compete for capacity.  All PMs had done solid discovery, but the difference was how we presented our findings.  Most stopped after discussing what they wanted to build and what discovery efforts led to their decisions.  I instead focused on how my initiatives would impact the business.  The discovery work gave signals; the signals showed how metrics would be impacted, and the impacted metrics would result in gains to the business.  Framing my roadmap in this way made a measurable difference.  My capacity requests were consistently approved, not because my ideas were better, but because leadership could see what they would get for the investment.  

‍

Saying No - A Lesson in Disciplined Leadership

While consulting for an e-commerce company, an unexpected partnership opportunity appeared out of nowhere.  The prospective partner was a massive company with huge market share, and leadership felt confident that a successful collaboration would elevate our brand status and lead to new revenues.  To make this work, we would need to quickly develop a complex API integration and create unique assets within 2 months.  If we couldn’t meet the partner’s deadline, then we would miss this collaboration opportunity.  But saying yes would mean stopping work in progress mid-quarter.  So, what did leadership do?  They crunched the numbers.

Leadership requested that a few engineering leads run a series of spikes to get a realistic effort assessment of the partnership integration, and asked me and a few other product managers to give an assessment of the opportunity costs of disrupting the work in progress.  The numbers made it clear.  The spikes showed that we could meet the deadline if we dedicated 85% of engineering resources to the remaining 8 weeks of the quarter.  And the impact to our roadmap would mean delaying a high priority conversion target by at least a quarter, which would impact larger company goals.  The risk to expected profits from delaying planned work outweighed the profits we could realistically expect from the partnership.

Leadership told the partner no.  It was a hard decision that put the relationship at risk.  But one based on proper analysis. We delivered the roadmap and hit our targets.  And when the same partner returned a few months later, we could plan the API integration the right way, without disruption.
‍

Guardrails - How to Avoid Analysis Paralysis‍

I know what some readers are thinking.  If we spend all this time assessing, we won’t get anything done.  Analysis paralysis is real, and it shouldn’t be ignored.  But we can protect against it by establishing proper guardrails around when you should dive deep into the numbers.

The real goal in establishing guardrails is to provide PMs and POs with a realistic understanding of what decisions they can make freely and what decisions require extra scrutiny.  It is leadership’s job to provide this guidance. 

Here are some guardrails to consider for your team.‍

Filters - ideas that shouldn’t make it to analysis

• Runway and payback period - Your team should understand financial timelines.  When working at a small startup, time to revenue is often critical.  Quick back-of-the-napkin math can tell you that a giant investment that will take 12 months to complete isn’t viable if you only have 6 months of runway.  Don’t bother with the detailed assessment here.
• Strategic fit - If an idea isn’t aligned with a company’s stated goals, it doesn’t get analyzed, no matter how cool the idea is.  If you are focused on DACH, and you find a promising opportunity in the UK, you park the idea until the strategy expands outside of the DACH region.
• Capacity already committed - If saying yes means missing a commitment to a customer or the board, the default is no.  

Exemptions - do it without a business case

• Legal requirements - This one is simple.  If the law says it absolutely must be done, or you face significant consequences, you do it.  No amount of analysis will change this. 
• Cheap and reversible - A simple A/B test, a quick interface adjustment, a small change to backend data flows behind a feature flag: anything that is quick to implement and easily reversible is usually better suited for test and learn, rather than analysis.
  

Triggers - when a business case is required

• Effort threshold - If your early developer assessment suggests that the effort extends beyond 2 sprints, it’s best to assess.
• High impact - If this concept impacts a significant number of users, touches a critical part of the infrastructure, or has a direct impact on revenue, assess, assess, assess.
• Cross-team dependencies - If your idea will require commitments from other teams, it should be worth your collective time.  
• Irreversible (One-Way Doors) - Platform changes, data migrations, changing vendors… all of these are incredibly difficult to revert.  Run the numbers.  Do it right.

Every Product Manager and Product Owner should understand the role their product plays in the bigger picture.  And it's just as important that they understand exactly what is within their control.  Guardrails don’t slow PMs down. They guide PMs towards where they can move faster, and where they need to stop and do the math.

‍

Parting Words

Proper analysis is hard.  It requires transparency so that all levels of the organization are in alignment on business goals.  It requires restraint so that when a shiny new idea comes into the frame, the impulse to say yes is contained.  It requires a lot of hard work to ensure that your metrics and guardrails are well defined, and your team knows what is actually important.  Letting the numbers do the talking doesn’t mean analyzing everything.  It means knowing which decisions require analysis, doing the analysis properly, and moving fast on everything else.