Most founders build their first real pricing page the same way: three browser tabs open to competitors' pricing pages, a fourth open to a template that says Starter, Growth and Enterprise. The names get swapped for something on-brand, the price points get adjusted up or down a little, and the tier boundaries land wherever they happened to land on somebody else's site.
That approach treats pricing-tier design as a research problem: go study the market, then reverse-engineer a structure from what you find. It is the default advice from pricing consultancies too. Segment your customers by job-to-be-done, then by operational complexity, then by risk and control needs, then build packages around the differences. That segmentation logic is sound. But it assumes the founder doesn't already have the data, and needs to go generate it through interviews, workshops or a consulting engagement.
Founders running their own enterprise or mid-market deals almost never have that gap. They have the opposite problem: the segmentation data is sitting in their CRM, in call notes, in the emails where a deal suddenly needed a second signature. It has just never been read as pricing data. The tier boundaries a founder needs are not out on a competitor's site. They are in the last ten to twenty deals already closed, stalled or lost.
The segmentation logic is right. The starting point is wrong.
Recent pricing guidance converges on a reasonable idea: don't segment by company size, segment by what changes about the buyer's problem as they move from one group to the next. Does the job get more complex? Does more of the organization need to coordinate? Does risk and control become a real requirement? Those are the right questions. The standard answer to "how do I find the answers" is to go build a research process: customer interviews, willingness-to-pay studies, sometimes a pricing consultant.
One consultant who has run roughly four hundred of these engagements makes a related point from a different angle: when a founder says pricing is broken, the actual problem is usually that the product, the positioning and the packaging were never telling the same story in the first place. His fix is also a research sequence, starting with customer interviews to find the job the product is actually being hired to do.
Both of those are legitimate paths. Neither is available, on the timeline a founder actually has, to someone running their own sales process pre-Series-B with no research budget and a board asking for a real pricing page next quarter. What's missing from that advice is the acknowledgment that a founder running deals personally has already been collecting exactly this data, deal by deal, for as long as they've been selling. They just haven't been asked to look at it as a pricing input.
Where your last ten deals already told you where the lines go
Three places in a founder-led sales process generate segmentation data as a byproduct, not as a separate project.
The buying committee that showed up. A deal that closed with one economic buyer and a deal that closed only after five stakeholders signed off are not the same customer wearing a different company size. They are different jobs, different risk profiles and different levels of organizational coordination. If a founder has been mapping who actually shows up on a deal, the roster itself is a segmentation signal: single-buyer deals cluster into one tier, multi-stakeholder deals into another, and the gap between them is usually where a real tier boundary belongs, not an arbitrary seat count.
Where discovery got harder. Some discovery calls surface a single, well-understood problem the buyer can describe in one sentence. Others surface a tangle: multiple workflows, several teams whose processes have to change, a problem the buyer themselves struggles to fully articulate. That difference in discovery complexity is not noise. It's a direct readout of how much product depth, configuration and support that customer will actually need, which is the same question every pricing framework is trying to answer through interviews the founder hasn't had time to run.
Where procurement pushed back. A deal that closed on a signature and a deal that triggered a security review, a data-residency question or a legal redline are different purchases, even at the same contract value. Procurement friction is expensive to generate on purpose, but a founder who has run even a handful of larger deals has already generated it and, in many cases, already has notes on exactly what got asked. Those notes describe, almost line for line, the control and governance requirements that pricing frameworks say should define an upper tier.
Put those three signals next to the last ten to twenty deals, closed and lost, and a pattern usually appears faster than a fresh research process would produce one: a cluster of deals that stayed simple, a cluster that got complicated in a specific and repeatable way, and the point in between where a tier boundary should sit.
The bias this method has to guard against
This only works if the sample includes the deals that fell apart, not just the ones that closed. A founder who builds tiers only from closed-won deals is building pricing around the customers easiest to win, which quietly filters out exactly the complexity a real tier structure needs to price for. A deal that died in procurement because the packaging didn't have an answer for a security review is not irrelevant data because it didn't close. It's some of the clearest data available, because it shows precisely where the current structure has no tier at all.
The practical fix is straightforward: pull closed-lost and stalled deals into the same audit as closed-won, tag each one at the same three points, and treat the resulting boundaries as a first draft rather than a finished pricing page. A reasonable next step is checking that draft against the next three to five live deals in the pipeline before it becomes permanent, the same way any framework gets stress-tested against reality before it's trusted at scale.
What this replaces, and what it doesn't
That validation step matters because this method has real limits. It's a way to get a defensible first structure in place quickly, using data a founder-led sales motion already generates. It is not a substitute for rate-setting once there's real volume, for formal willingness-to-pay research once the company can afford to run it, or for revisiting the whole structure once a company moves off founder-led selling entirely. There is no fixed number of tiers this method produces automatically. Different businesses will find the pattern breaks in two places or four; the method is about finding where the reader's own deals broke, not about landing on a specific count someone else recommends.
What it does replace is the instinct to treat pricing-tier design as a blocked project waiting on research nobody has time to run. The founders who wait for that research tend to keep quoting ad hoc numbers for another two quarters, which is its own form of mispricing, just spread out instead of concentrated in a bad pricing page.
The tiers were never the separate project
A pricing page is usually treated as its own workstream, handed off once the "real" GTM work is done. The deal-history audit treats it as a natural output of a sales system already in motion: buying-committee mapping, discovery structure and procurement visibility are not just what make a founder-led sales motion repeatable, they are what make a pricing structure defensible. Founders who have already built that discipline are closer to a real pricing page than they think. The work is not collecting new data. It's reading the data differently.
If your pricing page still looks like three competitors' sites stitched together, the fastest fix isn't a pricing study. It's an afternoon with your last twenty deals and the three questions above. Once the tiers themselves are set, how you sequence that number inside a live deal is a separate problem worth solving next. If the audit surfaces a structure you're not confident defending to your board, that's usually a sign the underlying GTM system, not just the pricing page, needs a closer look.
Want a second opinion on your pricing structure?
RivoAxis works with early-stage and growth-stage founders on the GTM systems behind decisions like this one.
Talk to RivoAxis