Let Your Client Pay You to Build Your Product Roadmap

The Word 'Mostly' Is Doing a Lot of Heavy Lifting

I was on a call with my dev team recently, going through a list of feature requests from a new batch of prospects. CRM integration. Centralized portal for managing live chats. Custom lead routing. WhatsApp integration. One by one, we went through the list.

And almost every time, my answer was some version of: yeah, Galadon can mostly do that.

Mostly.

That word kept coming up. And at some point in the call it hit me - that word is actually the most valuable word in early-stage product development. Because 'mostly' tells you exactly what to build next. Not a survey. Not a user interview. Not a $30,000 product discovery sprint with a consulting firm. A paying client, on a sales call, telling you in plain English what they need - and already signaling they'll pay for it.

That's not a problem. That's a funded roadmap.

Most Founders Are Guessing While Sitting on a Gold Mine

I've talked to a lot of early-stage SaaS founders over the years. And almost all of them are building in the dark. They have a hypothesis about what the market wants. They build it, ship it, then wonder why nobody's paying. So they go back and build something else based on another hypothesis. Rinse and repeat.

Meanwhile, they're ignoring the single best source of product intelligence available to them: the actual requests coming in through their services work or their sales calls.

If you're running any kind of agency or consulting business alongside a SaaS - and plenty of founders do, especially early - every custom scope request is a data point. Every time a prospect says "can it do X?" and you have to say "not exactly, but kind of," that's a vote. That's the market telling you what the next version of your product should be.

The founders who figure this out fast are the ones who close more clients, retain them longer, and build products that actually have product-market fit. Because they're not guessing. They're letting paying clients tell them exactly what to build - and paying them to do it.

Here's How It Actually Works in Practice

Let me make this concrete. On the call I mentioned, we had a prospect asking for a handful of specific things on top of the core Galadon setup. A centralized portal to manage all their live chats. Lead capture that routes directly into their CRM. Some WhatsApp functionality. And a few other items.

Most of those? Already in the product. Or 90% of the way there. The dev work is minimal.

But there were one or two things - particularly around the WhatsApp piece - where the honest answer was: we'd need to build that. It's not done. It's a little cloudy for us right now technically.

That's the gap. And the gap is the roadmap.

The play here isn't to say "sorry, we can't do that" and walk away from the deal. The play is to price the engagement in a way that accounts for the build cost, sign the client, and use their contract to fund the feature. Then - and this is the key part - that feature is now in the product for every future client.

You're getting paid to build something that makes your product more valuable. The client gets a custom solution. You get a funded, real-world-validated product improvement. Everyone wins.

The Gut-Feel Estimate: Know Before You Promise

Now, there's a version of this that goes badly, and I've seen it plenty of times. A founder gets excited about a prospect's request, quotes them a price, signs the deal, and then the dev team comes back with a number that's five times what they expected. Deal goes sideways. Margins get destroyed. Client ends up unhappy because timelines slip.

So before you price anything - before you get on the closing call - you need a gut-feel estimate from your technical team.

I'm not talking about a formal scope document. Not a full sprint planning session. I mean exactly what I asked my dev lead on this call: is this a thousand hours of work? A hundred hours? Ten thousand? Give me a ballpark. Because if I'm charging a client $10,000 for this build, I need to know whether we're going to lose money on it or whether I need to be at $20,000.

That's it. High-level. Order of magnitude. Enough to know whether the deal makes sense before you commit.

Then once the deal is signed, you do the detailed scoping. But you don't go into a sales call blind on the build cost. That's how you end up underwater.

The Structure That Makes This Work

Here's how I'd think about structuring a services engagement that's designed to fund roadmap development:

• Separate the implementation from the feature build. Be clear with yourself (and optionally with the client) about what's standard setup and what's custom. Don't blur the lines, or you'll start giving away custom dev work for free.
• Price the custom work at a rate that covers your dev cost plus margin. You're not doing charity work here. The client is paying for a solution. Build that cost in.
• Log every custom request as a product backlog item. The first time someone asks for something, it's custom. The second time, it's a feature. The third time, it should be in the core product.
• Get the gut-feel estimate before you quote. Always. Even if it's five minutes on Slack with your tech lead. Know the rough size of the build before you price the engagement.
• Design for generalization from day one. When your dev team builds the custom feature, make sure they're building it in a way that can be turned on for any client - not hardcoded for one. That's the difference between doing services work forever and building a product.

This Is How You Get to Product-Market Fit Without Burning Cash

The conventional startup advice is to go raise money, hire a product team, do user research, run betas, iterate. And maybe that makes sense at scale. But if you're in the early stages - bootstrapped, or close to it - that model is slow and expensive and based on a lot of speculation.

The services-to-product model is different. You're not speculating. You have a real client, with a real budget, asking for a real thing. The risk is almost entirely removed. The question isn't will anyone pay for this? - because someone literally already is. The question is just: can we build it profitably and fast enough?

I've seen this pattern work in my own businesses and in the businesses of people I've coached. The companies that get to product-market fit fastest are almost never the ones that built in a vacuum. They're the ones that stayed close to clients, listened obsessively to what wasn't quite working, and used services revenue to fund the gap.

The SaaS exits I've had - I didn't build any of them in isolation. Every major product decision had a client signal behind it. Someone said "I'd pay for this if it did X." So we built X. Then we had a better product. Then we raised the price. Then we sold it.

The Sales Side: How to Handle the 'Almost' Conversation

There's a specific moment in the sales conversation that matters here. It's when the prospect asks "can it do X?" and your honest answer is "mostly."

Don't fumble that moment. Don't get vague. And don't overpromise.

The right move is to be direct: "Yes, we can do that. Here's what's already built, and here's what we'd need to configure for your specific situation. That would be part of the implementation scope." Then you move on. You've turned a potential objection into a line item.

The worst thing you can do is promise a feature that doesn't exist yet without pricing it, then scramble to build it post-signature while your dev team is already stretched. That's how you end up with unhappy clients, missed timelines, and a team that hates working with you.

Be honest about the gap. Price it in. Then build it. Simple.

If you want a framework for how to run these conversations - how to ask the right questions on a discovery call, how to surface what clients actually need versus what they say they want - grab my Discovery Call Framework. It's free and it'll tighten up how you handle these exact situations.

One More Thing: Not Every Request Is Worth Building

I want to be real with you here. Not every custom ask should go on the roadmap.

On the call I mentioned, the WhatsApp integration came up. And my honest reaction was: let's not spend too much time on that right now. They're not a signed client yet. It's technically complex. And I'm not sure enough clients will need it to justify the build cost at this stage.

That's the filter you need to apply. Every custom request is a candidate for the roadmap. It doesn't automatically make the cut. The question is: how many other clients have asked for this, or are likely to ask for it? If the answer is "a lot," build it. If the answer is "just this one," maybe you price it as a pure custom build and don't generalize it yet.

The signal you're looking for is repetition. When the same request comes from three different clients in different industries, that's when you know it belongs in the core product. One request is interesting. Three requests is a feature.

The Bottom Line

Stop guessing at your product roadmap. Stop building features based on what you think the market wants and start listening to what paying clients are already telling you they'll pay for.

The gap between what your product mostly does and what clients are explicitly asking for is not a liability. It's your roadmap. And the right services engagement structure lets you fund that roadmap with client money - which means you're de-risking the build, validating the feature before you ship it, and getting paid in the process.

That's not a bad deal.

If you're doing outbound to land the clients who can give you this kind of signal, make sure your targeting is tight. Tools like ScraperCity's B2B lead database and the email finder are what I use to build prospect lists for exactly this kind of targeted outreach. You want to be talking to people who actually have the budget and the specific pain your product almost solves - because that's where the best roadmap signal comes from.

And if you want to pressure-test your cold email approach before you start sending, grab my Top 5 Cold Email Scripts - free download, no fluff, just the formats that have generated meetings for 14,000+ businesses I've worked with.

The best founders I know aren't the ones with the best product ideas. They're the ones who listen well and build fast. Start there.