Stop Bringing Backlogs: Start Telling Money Stories To Execs

Over the last few years, I’ve seen the same pattern again and again. The agile movement helped me a lot. It pushed me to focus on real outcomes for users, and on changes that are clear and valuable for buyers. Product management brings the whole picture and structures the discovery phase. From a product marketing point of view, it became easier to speak about pains and benefits in simple terms. But with executives, something was still missing. 

At first, I spoke about process. Then I tried to speak about “value”. Every time it was too long, too fuzzy, and it didn’t really land. I did not have a short, clear way to explain why a product decision mattered in a language that made sense for executives. 

That’s why Rich Mironov’s talk “Crafting business cases that win” at Productized conference really connected with me. He starts from a very clear point: most executives do not care about our backlogs, frameworks, or internal product practices. They care about revenue this quarter, a few big deals, and strong financial results. If product people stay in the language of process, we sound like we are giving excuses, not helping the company succeed.

 Rich suggests a different way: tell “money stories” instead of feature stories. For every important idea, we should be able to say, in one or two sentences, how much money it could bring or save: more revenue, new business, or lower costs. The numbers can be rough, but the story must end with a currency amount.

He gives simple patterns we can reuse:

• Upsell: number of basic customers × price difference × share who might upgrade → extra revenue per year.

• New market: number of possible customers × revenue per customer × expected win rate → new yearly revenue.

• Support savings: number of tickets × cost per ticket × share we remove → money saved each year.

The goal is not perfect prediction. The goal is to “count the digits”. Is this idea worth a few thousand, a few hundred thousand, or a few million per year? That is enough to see which ideas deserve serious work, and which ones we should drop before asking engineering to estimate them. 

His final takeaways are the ones that stay with me: Talk about money and outcomes with executives, not about process. A rough order‑of‑magnitude is usually good enough. Always give “or” choices: if we add this new request, which exact project do we stop or delay to make space? For product people who struggle to make roadmaps clear for executives, this way of thinking gives a simple bridge between user‑focused work and board‑room discussions. Thanks to Rich Mironov and PRODUCTIZED