How to get your first 10 customers for your software product

Andy Crebar
8
 min read
8
 min read

Summary

How to find pain, create a prototype, and sell it before you build it.

Building a business is hard, but nothing will be harder than getting your first 10 customers.

Because you are starting at zero.

No social proof, no revenue, and no case studies. No one trusts you (nor should they).

Despite all this, millions of people like you make this leap every year. And once you’ve got that traction, the journey to $1 million in revenue and beyond will be much clearer.

But it's not about the number of customers or revenue.

It's about what your product, team, and company that you become in getting there.

If you’re reading this, you are likely considering launching your own product. You may work at a big company. You want to have more impact and build something that solves real problems.

This is the playbook that has worked for me and many other companies I’ve seen do it.

Step #1 - Find Pain

To get your first 10 customers, you need to find pain. Then deliver a "painkiller" to stop it.

This is important. Because sometimes, you'll find things that help prevent pain in the future ('vitamins'). But the thing is…

It's 100x harder to get traction with a vitamin versus a painkiller.

Pain points are everywhere; you need to be observant enough to notice them.

There are many ways to find inspiration. But if you want to build traditional or role-specific software, there is a proven shortcut. Spreadsheets.

People often use spreadsheets to patch together a solution for an unsolved problem. It's a telltale sign of their efforts.

The key is to find these manual processes. Then, create a general solution that helps many people or companies solve them.

In 2015 and 2016, my co-founder and I faced a tonne of pain in employee onboarding at our companies. We figured that this might be a common problem.

In talks with other high-growth tech and finance firms, 90% had a huge, colour-coded 'onboarding' spreadsheet.

Rows were people and columns were tasks. It was a chaotic mess.

Every company had its version of it. They all hated it with a passion. The pain was real.

Excel onboarding checklist tracking employee status, tasks, equipment, and start dates. Ideal for HR and employee management - Andy Crebar

Our focus was to "kill that spreadsheet."

If you can find where people are making custom solutions to solve these generic problems, you are more likely to build something they will want and use.

Once you’ve identified the pain, it’s time to make it visual.

Step #2 - Build the Prototype

At this step, your first instinct might be to start writing software for the product.

Do not do this.

Building software wastes a lot of time and money. Many founders burn out before they have a viable product. You want a clickable prototype. It should show the experience and find flaws in your hypothesis.

A clickable prototype is something that looks and feels like software, but it isn't.

There are hundreds of no-code tools, like Figma and InVision. Use them to create a demo version for potential customers.

It works because prototypes are much faster and cheaper to make than real software. You can also make quick iterations based on feedback. This avoids the overhead of full-scale development.

But the most important thing is that it's much easier to sell a prototype than a PowerPoint and a dream.

Prospects can visualise it in action. Some customers won't know they're looking at a prototype. But it's just a bunch of linked, clickable images, like this.

Once we have the prototype, it's time to start selling it and getting input from real people.

Step #3 - Get Advice and Avoid Creep

Taking a prototype to people in pain and selling it as real software is the best step to get real, tangible feedback.

But the problem is that people do not want anyone to sell to them. Decision-makers get thousands of sales emails each month.

As a founder, you have a strategic advantage here. While people don't want anyone to sell to them, they do want to help.

Asking for a meeting to ‘get their advice’ is going to be far more fruitful and help make them feel as special as they are.

If you solve a painful problem, the conversation will shift to how they become a customer. You can then flip the conversation to that. If not, that's fine—use their input to make the product better.

When you show this prototype, people will question its limits. You will get feedback like “It needs to do X or Y,” but that’s part of the process.

The natural inclination is to keep building more functionality into the prototype.

But the thing is, software is never finished. There will always be another feature to build. There will always be something that's not quite right. There will always be something missing.

None of this matters.

Your product must solve the pain point and fit into the customer's workflow. That's what matters.

The more robust your prototype and product are, the harder it will be to sell and install.

This may seem intuitive. But, expanding your product's surface area may then overlap with other workflows or products.

It is much harder to sell something that tries to replace something already in place

You want to avoid telling a customer that they must change their existing workflows to implement your product.

Replace that one spreadsheet to start. You can expand later. But for your first 10 customers, you want to wedge into their existing workflows.

The more robust your minimum viable product (MVP), the more complex the sale will be. The harder it will be to get traction.

To visualise this, think about the balance of business value and complexity. Start-ups gain traction and momentum for ‘Low Complexity, High Value’ solutions.

Chart showing product prioritization based on low complexity and high value, focusing on high-potential product development - Andy Crebar

Many incredible founders go after big bets—think Palantir, Workforce, and Salesforce. It can work, but it requires a tonne of expertise and capital.

Back to us. The goal of the 'Low Complexity, High Value' prototype is to get commitments from customers.

Before we move to the next step of building the MVP, we want cash in your pocket (although unlikely). Signed order forms are next, then finally, as a last resort—verbal commitments.

You want to have conviction that if you invest in building that prototype, people will adopt it.

Step #4 - Build the MVP

You’ve got commitments from customers. It’s time to build.

The most common mistake is founders trying to build everything they have prototyped.

To get a customer to say yes, you likely have to show them a complete product with all the bells and whistles.

But a feature-complete product can lead to complexity and failure. You need feedback and iteration as you go.

Henrik Kniberg has a great framework for this in thinking about it as selling a car.

You’ve sold the dream. The customer is expecting 4 wheels and 0 to 100 km in 5 seconds. 

But you don’t start by building the car. You give them a skateboard that allows them to go from A to B.

They're not going to be happy, but the key thing is that they can use it. It solves enough points and gets into their hands.

You get their feedback, make adjustments, and build the vehicle step by step. This process keeps you aligned with the customer's true needs.

You create a more refined product (like a convertible without a roof). Their input helps you along the way.

You can add more features later. But it's key to have people try a smaller version of the complete thing, not its parts.

Illustration showing a better iterative product development process that improves user satisfaction compared to a non-iterative one - Andy Crebar

Sometimes along this journey, building even a simple MVP requires funds that you do not have.

This is where your order forms and prototypes become invaluable.

The vast majority of startups fail due to a lack of demand for the product.

Show investors you have ‘proof of demand’. You’ve removed the biggest risk with a validated concept with real customer interest. 

Your pitch should then be simple and powerful.

"We’ve built a prototype and have 10 signed order forms from customers who are ready to buy. We need your investment to build out the MVP, and we’re offering a sweetheart deal to get you on board now."

That’s an exciting story to rally around and for investors to throw money at.

Step #5 - Force-feed the dog food

I said that asking people to change their behaviour is going to be fraught with risk and apprehension.

Asking people to adopt the first iteration of your product is going to be even harder.

But product usage is like oxygen. You need people using the product so you can start learning and rounding out the edges.

Getting your first customers to use your product will be tough. There will be unexpected issues and problems.

Things will go wrong, but this is part of the process.

Use those shared (traumatic) experiences to strengthen your relationship with customers. 

You build trust when people know you will resolve issues without delay.

Integrating with other platforms can complicate your quest as well, especially if you are writing data to other systems. Fixing your own software is painful, but fixing data in other companies’ software can be excruciating.

At my first start-up, we’d quickly started pushing in 1000s of pieces of data into payroll systems in the early months. One of our field validations was off, resulting in blocked payroll for some of our customers.

We couldn’t fix it without access to their payroll systems—leaving them to do the cleanup. Ouch.

You will likely need some integrations to get started. Manage these with caution to avoid causing problems outside your own product.

Step #6 - Document Success

After acquiring your first few customers, it is time to document the process.

Case studies are the best sales tools. They are vital in the early stages when no one knows, likes, or trusts you yet.

To get your first 10 customers, get that case study ASAP. It will show potential customers that you've solved the same pain for someone else. The sales process will then be much smoother.

The format of case studies should follow the same structure:

  1. Overview of the company - Who is the company, how big are they, and what do they do?
  2. Before - What was the situation before your product or service?
  3. Implementation - How did the customer go live and adopt it?
  4. Results - What business impact outcomes did they achieve from it?
Diagram showing the ideal case study format, with company overview, problem identification, implementation, and results - Andy Crebar

Why this is important is that it allows you to tell the story of the customer in a logical way.

Referrals can be a great lead source, but some early customers may not have had the best experience with the first version of your product.

That's okay. It means you need to find more customers yourself.

For me and some early-stage software firms, sales come from founder-initiated, direct interactions. That means getting a warm intro or going in cold to get "advice" on your product roadmap.

If this helped and you want to start, I wrote another article on reaching $1 million in revenue. I'll share it soon.

Andy Crebar

Follow on

Keep Reading

View all