The Best Product Validation I Ever Got Was a $6.5 Million Quote

The quote was $6.5 million, and it was for teaching people how to use Jira.

In 2016 I was at Adaptavist, leading a pilot for a consulting client: 20,000 Jira and Confluence users to start, scaling to 140,000 across the organization. This wasn't a quick tour of where the login button lives. It was real, task-level training, so people could create issues, manage boards and run reports without flooding the help desk with basic questions. At the time, the only training Atlassian offered was seated classroom instruction, capped at 12 people per session even when it ran virtually, and Atlassian's quote covered only the pilot group.

The licenses were $3 million.

So the training would cost more than twice the software it was teaching people to use. And the detail that makes this worth telling is that the client could pay it. This was a multi-billion-dollar company, and budget wasn't really the issue. The sticking point was proportion. Very few organizations will look at a training bill that's double the license cost and sign it, however deep their pockets go.

I proposed something Atlassian didn't offer at all: e-learning, delivered inside Jira through a plug-in, so people learned the tool in the tool instead of getting pulled out of their work and into a room. That proposal became Learn for Jira. For a while I was the entire product team – product management, content, QA, releases, customer support – and I had to learn to read a little code just to do the QA. I've written about what happened to the product six years later, and it isn't a happy ending. But the start was as clean a validation signal as I've ever seen.

A refused quote validated the product before it existed

Most product validation I see measures interest. Someone runs a survey or a round of customer interviews, maybe puts up a landing page, and comes back with a count of people who said yes.

What I had was a different kind of evidence. Nobody had to tell me they'd love an in-app training product. A buyer with the means to pay had been quoted a real price for the problem, looked at it, and decided the math was wrong. That's behavior, and it already had a dollar figure attached, which is more than any opinion about a hypothetical product can offer.

Run the numbers and the gap gets almost comical. At 12 people per session, the pilot group alone works out to roughly 1,700 classroom sessions. If one trainer ran one session every working day, the pilot alone would take more than six years, and the plan was to go to 140,000. Nobody doubted that people needed training. The only available way to deliver it didn't scale, and everyone involved could see that.

So the market had already priced the problem, and the buyer had already refused the price. All that was left was to build the thing that sat in the gap between them.

Why "people said they'd use it" isn't validation

A refused quote beats an enthusiastic interview because what people say they'll pay and what they actually pay are reliably different numbers.

Economists have measured this for decades under the name hypothetical bias. A 2005 meta-analysis of 28 willingness-to-pay studies found the ratio of hypothetical to actual value had a median of 1.35, with a mean of 2.60 dragged upward by some wild outliers. A 2019 meta-analysis in the Journal of the Academy of Marketing Science, covering 77 studies of consumer goods, found that people overstated their willingness to pay by about 21% on average, and by more for higher-value and specialty products. You'll often hear that customers overstate by two or three times. The typical gap is smaller than that and the outliers are far worse, which is its own problem, because nothing in the interview tells you which kind of person you're talking to.

Sometimes people love a product and still won't pay for it at all. The AI coding tool Kite grew to 500,000 monthly-active developers, and its founder's farewell post says plainly that those developers "would not pay to use it." The engineering managers who held the budgets weren't moved by making their developers 18% faster, either. Half a million users is an enormous amount of appeal, and it turned out to say nothing about whether anyone would pay.

The same pattern shows up in post-mortems. In CB Insights' 2026 analysis of 431 startup shutdowns, running out of capital was cited in 70% of failures, and the analysts called it "almost always the final cause of death, not the root problem." Poor product-market fit was cited in 43%. Those are founders' own explanations, and most failures had more than one, so I read them as a pattern rather than a precise cause of death. It's still a lot of companies that found out after the build that nobody was going to pay.

Validate the price of the problem, not the appeal of the idea

If I were starting a direction bet today, this is the shift I'd make first. Stop asking whether people like the idea, and start asking what the problem already costs them.

A compliment is the purest cheap yes there is. It costs the person giving it nothing, it feels great to receive, and it tells you almost nothing about what they'll do when an invoice shows up. A cheap yes leads to an expensive no, and that no usually arrives after you've built the thing. A refused price runs the other way. It's an expensive no that somebody else already paid to discover, and it's sitting there waiting for you to notice it.

This matters most for teams that are good at building. A strong product and engineering team can make almost anything appealing, because appeal is what good builders produce. That's exactly why appeal is a weak signal when you're deciding what to build: a good team can generate it whether or not the problem underneath is worth solving.

Where to find a problem's price

Most problems don't arrive with a seven-figure quote stapled to them. The price is usually there anyway, and it tends to hide in a few predictable places.

Start with what people already spend. Rob Fitzpatrick makes this point about customer conversations in The Mom Test: ask how they solve the problem today and what that costs them, because someone who hasn't already tried to solve it probably isn't going to pay you to. Existing spend, even clumsy spend, is the market telling you the problem is real.

Then look for the quotes people turned down. This is the one I had, and I think it's underused. Ops leaders, finance people and procurement teams can usually tell you about the vendor proposal they rejected and why. A refusal over proportion, like the one in front of me in 2016, is a gift. A refusal because the problem didn't matter enough is useful too, just in the opposite direction.

Look at the workarounds. When the official answer costs too much, people build their own, and the ugliness of the workaround tells you how much the problem hurts. In the Jira world, the cost of untrained users showed up as bad data, abandoned boards and teams quietly drifting back to spreadsheets because they never learned the system they were supposed to adopt. The spreadsheet was the workaround, and every one of them was a small vote that the problem was real.

And look for commitments rather than compliments. Fitzpatrick's test is whether someone gives up something they value to move forward – their time, their reputation or their money. A pilot with a real budget line, an introduction to their boss, a request for a proposal: each of those costs the person something. "Let me know when it launches" costs them nothing.

What this means for your next direction bet

If you're weighing a new direction right now – a new audience, a new product line, a market your team hasn't served before – the question I'd put at the top of the list is what this problem already costs someone, and whether they've refused to keep paying it. Whether people want the product comes second.

If you can answer that with a number, you're in a strong position and the build is mostly an execution question. If you can't, find out before you build, because finding out is cheap and the build isn't. And if the honest answer turns out to be that nobody is paying anything for this problem today, that's the most valuable answer market validation can give, even when it isn't the one you wanted.

The case for Learn for Jira was already on the table, in a quote that a buyer who could afford it didn't want to sign. My job was to notice what that refusal was telling us.