David Bland recently shared something that caught my attention: "Reading Money Stories, the new book from Rich Mironov this morning and I appreciated his take on doing discovery. He's been very influential to my work over the past decade or so. You should read anything he writes".

That short endorsement says a lot, not just about a book recommendation, but about a philosophy of product discovery. When someone like David Bland (creator of the EMT System, Extract-Map-Test) says a product thinker has been influential for a decade, I hear a subtext: good discovery is not a one-time activity, and it is not a vibe. It is a discipline built from hard-won lessons about how products actually get funded, built, and adopted.

In this post, I want to expand on what David is pointing to: why Mironov's perspective on discovery matters, what "money stories" implies for product decisions, and how to turn those ideas into a practical discovery habit for your team.

Why a simple book recommendation signals something bigger

David's post is brief, but it highlights three important cues:

He is actively learning ("Reading ... this morning").
He is focused on discovery ("his take on doing discovery").
He values credible, experience-based writing ("You should read anything he writes").

Those cues matter because discovery can get abstract fast. Teams talk about "customer obsession" while shipping features that nobody funds, uses, renews, or champions. A book title like "Money Stories" is a reminder that products live or die inside real economic narratives: budgets, procurement, renewals, switching costs, incentives, and the internal politics of spending.

Key insight: Discovery is not only about what users say they want. It is about understanding the conditions under which someone will pay, adopt, renew, and advocate.

What "Money Stories" suggests about real-world discovery

Even without summarizing every chapter, the phrase "money stories" points to the kind of discovery many teams skip. A money story answers questions like:

Who is the economic buyer, and who is the daily user?
What budget does this come from, and what else competes for it?
What problem is painful enough to justify change right now?
What triggers a purchase, and what kills it?
What does success look like in the buyer's language?

In other words, the story is not "we built a feature." The story is "a specific group had a costly problem, they tried alternatives, something caused urgency, they justified spend, they implemented, and measurable value followed."

That is why David's line about appreciating Mironov's take on discovery resonates. Many discovery approaches focus heavily on desirability (do people like it?) and usability (can they use it?). Those are necessary, but insufficient. Viability is not a checkbox at the end. It should shape what you explore from day one.

Discovery that respects incentives, not just interviews

Product teams often do interviews that unintentionally filter out the truth:

They talk only to friendly users, not budget owners.
They collect opinions, not evidence of behavior.
They ask about future intent, not past decisions.
They validate solutions, not problems and constraints.

A more Mironov-aligned approach is to treat discovery as investigation into incentives and constraints. If you want to build something that survives contact with procurement and quarterly planning, you need to understand the internal math your buyers are doing.

Questions that uncover money stories

Here are a few prompts I have found useful when trying to get beyond surface-level feedback:

"Walk me through the last time you paid for something like this. What happened first?"
"Who had to say yes? Who could have stopped it?"
"What budget line did it come from? Was it pre-approved or fought for?"
"What alternative did you keep because switching was too hard?"
"What would have made you churn at renewal time?"

Key insight: The most useful discovery questions are anchored in real past decisions, because past behavior reveals true constraints.

Connecting David Bland's EMT mindset to better discovery

David Bland is known for helping leaders make faster decisions by breaking down, sharing, and testing risk. That orientation fits perfectly with money-story discovery.

If I translate the spirit of EMT (Extract-Map-Test) into the discovery context David is hinting at:

1) Extract the riskiest assumptions

Not "users will like it," but:

"A director-level buyer will fund this from budget X."
"Security review will not block adoption."
"Implementation can be done in under 2 weeks with existing tools."
"We can prove ROI within one quarter."

2) Map assumptions to evidence you need

For each assumption, define what would count as credible evidence. For example:

A copy of a real buying checklist
A timeline of the last procurement cycle
A quantified cost of the current workaround
A renewal metric that the buyer actually tracks

3) Test quickly with the cheapest experiment that teaches you

This might be:

A buyer interview focused on the last purchase decision
A pricing and packaging page used as a conversation artifact
A "concierge" pilot that proves time-to-value
A security review pre-check before building deep integrations

The point is not to "prove" your idea. It is to reduce the biggest risks early, before you invest heavily.

A concrete example: feature request vs money story

Imagine you are building B2B analytics software.

A user request sounds like: "Can you add scheduled exports to CSV?"

A money story sounds like: "We lose two days each month preparing reports for leadership because data is scattered. I built a spreadsheet workaround. If we could automate this, I can reassign an analyst to higher value work. My VP will fund it if we can show savings and reduce errors. But IT will block any solution that stores data outside our region."

Both start with exports. Only one tells you what matters:

the cost of the problem
who pays
what constraints govern the decision
what outcome defines success

That is discovery you can build a strategy on.

Practical steps to apply this on your team

If David Bland's recommendation nudges you to level up discovery, here are a few lightweight habits that compound:

Create a "money story" template

Keep it simple and consistent. For each opportunity, capture:

Buyer: role, incentives, budget source
Trigger: what made this urgent now
Stakes: cost of the problem, risk of doing nothing
Journey: steps from interest to approval to rollout
Proof: what evidence convinces them it worked

Interview for decision history, not preferences

Make your default interview prompt: "Tell me about the last time you solved this problem." Then dig into approvals, procurement, security, and timelines.

Bring sales, finance, and CS into discovery early

If the product team does discovery alone, you will miss crucial context. People closest to revenue and renewals often have the sharpest view of objections and deal-killers.

Treat pricing and packaging as discovery tools

You do not need a final price to learn. Even a rough packaging hypothesis can reveal whether buyers see this as a tool, a platform, or a nice-to-have.

Track learning, not just shipping

A healthy discovery cadence produces learning artifacts: assumptions tested, evidence gathered, risks reduced. If you cannot point to what you learned this sprint, you might be doing activity, not discovery.

Key insight: Discovery that ignores viability creates products that are easy to build but hard to sell, adopt, and renew.

Why "read anything he writes" is a discovery strategy

David's closing line, "You should read anything he writes," lands because good product writing is compressed experience. It exposes you to edge cases you have not lived yet: stalled deals, failed rollouts, renewal surprises, internal politics, and the messy reality between "user need" and "business result."

If you want to get better at discovery, reading is not a substitute for talking to customers, but it can dramatically improve what you listen for and which questions you ask.

Ultimately, that is what I hear in David Bland's post: a nudge toward discovery that is grounded in reality, focused on risk, and anchored to the real economics of product decisions.

This blog post expands on a viral LinkedIn post by David Bland, Author | Speaker | Creator of the EMT System (Extract-Map-Test) | Helping leaders make faster decisions by breaking down, sharing, and testing risk.. View the original LinkedIn post →