SaaS strategy

Scaling B2B SaaS is a product problem before it is a marketing one

The playbook that got a SaaS company to $15M stops working somewhere past $30M. The break is usually between what was promised and what the product delivers.

An operations analyst seen from behind working a dense data table on a wide monitor

Photographs on this page are AI-generated.

The playbook that stops working

Scaling B2B SaaS has a well-known awkward middle. The marketing playbook that carries a company to $15M in revenue can become the constraint somewhere around $50M, and pushing harder on it buys less each quarter.

That is the opening argument of a recent SaaS growth podcast episode with a B2B marketing leader who has run marketing through hyper-growth and a public listing. The episode's answer is an audit: find what still creates growth, what has become habit, and what the team should stop doing.

It is a marketing conversation, and a good one. This post reads it from the other side of the sale, because the audit it calls for runs straight through the product.

Buyers and users want different proof

In a SaaS company's early deals, the person who buys the product and the person who uses it are often the same founder or team lead. As deals get larger, they tend to split. Nielsen Norman Group's research on B2B websites describes purchases made by groups, with the people who choose a product and the people who use it needing different information at different times.

That split is where a growth engine leaks. Marketing and sales make the promise to the chooser. The product has to keep it for users who were not in the room. On a cloud security product I designed for, the analysts working the alert queue were losing 40 percent of their day to false-positive alerts, a cost that shows up in the work, not in a purchasing conversation.

SaaStr's panel on what changes at $50M ARR makes a related point from the operator side: pricing has to follow the value customers can see, and leaders lose sight of what is happening on the ground as the company grows. Both are product questions as much as commercial ones.

The promise-to-value chain

A useful way to audit this is to follow one customer outcome through six links, and ask at each one whether the promise survived.

Six links from promise to value: promise, evaluation, setup, first value, repeated use and team adoption, with first value highlighted as the link most often assumed rather than measured

The promise is what the customer was told. Evaluation is the proof they needed to say yes. Setup is everything that must happen before the product can do anything: data, permissions, integrations, invitations. First value is the first time the product does the job it was bought for. Repeated use is that job done again without help. Team adoption is the job spreading to the people the account was bought for.

Funnels count signups and conversions at the front of this chain. The links that decide renewal sit at the back, and they are the ones least likely to belong to a single team.

Diagnose the break before choosing the fix

The same symptom can come from different links, and the fix depends on which one. Weak trial conversion might mean the wrong customers are arriving, the promise is vague, or setup asks for data the trial user does not have. An onboarding tour fixes only the last of those, and only sometimes.

Three symptoms are worth separating early. Signups that never reach a first result point at setup or at fit. Strong demos followed by weak usage point at a promise the product cannot keep for the people who use it. An administrator who finishes setup while the rest of the team never logs in points at the handoff between roles, which is where onboarding that ends at the setup screen loses most accounts.

Each needs a different investigation: watching a real setup, comparing the sales narrative with a user's actual task, or following one invitation from the administrator to the person who receives it.

Define first value as a customer outcome

Most activation metrics measure the product's progress, not the customer's. "Workspace created" and "integration connected" are setup steps. First value is the moment a customer gets the result they bought, such as a report they would otherwise build by hand or an alert they can act on.

Google's HEART framework, published at CHI 2010 by Kerry Rodden, Hilary Hutchinson and Xin Fu, is still the clearest method for this. HEART starts from a goal, picks the signals that show progress toward it, and only then chooses metrics. Applied to activation, the goal is the customer's outcome, and an event earns the name only if accounts that reach it keep using the product.

If the event needs a second role, such as an admin granting access, it belongs to two people, and the design has to cover both.

Give sales and executive requests a decision path

Growth brings requests. A large prospect wants one feature, an executive returns from a conference with an idea, and each lands on the roadmap as an interruption. The same podcast episode has a chapter on turning random executive ideas into a system, and the product version of that system is a short intake record.

Record where the request came from, the customer problem underneath it, which segment and role it affects, what evidence exists, whether anything was promised, and who decides. A request is evidence to interpret, not an order to implement or dismiss. An urgent contractual commitment still needs a fast path, written down, so it stops arriving as a surprise.

Measure what design can honestly claim

SaaS Capital's 2026 survey of more than 1,000 private B2B SaaS companies found growth tracks net revenue retention: moving retention from the 90 to 100 percent band to the 100 to 110 percent band went with about five more points of growth. That is an association across companies, not proof that any one interface change moves revenue.

So keep the claims in layers. Design can own task success and time to first value. It shares adoption with customer success. Retention and expansion belong to the whole company. A redesign that improves the first two layers is a good redesign even when the third moves for other reasons.

Run it on one journey

  1. Pick one customer outcome the product is sold on.
  2. Write the promise exactly as sales and the website make it.
  3. Watch two or three new accounts go through setup and first use.
  4. Mark the first link where the promise and the experience part ways.
  5. Name an owner for that link before anyone designs a screen.

A UX audit that ranks problems is the structured version of this, but one journey traced honestly is enough to start.

The point

A company that stops growing past $30M rarely lacks ideas. It lacks a shared view of where its promise stops being true. Marketing sees the front of the chain, the product team sees the middle, and nobody sees the account that bought and never adopted. Find that break first. More acquisition only sends more people to it.

Frequently asked questions

How do you scale a SaaS company from $30M to $100M?
Scaling a SaaS company from $30M to $100M usually requires changing the playbook that produced the first $30M rather than running it harder. Audit which acquisition channels still create growth, separate buyer needs from user needs, and check that customers reach real value after the sale. Retention and expansion matter more at this stage, so product adoption becomes a growth lever, not only a support concern.
What is a good activation metric for B2B SaaS?
A good B2B SaaS activation metric marks the first time a customer gets the outcome they bought, not a setup step such as creating a workspace. Choose a candidate event, then check that accounts reaching it keep using the product more often than accounts that do not. If the event depends on two roles, such as an administrator and a daily user, measure both.
Should a SaaS company fix activation or acquisition first?
A SaaS company should usually investigate activation before increasing acquisition spend, because more traffic sends more people into the same break. Keep enough acquisition running to learn from real accounts, since very low volume makes behaviour hard to read. Watch a few new accounts through setup and first use, find where they stall, and fix that link before scaling the top of the funnel.
How should product teams handle feature requests from sales?
Product teams should treat feature requests from sales as evidence about a customer problem, not as specifications. Record who asked, the underlying problem, the segment and role affected, any commitment already made and who decides. Requests that share a problem become one roadmap item. Urgent contractual commitments need a written fast path so they stop interrupting planned work without review.
How does product design contribute to SaaS growth?
Product design contributes to SaaS growth by finding where the experience after the sale fails to deliver what marketing and sales promised. Designers trace setup, first value and team adoption, test those steps with real users, and fix the workflows that block them. Design can claim task success and time to value; retention and revenue depend on the whole company.

Sources

This thinking, applied

an audit that traces one journey from promise to value

Share this

Keep reading

All posts