A Working Product Is a Very Convincing Way to Avoid Selling

I postponed outreach for Zaplink because I thought larger customers would want to use their own WhatsApp number.

None had asked me for that yet.

Zaplink lets businesses offer login through WhatsApp. There are two ways to handle the sending number: use a number provided by Zaplink, or connect your own. I built the managed version first, where the message comes from Zaplink’s number.

The message includes the name of the business, but the number itself isn’t theirs.

I thought that would be a trust problem. A larger customer would want their own identity on the number sending the message. Giving them that option would also make the product feel more complete.

It was a plausible requirement. That was enough for me to give it time I could otherwise have spent approaching customers.

With limited time and resources, those choices mattered. Work on the product postponed outreach. I was improving what I could offer before finding out whether the people I could approach needed the improvement.

A customer you haven’t spoken to can turn out to have a surprisingly detailed requirements list.

When I started selling to smaller customers, they were fine with the login message coming from Zaplink. The message named their business. They treated it much like an SMS arriving from a generic number.

That didn’t settle what larger customers would require. It told me something narrower and more useful for the conversations I was actually having: using Zaplink’s number was acceptable to those customers.

The managed version gave me something I could put in front of them. I could have tested that assumption earlier.

This is what makes the situation difficult to catch. Supporting a customer’s own number has a reasonable purpose. You can explain the work, show progress, and describe a more capable product at the end of it. None of that tells you whether it deserves to happen before the next sales conversation.

Once a product works, there are still plenty of defensible things to improve. Onboarding could be clearer. Documentation could be better. Another integration could make it useful to another type of customer.

Each task can be sensible on its own. Together, they can keep moving the conversation with a buyer further down the calendar.

Development also gives you a relatively clear place to put your effort. You can break a feature into tasks and watch them get done. Selling introduces questions you have much less control over. Can you reach the buyer? Does the problem matter to them? Do they understand the offer? Do they trust you to deliver it?

Another development session can leave all of those questions untouched while giving you something tangible to show for the day.

In this case, wanting a more complete product gave me a reason to keep building. I had an untested assumption, I allocated time to it, and outreach happened later. That’s the decision worth examining.

Before allowing the next improvement to delay a sales conversation, here are four questions worth asking.

1. Who has encountered this problem?

   Name the person or company and what happened. If the answer is a category of customer you hope to sell to, record it as an assumption. In my case, I expected larger customers to want their own number. I didn’t have a request from one establishing that requirement.

2. Did it actually prevent them from buying or using the product?

   Someone liking an option is different from being unable to proceed without it. Ask what they would do with the current version and what, specifically, would stop them. The smaller customers I approached accepted the managed number. That gave me evidence about those customers, without answering for everyone else.

3. Can I help them get started with the current version?

   Consider what you can honestly deliver now, including setup you can do yourself. With Zaplink, I had also offered integrations manually before building the platform. A more complete software experience isn’t always necessary to begin delivering something useful. Be clear about what the customer will receive and the help it requires.

4. What would I learn by putting it in front of them now?

   The objection might concern the feature. It might concern the price, the explanation, trust in the provider, or whether you’ve reached the right person. A conversation gives you a chance to distinguish those possibilities. Building the feature first leaves you guessing for longer.

There are good reasons to delay. If the product cannot reliably deliver what you’re offering, that deserves attention. A failure you’ve found in the core experience is evidence too; you don’t need to wait for a customer to suffer through it. You may need to fix the problem or narrow the offer before asking someone to rely on it.

The useful distinction is between a demonstrated problem with delivering the promise and an imagined requirement for making the product feel finished.

Try this with the next three items in your backlog. Beside each one, write the evidence behind it and whether that evidence justifies delaying a customer conversation. Where you have an assumption, write the question you need to ask.

For my own-number decision, that question could have been: would you use the managed version, where the login message names your business but comes from Zaplink’s number?

I eventually got an answer from the smaller customers I approached. I could have asked before treating my assumption as a requirement.

Which item in your backlog needs a conversation before it needs more code?