Build Sales Pipeline for Your Startup Before the Product Is Ready

Every founder I know has sat through a version of the same conversation. A potential customer is interested. They can see the problem you solve. They lean forward and ask for something you haven’t built yet — and you have about three seconds to decide what to say. If you want to build sales pipeline for your startup, this is the moment that defines how you do it.

At Data Solver, the privacy compliance platform I co-founded, this happened repeatedly. We had built a tool that could identify where privacy gaps existed in an organisation’s data. Customers could see the gaps. What they wanted to know was: can you fix them automatically?

We hadn’t built correction. We hadn’t even fully mapped the sources of private information. The temptation to say “yes, that’s on the roadmap” was enormous — because the person asking was exactly the kind of anchor customer we needed to survive.

To build sales pipeline for a startup before the product is ready, founders must sell the problem they solve, not the features they’ve shipped. It requires honest conversations about what exists today, commitment signals from customers before you build, and the discipline to say no to requests that would pull you away from your core vision.

Why should a startup build sales pipeline before the product is finished?

The instinct is to wait. Finish the product, polish it, then go to market. The problem is that while you’re building in isolation, you’re burning cash, getting no market feedback, and creating a gap between what you think customers want and what they’ll actually pay for.

At Data Solver, we couldn’t afford to wait. Runway was finite. But more importantly, the conversations we had while selling — even before the product could do what customers wanted — shaped what we actually built. The pipeline wasn’t just a revenue channel. It was a feedback loop.

The same was true when I co-founded Royal Mysore Walks, a heritage tourism venture in India. We didn’t have a polished multi-route experience. We didn’t have a brand anyone recognised. What we had was a product idea and the willingness to start talking to people who could help us reach an audience. We contacted journalists, offered free tours to the press, approached heritage organisations like the Confederation of Indian Industries for collaboration opportunities, and positioned ourselves at government tourism press conferences — not as headliners, but as a complementary offering to what those larger bodies were already doing.

We were building the pipeline by borrowing credibility we hadn’t earned yet. And it worked — not because we were clever, but because we started before we felt ready. Paul Graham’s advice to do things that don’t scale captures this well — the manual, unglamorous work of showing up, making introductions, and running free tours for journalists was exactly the kind of thing that would never work at scale, but it was the only way to get started.

If you’re approaching investors at the same time as building pipeline, the two conversations reinforce each other. Your investor buy-in pitch improves when you can show real customer interest, and your investor meeting preparation becomes sharper when you have pipeline data to reference rather than just a slide deck and a promise.

What happens when you say yes to everything a customer asks for?

At Data Solver, we tried both approaches. Sometimes we said yes to things we weren’t ready to deliver. Sometimes we said no.

When we said yes — when we agreed to explore data correction before we’d properly solved identification — we lost trust. Customers could tell we didn’t fully understand the complexity of what we’d committed to. The gap between what we’d promised and what we could actually show them in the next meeting was too wide. It wasn’t that they were angry. It was worse than that. They stopped taking us seriously.

When we said no, we sometimes lost the deal entirely. The customer heard “no” and treated it as a reason to walk away, rather than understanding it as honesty about where we were in the journey.

Neither outcome was good. But over time, the pattern that worked best was a third option: don’t say yes or no. Ask for commitment first.

“This is something we could build. Before we invest in it, can we agree on terms that would make this worthwhile for both of us?”

At Data Solver, that commitment was usually a memorandum of understanding or a verbal acceptance — we didn’t have the leverage for anything more formal. But even that lightweight signal was enough to separate genuine demand from polite interest. If a customer wasn’t willing to put anything on paper, the request probably wasn’t the thing that would close the deal. It was a nice-to-have dressed up as a requirement.

This is where the distinction between product vision and product strategy matters most. The vision tells you what you’re building towards. The strategy tells you what you’re willing to do — and not do — to get there. When a customer asks for something that conflicts with both, the answer has to be no, however you frame it. When it conflicts with the strategy but aligns with the vision, that’s the conversation worth having — and that’s where asking for commitment helps you decide.

It also helps to know exactly who your target customer is. If the person across the table doesn’t fit the profile you’ve defined, their feature request — however compelling — is pulling you toward a different business.

How do you sell when you have no brand to trade on?

This was the Royal Mysore Walks problem. We had no reputation, no existing customer base, no press coverage. Nobody was searching for us.

The approach that worked was attaching ourselves to organisations that already had the trust we needed. Heritage agencies, government tourism bodies, industry confederations — these were institutions with established audiences and credibility. We didn’t try to compete with them. We positioned ourselves as a supplier to their needs, a value-add to what they were already offering.

Practically, that meant finding opportunities where larger players were already convening an audience. Government press conferences for tourism strategy reports. Heritage organisation events. Industry body gatherings. We showed up, offered something complementary, and let the association do the credibility work that we couldn’t do on our own.

This isn’t glamorous. It’s slow and requires a thick skin. But for a startup with no brand equity, it’s one of the most effective ways to build a pipeline — because you’re reaching people who already trust the institution you’re standing next to. The principle is similar to stakeholder alignment inside a company — you don’t need everyone to believe in your product yet, you need them to believe in the problem you’re solving and the people you’re associated with.

How do you handle the “is it ready yet” conversation?

This was always the hardest part. A customer is interested, they’ve seen the wireframes or the deck, and they ask when they can use it.

The honest answer is often “not yet” — but how you frame that matters enormously. What worked for me was reverting to intent questions. Instead of defending the roadmap, ask the customer how important this specific capability is to their current priorities. Often, what sounds like a hard requirement turns out to be flexible. The customer is testing you as much as they’re evaluating the product.

Clickable prototypes helped here — wireframes linked together to simulate a workflow. They weren’t functional, but they let customers experience how the product would feel. At Data Solver, these were particularly useful for complex AI features around privacy, where explaining the concept verbally wasn’t enough. A deck could carry some of that weight too, but the prototype let the customer react to something tangible rather than something theoretical.

The key insight is that the readiness conversation isn’t really about the product. It’s about whether the customer trusts you enough to wait. And that trust comes from honesty, not from pretending you’re further along than you are. Clickable prototypes are one of the most practical tools for managing this trust gap — they let customers react to something tangible without requiring functional code behind it. YC’s enterprise sales curriculum makes a similar point about founder-led sales: the goal isn’t to close the deal in the first conversation, it’s to build enough trust that the customer stays engaged through the development cycle.

None of this works, though, if the founding team isn’t aligned on what “ready” means. If one co-founder is promising features in sales conversations that another co-founder hasn’t agreed to build, the trust gap grows internally before it ever shows up with customers. Getting co-founder alignment on product direction early — what you’ll sell, what you won’t, and what “ready enough” looks like — is a prerequisite for honest pipeline conversations.

What is the real danger of the sales pipeline pulling against the roadmap?

In the early stages at Data Solver, the pipeline was pulling in multiple directions. Different potential customers wanted different things, and some of those requests were in direct conflict with the roadmap we’d set out. This is the part of trying to build sales pipeline at a startup that nobody warns you about — the pipeline itself can become the thing that pulls you off course.

This is the classic tension: sales wants the feature that closes the immediate deal, and the product vision points somewhere else entirely. The temptation to chase every opportunity is strongest when cash is tight — which is exactly when it’s most dangerous to do so.

The data correction request was a perfect example. Customers were asking for it. It sounded like demand. But building it would have meant fundamentally changing what Data Solver was. We would have gone from a compliance identification platform to something much broader, much more complex, and much harder to deliver well. We would have become a consultancy disguised as a product company.

A strong pipeline should inform what you build. It shouldn’t dictate it. The difference is whether you’re hearing a pattern across multiple customers (real demand) or responding to individual requests because each one feels urgent in the moment. This is why having a clear product vision matters even before you have a product — it gives you something to measure every request against.

What is the balance between shipping early and shipping something good enough?

There’s a constant push to release the simplest slice of value as quickly as possible. That instinct is right — waiting for perfection burns cash and delays the feedback you need.

But there’s a counter-risk that doesn’t get talked about enough. If what you release isn’t ready to support even a small number of customers well, you damage your brand before you’ve built one. Early customers are forgiving, but only up to a point. If the experience feels incomplete or unreliable, they won’t come back — and worse, they’ll tell other people.

At Royal Mysore Walks, the balance was offering one tour that worked brilliantly rather than five tours that were mediocre. Everything else could come later, but the first experience had to be good enough that people would recommend it.

The same principle applied at Data Solver, though the stakes were different. B2B customers will accept an early product at a discount — we offered initial customers a reduced rate on the understanding that this was a 0-to-1 product and their feedback would shape what came next. But that only works if the slice you’ve shipped genuinely solves something. A discount on something that doesn’t work isn’t a partnership. It’s a liability.

The danger sits at both ends. Perfectionism kills your runway because you never ship. Rushing kills your reputation because you ship something that isn’t ready. The answer is finding vetted customers — a small number of partners who understand what they’re getting and are willing to invest their time alongside their money — rather than going broad before you can support it.

Having a clear product brief for each slice of value you’re releasing helps here — it forces you to articulate what problem this slice solves, who it’s for, and what “good enough” looks like before engineering starts building.

Frequently Asked Questions