Where it started

If you build B2B SaaS long enough, this moment becomes familiar. Sales closes a hard-won deal, the customer starts onboarding, genuinely intending to use the product. Then, not long after, they say:

"We don't think we're ready to use this yet."

Our product was a B2B SaaS with an enterprise ICP, and this line kept showing up as the reason customers dropped out of onboarding. Once or twice, you'd chalk it up to an individual customer's circumstances. But it was showing up often enough to call it a pattern.

A proposal to solve this problem landed on my desk. It came with wireframes, and a note that it was already "aligned with customers."

The solution I was handed

The logic behind the proposal was straightforward: customers felt unready because they didn't yet have a project worth putting into our product. So the plan was to extend our product's scope upstream, into the stage before real usage, to help customers surface and prioritise project ideas.

The design added a whole new capability: collect project ideas, build a mapping/prioritisation feature around them, and connect the output into a real project inside our core product. Directionally, it made sense. The problem was scope. This wasn't a feature; it was effectively a second product. It called for a PM, a product designer, an engineering lead, and five software engineers, for six months or more.

The question I stopped to ask

I had no objection to the plan on its face. But before committing that much scope, one thing kept nagging at me.

Was "we're not ready yet" really one situation, or several different ones, flattened into a single phrase?

The proposal had already arrived with the premise that one solution was aligned with customers. I wanted to test that premise itself before building on top of it. So I broke down the possible reasons behind "not ready yet" into three hypotheses:

1. No project to manage, yet: at the point of onboarding, the customer simply doesn't have a project to put into the product

2. A project exists, but it doesn't fit our product's structure: the customer has a project, but its shape doesn't match the structure our product requires

3. A project exists and is structurally compatible, but there's no good way to bring it in: the content and structure line up, but there's no viable import path

The three hypotheses look similar on the surface, but they call for entirely different solutions. If it's #1, "help customers discover project ideas" is the right answer. But if it's #2 or #3, an entirely different kind of solution is needed.

Checking it against data

Once the hypotheses were set, I went to the people closest to customers, Sales and CS, to ask which of the three actually matched what they were seeing. I wanted to know, among customers who dropped out during onboarding, which reason came up most.

The result didn't match the premise the original proposal was built on. By a wide margin, the dominant reason wasn't #1 (no project to manage); it was #2: "there's a project, but it doesn't fit our product's structure."

In other words, customers weren't stalling because they lacked a project to put into the product. They already had projects, run their own way, and were dropping out at the moment they realised how much re-structuring it would take to fit our format.

Had we gone ahead with the original plan, we would have spent six months building a solution for a problem (#1) that, in practice, was barely happening.

The solution I proposed instead

I brought this data back to the stakeholders. It didn't land at first. I framed it as "I tested the hypotheses and got a different picture," but momentum doesn't shift that easily. So I changed approach. I invited Sales and CS directly into the room and let stakeholders hear the actual customer cases from the people who'd lived them. The specific stories from people who'd talked to customers carried far more weight than the data I'd summarised.

That's how I ended up proposing a much smaller alternative.

The core idea was simple: let customers bring in their existing projects as-is, as a raw data source, before asking them to restructure anything to fit our product. Instead of treating structural compatibility as a prerequisite for onboarding, flip the order: let customers onboard first, and clean up the structure gradually, afterward.

• Not a new feature to help customers discover project ideas,

• but an intake path that lets an existing project in, structure-agnostic, from day one.

With this, customers no longer had to answer "does our project fit this product's structure?" before they could even start. Structuring becomes a later problem, not a gate.

The outcome

The original six-month proposal pivoted into a smaller, validated solution. The team that would have been assigned to it, a PM, a product designer, an engineering lead, and five software engineers, eight people in total, was freed up to work on other priorities instead. A rough estimate, based on industry-average loaded salary costs, puts six months of that team's time at roughly A$700K or more in Australian dollars. But the number matters less than what it represents: eight people's worth of engineering capacity that could have gone toward an unvalidated problem, redirected toward a validated one instead.

The solution I'd proposed was eventually built and shipped, and onboarding drop-off went down.

What stayed with me

"We're not ready yet" was one sentence from the customer, but behind it were three distinct situations. Even a solution that looks like it's already aligned with customers is worth checking again: aligned with which question, exactly.

What this experience reinforced, ultimately, comes down to one thing: the larger the scope of a proposal, the more worthwhile it is to validate the problem definition before building. Framing hypotheses and asking the people closest to the data, in this case Sales and CS, took two days. Those two days changed the direction of a six-month project.

The question that stayed with me since is this: is the "already-decided solution" in front of me actually solving a validated problem, or just the loudest voice in the room?