Best Practices
Every early-stage SaaS company I've worked with had a growth team. Most had a sales team. Almost none treated design as a revenue function. That's a problem, because the difference between a deal closed and a deal lost, between a user retained and a user churned, is often just how intuitive the product felt in the first five minutes.
The Quiet Revenue Leak Most SaaS Companies Ignore
Every SaaS company I've worked with has a growth team. Most have a sales team. Almost none have treated design as a revenue function.
That's a problem, because in my experience, design decisions directly affect whether users stay, whether prospects convert, and whether enterprise deals close. Not indirectly. Directly. I've seen it play out too many times to call it a coincidence.
You're spending money to acquire users you're losing at the door
The default move when growth slows is to spend more on acquisition. More ads, more SDRs, more top-of-funnel. It makes sense on paper. More users in means more revenue out.
Except that math only works if users actually stay.
Most SaaS products lose a significant chunk of new users before those users ever experience the value the product was built to deliver. They sign up, poke around, don't immediately understand what to do, and quietly leave. No complaint ticket. No cancellation survey response. They just stop logging in.
Companies see this in their data and call it normal churn. It isn't. It's users telling you the product didn't make its case fast enough. And pouring more acquisition budget on top of a leaky retention problem is one of the more expensive mistakes an early-stage company can make.
EXAMPLE
At Docsumo, the percentage of new users who had any real chance of hitting their aha moment was sitting at 15%. Not 15% conversion to paid. 15% of users even getting far enough to understand what the product did. We rebuilt the onboarding flow around the moment users first saw value, not around the steps the product team thought were logical. Retention went from 15% to over 95%.
That's not a design win. That's a revenue win that happened to come from design.
The POC stage is where enterprise deals quietly die
For SMB products, onboarding is the moment of truth. For enterprise, it's the proof of concept.
A prospect's team gets access to the product. They spend a few days, sometimes a few weeks, trying to evaluate whether it solves their problem. And if the product isn't immediately intuitive, if it doesn't communicate its own value clearly, if the user has to work too hard to understand what's happening, the evaluation fails.
Not because the product doesn't work. Because it doesn't convince.
Enterprise buyers are evaluating multiple options simultaneously. They're busy. They're skeptical. They're not going to read documentation to figure out why your product is worth buying. The product has to make that case itself, through the experience of using it.
EXAMPLE
I designed a reporting tool for GatherGov that was being evaluated against a competitor by an enterprise client with a deal size of around $1M. The competitor had been building their product for over a year longer than we had. We won the deal. Not because of features. Not because of pricing. The client said our product was easier to use.
That's what good UX does in an enterprise sales context. It closes deals that would otherwise be lost to a competitor who happened to build something clearer.
Most new features get built for the wrong reason
Here's a pattern I've seen at nearly every early-stage startup: a key customer asks for a feature. The sales team escalates it. The feature gets built. It ships, the customer is happy, and then almost nobody else uses it.
This happens because the discovery process started with a request instead of a problem. One customer described their specific workflow and the team built exactly that. It solved that customer's problem and nobody else's, because nobody else had exactly that workflow.
Good problem discovery goes deeper than the request. It asks why the customer needs this, what they're actually trying to accomplish, what would happen if they couldn't do it. When you design from that level of understanding, the feature you build tends to solve a problem that a much larger group of users has, even if they never articulated it the same way.
The difference between a feature with 3% adoption and one with 40% adoption is usually not engineering quality. It's how well the problem was understood before a single screen was designed.
EXAMPLE
There was a Series A YC company that had a bloated product because they build "exactly" what the customers ask for. The product was designed by someone that joined as an intern and stayed with the company for 3 years with no experience otherwise.
She said the process they followed was:
Sales comes in with a requirement to close a deal -> Design prioritizes and ships the design in 2 days -> Devs ship it to the product in 2 more days -> Sales closes the deal
No thorough problem discovery. She thought she was doing a good job because she shipped what their customers ask for. I almost lost the contract for pointing this out, but lucklily I went in with proof - their user feedbacks about the product being bloated from public sources like G2.
After Series A, this became a real problem with churn going out of hand as they added more features to the product. They spent 6 months and probably around $500k worth of resources to ship a 2.0 version that was simpler and easier to use.
The prototype that closes deals before the product ships
One of the most underused tools in an early-stage company's sales process is a high-fidelity clickthrough prototype.
Not a demo of the existing product. A designed prototype of what the product could do for a specific prospect, built quickly, shown in a sales conversation to demonstrate that you understand their problem and can solve it.
This works for a few reasons. It gets detailed, specific feedback much earlier than waiting for a shipped feature. It signals to the prospect that you move fast and think about their experience. And it gives the sales conversation something concrete to anchor to instead of promises about what's coming.
The cost of building a good prototype is low relative to the cost of losing a deal because you couldn't show the customer what you meant. And the feedback you get from a prospect reacting to something tangible is worth more than ten discovery calls.
More enterprise deals are won and lost at the prototype stage than most founders realize. Design's role in the sales process isn't just making the product look good after it ships. It's giving the sales team something to show before it does.
Good UX doesn't expire
The thing about revenue generated through design is that it compounds. An onboarding flow that retains users keeps retaining them. A product that wins enterprise deals because it's clearer than the competition keeps winning them. A feature built from real problem discovery keeps getting used.
You don't have to keep paying for it the way you pay for ads or headcount. Good UX, built on real understanding of the user, keeps working.
Most early-stage companies treat design as a cost. The ones I've worked with that treated it as a revenue function grew faster, churned less, and closed larger deals. The correlation isn't subtle.
If this sounds familiar
If any of these problems are ones you're currently sitting with, I'm open to new work.
I've helped close a $2.3M in enterprise deals purely through UX.
Taken onboarding retention from 15% to 95%+.
Generated $400K in PLG pipeline in a single month post-launch.
All at early-stage startups where there was no room for slow or expensive mistakes.
If you want to talk or consult about what's happening in your product, book a call.
