Play the Revenue Hawk: Pressure-Testing Whether Your Feature Actually Makes Money

Pressure-testing a feature's revenue case means proving, with real numbers, who pays, how much, how often, what it cannibalizes, what it costs to serve, and when the company recovers its money — before you ship. A feature that only proves demand ("users want this") has answered half the question. The revenue hawk demands the other half: the money mechanism itself.

Quick answer: A revenue-hawk pressure test forces five numbers before you build — who pays, how much, what gets cannibalized, what it costs to serve, and how fast it pays back. If any answer is "we'll figure it out later," the business case isn't ready to leave the room.

What It Means to Play the Revenue Hawk in a Product Review

Playing the revenue hawk means assigning someone the explicit job of attacking a feature's money mechanism, not its usability. The hawk refuses "users will love it" as evidence of revenue and instead asks who pays, how much, and what breaks the model — forcing the business case to survive interrogation before it survives launch.

Most feature reviews over-index on desirability signals: interviews, prototype reactions, feature-request volume, a promising NPS delta. Those are real signals, but they answer a different question than viability does. A user advocate persona critique exists precisely to stress-test whether people want a thing; the revenue hawk exists to stress-test whether anyone will pay for it, and whether the payment covers what it costs you to deliver.

The hawk is one voice in a broader adversarial-review practice, not a replacement for it. It works best alongside:

• A skeptical engineer, probing feasibility and hidden build cost — see the skeptical engineer persona critique for how that role operates.
• A user advocate, defending real customer need against a purely commercial lens.
• A premortem facilitator, running the wider "how could this fail" exercise described in the four critics premortem panel framework.

If you haven't built out this muscle yet, the complete guide to adversarial thinking is the place to start; the revenue hawk is one of its more specialized, and more frequently skipped, roles.

Why "users will love it" isn't evidence of revenue

Enthusiasm and intent to pay are correlated but not the same thing. People routinely say they'd use a free feature, request it in a support ticket, and rate it highly in a survey — none of which obligates a budget line. The gap between "I want this" and "I will pay for this, at this price, in this budget cycle" is exactly where business cases quietly die post-launch.

The takeaway: desirability evidence tells you to keep exploring; viability evidence tells you whether to fund it. A business case needs both columns filled in, not just the left one.

Build the Revenue Logic Tree Before You Defend the Feature

A revenue logic tree maps the money mechanism as a chain of dependent questions, each one a place the business case can quietly fail. Draw it before you write the business case narrative — the tree exposes which assumptions you've actually tested and which ones you've simply asserted.

Feature ships
├─ Who pays?
│  ├─ End user, direct (upgrade, seat, usage fee)
│  ├─ Buyer's employer (expansion SKU, add-on)
│  └─ Someone else (platform cut, data partner, ads)
├─ How much, how often?
│  ├─ One-time fee vs. recurring
│  └─ Priced to the job done, or priced to the feature?
├─ What does it cannibalize?
│  ├─ An existing paid tier's reason to exist
│  └─ A competitor's job — or your own roadmap
├─ What does it cost to serve?
│  ├─ Marginal infra/support cost per active user
│  └─ Cost that scales with usage vs. stays flat
└─ When does it pay back?
   ├─ Time to recover build + go-to-market spend
   └─ Payback period vs. expected customer lifetime

Each branch is a claim someone in the room should be able to defend with a number, not a hunch. This is also where Jobs to Be Done thinking earns its keep: a feature only commands a price if it's hired for a job the customer already budgets for. The complete guide to jobs to be done is useful here for separating "a job worth paying to solve" from "a nice-to-have wrapped around an existing job."

Two failure patterns show up constantly when teams skip the tree:

1. The single-branch business case. The deck proves willingness to pay and stops, silently assuming attach rate and cost to serve will "work out" — they're the two branches most often left untested.
2. The borrowed-branch business case. A team reuses last year's cannibalization or payback numbers from an unrelated feature because building a fresh estimate feels like extra work the deadline doesn't allow.

The Five Numbers a Revenue Hawk Will Always Ask For

A revenue hawk's questions collapse into five recurring numbers: willingness to pay, attach rate, cannibalization, cost to serve, and payback period. Each one maps to a branch of the logic tree above, and each has a distinct, well-documented way to pressure-test it rather than guess at it.

Willingness to Pay

Willingness to pay is what a segment will actually commit from a real budget, which is a narrower thing than what they say they like. Economist Peter van Westendorp's price sensitivity meter — asking at what price something feels "too cheap to trust," "a bargain," "getting expensive," and "too expensive" — remains one of the more reliable ways to triangulate a real number instead of a single anchored guess.

A revenue hawk pushes back on any willingness-to-pay figure sourced from a single "would you pay $X for this?" question, because that framing anchors the respondent to your number rather than surfacing theirs. Ask for a range across multiple price points instead, and segment the answers by role — the buyer's willingness to pay and the end user's are frequently not the same number.

Attach Rate

Attach rate is the share of the eligible base that actually adopts the paid version, and it is the metric most often modeled on hope. A hawk will ask for the attach rate on your two or three most comparable past launches before accepting a projection pulled from an industry benchmark deck.

• Segment attach rate by cohort (new vs. existing customers) — the numbers rarely match.
• Distinguish trial activation from paid conversion; only the second one is real attach.
• Ask what would have to be true for this launch to beat your own historical rate, and whether that condition is testable pre-launch.

Cannibalization

Cannibalization is the revenue this feature displaces rather than adds — from your own tiers, from a competitor's offer, or from your own future roadmap. Clayton Christensen's work on disruption is the classic warning here: a feature priced to serve an underserved segment can quietly erode the premium tier that funds the rest of the business, especially when it's bundled into a lower price point "to drive adoption."

A hawk asks a blunt question: if this ships as described, which existing SKU loses its reason to exist? If the honest answer is "the one two tiers up," the business case needs to model that loss explicitly, not treat the new feature's revenue as purely incremental.

Cost to Serve

Cost to serve is what one additional active user actually costs you, marginally — support tickets, infrastructure load, success-team time — and it is the branch most business cases skip entirely. Accounting researchers Robert Kaplan and Robin Cooper's activity-based costing work exists precisely because blended, company-wide cost averages hide the outliers that quietly wreck a margin.

Mapping the actual customer journey around the feature — onboarding friction, support contact points, the moments usage spikes — is one of the more reliable ways to find where cost to serve is hiding, because those journey moments are where marginal cost is actually incurred, not where the pricing model assumes it is.

Payback Period

Payback period is how long it takes to recover what you spent to build and launch, weighed against how long the customer is likely to stick around. SaaS Capital's periodic surveys of private software companies have generally put healthy CAC payback somewhere in the 12-to-20-month range, with anything meaningfully longer than that raising real questions about whether the unit economics work at all.

A hawk asks two things here: is the payback estimate built on your own retention data, or an industry-average lifetime that's more optimistic than your churn curve supports? And does the payback clock start at launch, or at the (later) point most customers actually adopt the feature?

Red Flags That Signal a Fragile Business Case

Certain patterns in a business case are reliable tells that the underlying revenue logic hasn't been pressure-tested, even when the topline number looks healthy. A revenue hawk learns to spot these on sight, because they recur across almost every fragile pitch.

Any one of these, on its own, might be a manageable risk with a plan attached. Two or more appearing together in the same business case is usually a sign the revenue logic tree was never fully walked — someone filled in the branches that were easy to answer and skipped the ones that weren't.

Running the Revenue-Hawk Session as a Team Exercise

Running a revenue-hawk session means assigning the role explicitly, walking the logic tree branch by branch, and capturing every unresolved number as a named assumption rather than letting it slide into the deck as fact. The output isn't a verdict — it's a list of exactly what has and hasn't been tested.

A workable structure for a 45-60 minute session:

1. Assign the hawk. Pick someone genuinely willing to be unpopular — ideally someone with finance or revenue-ops fluency, not just the most contrarian person in the room.
2. Walk the tree. For each branch (who pays, attach rate, cannibalization, cost to serve, payback), ask: is this a tested number, a benchmark, or a guess?
3. Flag every guess as an assumption. Don't resolve it in the room — write it down, owner attached, with how it will be validated and by when.
4. Scan for red flags. Run the list above against the current draft before anyone presents it further up the chain.
5. Re-price or re-scope, don't just soften the story. If the numbers don't close, the fix is in the mechanism — pricing, packaging, segment — not in the slide's confidence level.

In Prodinja's prototype, the Stress-Test / War Room is built around a set of adversarial personas — including a revenue-hawk persona — designed to raise exactly these objections before a real stakeholder does. It's a simulated critique experience, not a live financial model: the value is in the prompts it's designed to surface (willingness to pay, cannibalization, opportunity cost) so you can capture them as assumptions inside a Situation and track which ones later get confirmed or falsified as real evidence comes in.

Key Takeaways

• A business case needs two kinds of evidence, not one: desirability (users want it) and viability (someone will pay for it, at a price that clears cost to serve).
• The revenue logic tree makes hidden assumptions visible — who pays, how much, what it cannibalizes, what it costs to serve, and when it pays back.
• Willingness to pay should come from a price-sensitivity method, such as Van Westendorp's, not a single anchored yes/no question.
• Attach rate projections need an internal analog — your own past launches, not an industry benchmark deck.
• Cost to serve hides in journey moments, not in a blended company-wide average; map the journey to find it.
• Free-tier bloat, discount dependence, and one-whale skew are the three most common tells that a business case's math hasn't actually been tested.
• A revenue-hawk session should produce a list of named assumptions, each with an owner and a validation plan — not a softened story.