tldr; Stop building. Please do marketing.
I know. You have one more feature to ship first.
The onboarding is not perfect. The settings page feels weird. There is a small bug in a flow that three people might use. Your landing page could probably be better. You still need to refactor that one component before anyone important sees the product.
So you keep building.
It feels like work because it is work. There is a commit at the end. Maybe a pull request. Maybe a satisfying green checkmark.
But after you have a usable MVP, building can become a very respectable way to avoid the uncomfortable part of running a company: finding people, asking them to try something, and listening to what they say.
I have seen this countless times. I have also done it countless times.
Every time, I thought my situation was different.
Spoiler alert: it wasn’t.
This is not an argument for leaving broken software online or ignoring problems that stop users from succeeding. Fix blockers. Fix security issues. Fix the thing that makes the core product unusable.
The point is simpler:
Once a real person can use the product, stop treating more speculative features as the default next step.
Go find customers.
The MVP is a starting point, not a hiding place
An MVP does not need to represent the full vision in your head. It needs to deliver enough value for a specific person to try it. Y Combinator’s MVP guidance makes the same distinction: launch something useful, then learn from real users instead of planning the complete product in isolation.
That is it.
It does not need every integration. It does not need five pricing tiers. It does not need to support every possible customer. It definitely does not need to feel emotionally complete to the founder who has been staring at it for six months.
After launch, the important unknown usually changes.
Before the MVP, you are asking:
Can we build something that solves this problem?
After the MVP, you should also be asking:
Who actually cares about this problem, and how do we reach them?
Those are different questions. More code does not automatically answer the second one.
A founder can spend another month improving a product without learning whether the right people want it. That is the trap. The product gets more elaborate while the evidence stays the same.
You still do not know who your best customer is. You still do not know what makes them hesitate. You still do not know whether your message makes sense to anyone outside your own head.
That is not a feature problem.
How to get your first customers after the MVP
Your first customers probably will not arrive because the product finally has enough features.
They arrive because you deliberately put it in front of a narrow group of people and help them use it.
Pick one narrow customer group
“Anyone who wants to be more productive” is not an ideal customer profile.
It is a wish.
Choose a real group with a specific problem. What are they trying to do? What do they use now? What happens when the problem becomes painful? Where do they already spend time online or in person?
You do not need to get this perfectly right on the first attempt. Treat it as a hypothesis. Pick one group, try to reach them, and pay attention to what happens.
The important thing is to stop aiming at everyone. When you aim at everyone, you have no idea where to look, what to say, or whether anyone is responding.
A narrow customer group gives you somewhere to start.
Go where those people already are
The best channel depends on the people you are trying to reach.
If your ideal customers are startup founders, some startup communities might be useful. If they are local business owners, maybe a Discord server is not your best first move. If they are enterprise operators, posting into the void on a random social network probably will not produce a reliable sales motion.
You do not need to post everywhere just because every platform exists.
Find the places where your potential customers already ask questions, complain about existing tools, compare alternatives, or look for help.
Then show up there with something relevant.
Not a ten-paragraph product announcement. Not a link dumped into a community you joined five minutes ago. Start by understanding the conversation. Be useful. Talk to people who have the problem.
Get your first customers manually
There is no secret technique.
The secret technique is doing the manual work consistently enough to learn from it.
Send the personal message. Make the introduction. Reply to the person who described the problem. Set up the product for them. Sit beside them while they try it. Walk them through the confusing part.
It is not glamorous. That is why people avoid it.
Early customer acquisition is often supposed to feel a little inefficient. You are not optimizing a machine that already works. You are trying to discover what the machine should be.
A manual customer can teach you things that a thousand anonymous impressions cannot. They can show you which part of the problem matters, what language they use, what they expected to happen, and where your product loses them.
This is why early-stage founders are often better off doing things that will not scale yet. Paul Graham makes the same case: do the manual work first, learn what matters, and worry about scale after you understand what deserves to scale.
Talk to real humans, not generic automation
Then go talk to real humans.
Not LLMs.
I am not saying you can never use AI to organize research, prepare notes, or help you think. I am saying that an obviously generic message is still obviously generic, no matter which tool produced it.
People can tell when you have not understood their situation.
Write to someone because they are plausibly dealing with the problem, not because you found a list of names and want to hit send. Mention the thing that made you think the conversation could be useful. Ask about their current workflow. Ask what they tried. Ask what would make the product valuable enough to use again.
If you are introverted, fake it for long enough to get started. Create a persona in your head. Pretend you are doing research for someone else. Start yapping.
Post on the channels where your customers actually are. Join communities. Send DMs when they are relevant. Make the introduction. It might feel cringe. That is fine.
The goal is not to become a full-time internet personality. The goal is to stop guessing.
Analytics tells you what happened. Conversations tell you why.
Instrument product analytics.
Use something like PostHog’s user paths to see what people actually do on your website and inside the product. Watch the paths they take. Look for places where they stop. Notice whether they reach the page you expected or disappear three clicks earlier.
This is useful because your memory is not analytics.
You will remember the one person who loved the product. You will assume everyone understands the landing page because you wrote it. You will imagine users moving through the happy path while real people are clicking on something else entirely.
Analytics gives you behavioral evidence.
But analytics does not always tell you why something happened.
A visitor may leave because the product is confusing. Or because the audience is wrong. Or because the price is unclear. Or because they were never serious. Or because the page loaded slowly. Or because they opened the tab while waiting for a meeting and forgot about it.
A drop-off is a question, not an explanation.
That is why analytics and conversations belong together:
- Observe what people do.
- Talk to people who are willing to explain it.
- Help them through the immediate problem.
- Fix the smallest repeated blocker.
- Watch what happens next.
Do not use a dashboard as an excuse not to speak to anyone.
Your website traffic is not just a number
If people are already reaching your website, do not waste that attention.
Not every visitor is a customer. Not every pageview deserves a phone call. But some people are looking at pricing, checking onboarding, reading the feature page, or spending enough time with the product to show relevant intent.
Most websites make those people wait.
They fill out a form. They book a meeting. They send an email. They wait for a reply. By the time someone responds, the visitor has moved on.
I kept seeing that problem while working on HeyZinc. People would get stuck during onboarding or try something, hesitate, and leave without saying much. I kept thinking: if I could talk to them at exactly that moment, maybe I could answer the question before they disappeared.
That was the idea behind HeyZinc.
When a relevant visitor meets configured intent criteria and is active on the site, the product can help the team notice and start a conversation. Depending on the setup, that can mean messaging, calling, or moving into a meeting while the context is still fresh.
I am not going to pretend that this is a magical conversion button. The belief that a live conversation could help was the product hypothesis. The useful part is creating a chance to learn from someone who is already showing intent instead of treating them as an anonymous number in an analytics dashboard.
If this is the kind of workflow you need, start with getting started with HeyZinc, then learn how to reach website visitors while they’re still active.
Early users need help, not just access
Your first users are not just signups.
They are people trying to get value from a product that is probably still rough around the edges.
Your onboarding is not perfect. Something is probably unclear. One integration probably behaves differently from what the user expected. The copy might describe the product in language that makes sense to you and nobody else.
That is fine.
Get on a call. Answer the question. Watch where they hesitate. Help them complete the first meaningful action.
You will learn whether the problem is the product, the positioning, the audience, the pricing, or the way you explained the thing. Customer discovery is useful precisely because those are different problems, and they require different solutions.
If five early users all get confused in the same place, fix it. If five people do not care about the problem you thought was urgent, do not immediately build a bigger version of the same solution. Go back and ask better questions.
One real conversation can teach you more than another week of coding.
That is not a benchmark. It is just what it feels like when you finally replace a theory with evidence.
When should you start scaling marketing?
Do not scale because you hit an arbitrary customer number.
Scale when you have evidence that a defined group gets value, some people are willing to pay or make a meaningful commitment, the same problem keeps appearing, and your way of reaching and helping them can be repeated.
Then turn the manual lessons into systems.
Improve the onboarding. Rewrite the message. Document the setup. Build the feature that removes a repeated blocker. Create a better referral loop. Automate the part that is now understood.
This is where building becomes useful again.
You are no longer adding features because they might make the product more appealing to some imaginary future customer. You are building because real customers showed you a repeated problem and you know why it matters.
The center of gravity can move back and forth between product and marketing. The point is not to stop coding forever.
The point is to stop using coding as a substitute for distribution.
Do the uncomfortable work this week
If you have an MVP and no customers, try this:
- Write down one narrow customer group.
- Find ten people or places where those people already gather.
- Start five specific conversations.
- Watch one real person use the current product.
- Write down the exact point where they get confused.
- Fix the smallest repeated blocker.
- Repeat before adding another speculative feature.
You do not need a perfect marketing strategy.
You need repeated contact with reality.
Build the MVP. Stop polishing the future. Go find people. Help them. Listen carefully. Then build what the evidence tells you to build.
The product is not finished when the code is finished.
It becomes real when people use it, struggle with it, pay for it, and give you enough truth to know what should happen next.
