Knowing how to sell before product is ready is one of the hardest things a founder has to learn — and almost nobody teaches it. At Data Solver, there was a moment that stopped us in our tracks. A prospective customer — exactly the kind of anchor customer we needed — leaned forward and asked whether our platform could automatically correct privacy gaps, not just identify them.
We couldn’t. We hadn’t built correction. We hadn’t even finished mapping all the sources of private data. But the person across the table was interested, engaged, and asking with what felt like urgency.
What do you say?
Knowing how to sell before your product is ready means resisting the instinct to answer the question being asked. The more useful question is whether the request in front of you reflects a problem the whole market has, or a problem this specific customer has. Those are very different conversations — and they lead to very different decisions about what to build next.
Table of Contents
Why Selling Before Product Is Ready Is Harder Than It Looks
The problem isn’t finding willing customers
The difficulty in early-stage selling isn’t finding people willing to talk. Most founders discover that prospective customers are surprisingly open to conversations — especially when a product solves a problem they recognise.
The difficulty is knowing what to do with what those conversations surface. Learning how to sell before your product is ready is, in practice, learning how to manage yourself in those conversations — not just the customer.
At Data Solver, we had over 40 customers and a product solving a genuine compliance problem. But the conversations we had while still building — before everything worked the way we intended — generated requests we hadn’t anticipated. Some shaped the roadmap well. Some nearly destroyed it.
The instinct that gets founders into trouble
The challenge isn’t the customer. It’s the founder’s instinct in the room.
When someone is interested and asking for something, the pull towards yes is almost physical. You can feel the deal within reach. You start mentally building the thing they’ve described before they’ve finished the sentence.
That instinct — however understandable — is the thing to watch. If you’re still figuring out how to build sales pipeline for your startup, the discipline of managing that instinct in real conversations is what separates founders who grow cleanly from those who end up committed to building things they shouldn’t. Paul Graham’s essay on doing things that don’t scale makes a related point: the scrappy, manual work of early founder-led sales is precisely what can’t be delegated or systematised yet.
What a Customer Request Actually Tells You
Genuine doesn’t mean representative
When a customer asks for something you haven’t built, they are almost always being genuine. They’re not trying to send you in the wrong direction. They have a problem, and what you’ve shown them has made them think you might solve it — or a version of it.
But genuine doesn’t mean representative.
The question worth asking — and this took us time to learn — is whether the problem they’re describing is one the wider market has, or one their specific organisation has.
A problem that one company has is a consulting project. A problem that a segment of the market has is a product.
The SaaS trap: building for one customer
At Data Solver, we were building a SaaS platform. That meant we needed solutions to common problems, not bespoke fixes for individual customers. When a prospect asked for automatic correction of privacy gaps, we had to ask ourselves: is this something every organisation with compliance obligations needs, or is this something this particular customer needs because of how their own data architecture works?
After investigation, the honest answer was closer to the second. Delivering automatic correction varied enormously by data environment. It wasn’t a feature we could build once and deploy across customers. It was a different product — and a significantly more complex one.
That investigation cost us in the short term. Some customers didn’t wait. But the alternative — cannibalising the roadmap for one customer’s requirements while leaving the rest underserved — is how SaaS companies become project-based consultancies without realising it.
This is one of the tensions that sits underneath product vision vs product strategy: the vision tells you where you’re going, but the strategy has to hold the line on what you’re willing to build to get there.
How to Read Genuine Demand When Selling Before Product Is Ready
Why the room is misleading
There’s a version of customer interest that sounds like demand but isn’t. A customer is engaged, asks thoughtful questions, raises a feature request at the end — and you leave the meeting convinced you’re close to a deal. Then the follow-up goes quiet.
This is one of the harder things to calibrate in early-stage sales. A few things helped us distinguish real demand from polite interest.
Three signals worth watching
Ask who else in their organisation cares about this
A request from someone with buying authority looks different from a request from someone who would need four other people to agree. Not every person you speak to can make a purchasing decision. Understanding that early — rather than late — saves significant time and avoids the painful experience of building a relationship with the wrong person in the room.
Watch what happens when you push back
When we said “we don’t have that yet — would that change your decision to move forward?”, the response told us a great deal. Customers with genuine demand tended to stay in the conversation and start problem-solving with us. Customers for whom it was a nice-to-have tended to use the pushback as an exit.
Use the commitment test
Before we agreed to explore building anything at a customer’s request, we started asking for something in return — a memorandum of understanding, a letter of intent, or at minimum a verbal agreement on terms. Not because we needed the paperwork, but because it separated customers who meant it from customers who were curious. If someone wasn’t willing to put anything on paper, the request probably wasn’t the thing that would close the deal. Understanding how to prepare for investor meetings uses a similar logic — the signal you’re looking for is commitment, not enthusiasm.
Why Saying Yes to Everything Makes the Problem Worse
The pattern we kept repeating
We made the mistake of saying yes. More than once.
The pattern was usually the same. A customer asked for something that felt adjacent to what we were already building. We said we could explore it. Engineering time went into the investigation. And at some point we realised either the complexity was far beyond what we’d assumed, or delivering it would pull the roadmap significantly off course.
The double cost of a retracted yes
In one case, we went back to the customer honestly and told them we couldn’t deliver what we’d discussed. The conversation was difficult — not because they were angry, but because we had raised their expectations and then retracted them. That erosion of trust was harder to recover from than a clean no at the first meeting would have been.
The internal cost was equally real. Every time you explore something at a customer’s request, the team begins building a mental model of the product that includes it. When you later decide not to build it, you’re not just saying no to the customer — you’re resetting expectations internally. That friction accumulates.
None of this means saying no to everything. It means the threshold for saying yes should be higher than a single customer’s enthusiasm, and the decision should connect back to a clear product vision rather than the energy in the room.
What to Say When You’re Selling Before Product Can Do What They Want
Revert to the problem, not the feature
The framing that worked best was going back to the problem underneath the request.
Rather than asking “can we build what you’ve described?”, we’d ask: “What’s happening now that makes this feel important?” That question usually surfaced two things: the actual problem — which was often something we could partly address with what already existed — and sometimes the realisation that the feature they’d asked for wouldn’t solve the underlying problem anyway.
This isn’t a deflection tactic. It’s a genuine way of finding out whether there’s something real to work on together. A customer’s feature request is how they express a problem using the vocabulary of what they’ve already seen. The underlying problem is often different — and more useful — than the surface request.
How to frame “not yet” honestly
From there, if the honest answer was still “not yet”, the message that worked was something like:
“We’re tracking this alongside what we’re hearing from other customers. If the same need keeps appearing, it becomes a priority. We’ll come back to you.”
That’s not a stall. It’s an honest description of how product decisions should work. A single customer’s request, however compelling, isn’t sufficient to change direction. A pattern of the same request from multiple customers is. Getting stakeholder alignment on product direction — including alignment with customers about what’s feasible and when — follows the same principle.
Where prototypes help
Clickable prototypes were useful here — particularly for complex AI features where explaining the concept verbally wasn’t enough. A linked wireframe isn’t functional, but it lets a customer react to how the product will feel rather than imagining it from a description. That tangible reaction often surfaced concerns earlier than a conversation alone would have, which is better for everyone. A well-constructed product brief can serve a similar function — giving the customer something concrete to respond to without committing to build anything yet.
The Commitment Trap: What Founders Learn Too Late About Selling Before Product Is Ready
Customers buy what exists, not what you’ll build
The most important shift in how I think about selling before product is ready is this: a customer is ready to buy what you have today, not what you’re going to build tomorrow.
It sounds obvious in retrospect. But in the room, it doesn’t feel that way. The relationship is built. They’ve told you what they need. The gap between what you have and what they’ve described feels bridgeable — a few more months, a couple of additional features.
What happens in practice is that the gap doesn’t close the way you expect.
Why the goalpost keeps moving
You build what the customer described. You go back. And now there’s something else.
Not because the customer has changed their mind arbitrarily — but because they’re seeing your product through the lens of what it is now, and that creates new ideas about what it could be next. Their frame of reference shifts every time you show them something new. What looks like an unmoving requirement in one conversation looks different after they’ve seen a working prototype, and different again after they’ve used it in their own environment.
This is the cycle that locks startups into building for one customer rather than for a market. The anchor customer defines the roadmap. The roadmap solves their specific problems. The product that emerges is designed for someone else — and the wider market can tell.
How to hold the line
The way out isn’t to ignore what customers tell you. It’s to come back, every time, to the core value proposition: are we still solving the problem we set out to solve? If yes, that’s what to sell. Y Combinator’s enterprise sales guide for founders captures this well — the goal of early sales conversations isn’t to close every deal, it’s to find whether the problem you solve is real enough that the right customer will commit to it today.
Everything else is a conversation about what phase two might look like — and that conversation should only happen when more than one customer is asking for the same thing.
Getting this right is partly about how well-aligned the founding team is on what they will and won’t build. If one co-founder is committing to features in sales conversations that the other hasn’t agreed to, the misalignment shows up with customers eventually. Establishing co-founder alignment on product direction — including what you’ll say yes to in the room — is a prerequisite for consistent, honest pipeline conversations. And if you’re communicating this direction to investors at the same time, being clear on how to get investor buy-in for your product vision means showing them a product direction that your sales conversations are actually reinforcing — not one that’s drifting under pressure from individual customers.
Frequently Asked Questions
What does it mean to sell before product is ready?
It means having genuine sales conversations with prospective customers before product can do everything they might want. The goal is to validate demand, build relationships, and shape the roadmap around real market signals — not to make promises about functionality that doesn’t exist yet. Knowing how to sell before product is ready is largely about managing your own instincts in the room, not just the customer’s expectations.
How do you avoid overpromising in early-stage sales conversations?
Go back to the problem underneath the request. Instead of asking whether you can build what the customer described, ask what’s happening now that makes it feel important. That reframes the conversation around what exists today and whether it addresses the actual issue — which is often different from the surface request.
What is the difference between a customer request and market demand?
A customer request is what one buyer wants, shaped by their specific situation and what they’ve just seen. Market demand is the same underlying problem appearing consistently across multiple customers in your target segment. As a startup building a scalable product, you’re building for the second — and early conversations are partly how you tell the difference.
When should a startup say no to a customer request?
When delivering it would require building something only that customer needs, or when the investigation required would disrupt the existing roadmap without a clear return. A single customer’s enthusiasm isn’t enough to change direction. A commitment signal — an MOU, a letter of intent, or at minimum clarity on who the actual decision-maker is — is a more reliable indicator of genuine demand.
How do you handle the “is it ready yet” question?
With honesty, and with a clear explanation of what does exist and what it can do today. Raising expectations you can’t meet creates a trust deficit that’s harder to recover from than a straightforward “not yet.” Where possible, use something tangible — a clickable prototype, a detailed brief — to give the customer something to react to in the meantime.
How do you know if a prospective customer will actually buy?
Test commitment early. Before agreeing to explore anything at their request, ask for something in return — a written agreement, a confirmation of terms, or at minimum an answer to who in their organisation would make the final decision. Customers with genuine intent stay engaged when asked for something concrete. Customers for whom it was polite interest tend to exit.