How to Sell Products and Retain Customers

From a user's point of view, what products I rave about have done right.

Before thinking about PMF, devtool vendors first have to: understand the audience, source leads by appealing to said audience, onboard them to the particular tool, and only then can vendors think about retention. This is largely encompassed by the developer experience function with a sprinkle of marketing and growth.

Where do vendors start with the goal of getting people hooked?

Don’t build toys, solve problems

Photo by Crissy Jarvis

If I, a potential customer, read a marketing page explaining how the product is built or a detailed rendition of what it does, I usually move on quickly. It begs the question, so what? Why should I pay money for this? Every real problem can be boiled down to either saving time or money.

Rolled out a change with a mistake because there wasn’t any testing? It’s either going to cost the business money because the product isn’t functioning properly or waste a developer’s time fixing the issue—time that could’ve been spent doing something more productive had the mistake not occurred in the first place.

Can’t use Python easily in a workflow that’s built for SQL? Workarounds make a task take longer than it needs to if there was only the right tooling, again coming down to wasting precious development time. At the end of the day, development time is money—engineers don’t work for free.

Consider the abacus as the product and society is blissfully unaware that modern calculators and computers exist (or we’ve all somehow traveled hundreds of years back in time). If you had to sell it in one sentence:

❌ Marketing a toy: A beautiful wooden structure with hand crafted beads that easily glide across 10 horizontal rods used to make calculations.

✅ Solving a problem: A calculator that can be used anywhere to avoid mathematical mistakes, saving your business otherwise lost money and time while checking out eager customers.

Sure, after solving the problem you can tell the audience how this particular abacus compares to some other ugly metal one. Eventually, the best products get to the “joy to use” phase. Before that, the user has to need the product and rely on it.

We all know what an abacus is. This seems obvious. In the data world, I think many of us (not excluding myself here!) are guilty of sometimes keeping horse blinders on. Do I care that a tool “makes the data stack experience better”? Sure, but… how? How is my experience better and why should I care? If the tool allows me to do something I need to do as part of my job that I can’t easily do otherwise, now you’ve started selling me.

A good onboarding experience converts

Source

And a bad one leaves money on the table. Let me explain.

As the vendor, say you’re at the point where you’ve got the potential customer sold on what you’re doing. They have a problem, and you’re solving it. The real work is by no means done—the user’s process hasn’t changed.

Consider where users are today. The most desperate ones have built some hacky internal process to get around the problem at hand. Maybe in the Python example, they use Jupyter Notebooks to make graphs, screenshot them, and put them in Slack for stakeholders to see. Even if they’ve signed a contract for your product for a year, they’re not using it yet. The hacky work-around still exists.

There are two types of users, the first being ones that are already doing what the product does just very inefficiently. The second user wants the to do what the product accomplishes (again consider developing visualizations in Python) but isn’t actually there yet. The first user is the desperate one—they already know the value the particular product provides!

Going from something to a tool is different than starting with the tool in question from scratch. Some process and/or code exists, and it’s the vendor’s responsibility to walk the user through changing that process and moving the code.

The transition from the hacky process to the product cannot be manual and difficult.

Let me say that differently. A user is already excited to use a tool that will remove manual work and inefficiency. And the first thing, as a vendor, that you’re asking the user to do is go through a manual inefficient flow? That’s a blow to the gut. (Let me caveat this with talking about post-Series A products—in MVP stage, well that might be a different story and the price would likely be lower as well.)

Eventually, you’ll have users that don’t have this hacky process and want to use the product. Not having both types of users rave about ease of use is just a missed opportunity.

Hooked customers will deal with bugs

Of course, the product has to function. Customers that rely on your product will deal with small bugs, and even help you find and fix them. But first, they have to understand how to integrate your product within their ecosystem.

Everyone wants to be the next end-to-end platform. But first, you need to be a solid wedge.

Thanks for reading! I talk all things data and startups so please reach out. I’d love to hear from you.