DEV Community: Dan Liang

A founder asks: We got certified, worked through testing, and still lost the deal after five months. What did we do wrong?

Dan Liang — Fri, 13 Nov 2026 12:00:00 +0000

The founder of an AI agent startup wrote on Hacker News that an enterprise buyer had approached his company and asked for ISO 27001 certification. After the company got certified, the two sides spent about a month testing the product and revising it. Then the buyer stopped replying. He heard from someone he knew inside the company that it had chosen another vendor. By his account, he'd put five to six months into the deal.

What's hard to let go of is the collaboration that came before. If they ended up choosing someone else, why did they take the time to lay out their requirements carefully and work through changes with you?

Have you been through something similar?

We don't think losing the deal means all the earlier work was wasted. Once the requested certification was in place, the two sides did move on to testing. That step had value. But getting certified doesn't mean the buyer now has a reason to choose you.

What's easier to miss is that a buyer may keep testing carefully precisely because they still need to understand how the vendors differ.

Wynter surveyed 100 B2B SaaS marketing leaders who had recently evaluated competing vendors. In response to the question “When the vendors on your shortlist feel interchangeable, what do you typically do?”, 41% selected “Push for a deeper trial or demo.”

That doesn't represent all enterprise AI purchasing, but it does make one possible motive clear: a buyer needs the trial to develop a basis for choosing that they don't yet have.

The buyer's requirements can be real, and the people involved in testing can be taking it seriously. Fixing problems uncovered during testing helps the buyer see how the product performs in actual use. But once those problems are solved, the differences between you and the other vendors may still not be enough to affect their choice. A deeper trial might even show them that a particular feature difference isn't all that important to them.

An evaluation can make progress and end with a decision not to choose you. Serious collaboration doesn't mean you'll win the deal.

Testing can end in a pass, a failure, or no clear conclusion. Even if a product passes technical testing, the buyer may not yet have secured budget approval, completed internal approvals, or signed a contract. During procurement, the problem they want to solve and what they intend to buy may also change.

We can't use any of those possibilities to draw a conclusion about this founder's case. He didn't report the test outcome or say whether the buyer had made a commitment to purchase. The specific reasons for the lost deal and the silence are also unclear. If a deal already includes a clear commitment to buy once certain conditions are met, we need to look at what that commitment was, whether the conditions were met, and what happened afterward.

When a buyer assigns engineers, discusses problems seriously, and works through repeated rounds of testing, it's understandable that the seller feels more hopeful. For example, suppose a company wants to use AI to answer customer support questions and worries that it will mix up old and current return policies. The buyer gives two vendors past customer questions that could easily lead to mistakes, asking each to answer using the current policy and show what the answers are based on.

If both meet the agreed requirements, that round of testing serves a real purpose: the buyer has seen how the products handle those questions, and the errors they were worried about haven't appeared in testing. But the buyer may also discover that both products are good enough for this particular use. The test has resolved one concern without giving them a reason to choose you.

If the buyer then asks, “Could you adjust the tone of the replies a little?”, we'd look at how much that change matters to their choice. If they think both products' answers are suitable for their support team to use with only a small adjustment in tone, further refinement can make the product easier to use without changing their judgment that both are good enough.

In this example, we recognize the value of the first round of testing. But we wouldn't raise our expectations of winning the deal just because the buyer has made another request. If the next round of work is intended to help win this order, we wouldn't support investing more in tone adjustments at this point: there's no basis yet for saying that this improvement would change the buyer's choice.

The work already done doesn't have to be written off as wasted. The work that comes next still needs its own justification.

Why customer feedback may not settle your messaging debate

Dan Liang — Tue, 10 Nov 2026 17:03:43 +0000

When you're deciding which benefit to lead with, putting customer feedback and product observations on the table doesn't always settle it. You've explained your reasons. Why is your colleague still objecting?

When we analyze this kind of disagreement, we start by asking which buying question each reason answers. You may be discussing the same benefit while comparing the product with different alternatives. The extra reasons you offer may leave your colleague's objection unanswered.

In her public Forget The Funnel conversation with Gia Laudi, April Dunford recalled the arguments she encountered when she first brought cross-functional teams together. A founder would list reasons customers bought. Sales would question one because other products offered it too. Someone would cite what customers had said, while product would argue that if everyone could do it, customers must have chosen them for another reason. These arguments generally ended with the founder deciding, or sometimes the head of sales. Her explanation was that people had different competitors in mind, which led them to accept different value propositions. What sounded like a messaging dispute could reflect disagreement about the positioning behind it.

Consider a hypothetical example. One colleague is comparing the product with the customer's existing manual process. Another is comparing it with the other products on the customer's shortlist. The first is asking why this benefit makes changing the current process worthwhile. The second is asking why a customer would choose us when several products offer the same benefit.

A customer mentioning the benefit supports the case that it matters to them. That alone doesn't establish that it makes us a better choice than the other products. If competitors offer it too, the benefit may do little to distinguish the products. That doesn't rule it out as a reason to leave the manual process behind.

Both colleagues can accept the same observation and still disagree about the selling point it supports. One keeps explaining how much customers care; the other keeps pointing out that competitors can do it too. The discussion can remain stuck. The first hasn't explained how customers choose among products. The second hasn't undermined the value of changing the current process.

Before revising the wording again, it helps to make the buying question explicit: Who is this message for? What are they comparing us with? What conclusion can this customer feedback support? Those questions help establish why a benefit deserves to come first. They also help reveal whether a colleague disputes the observation itself or the inference from that observation to the selling point.

Sharing a basis for the decision still leaves room for different messages. A free trial aimed at end users and a sales conversation aimed at management buyers may need very different value propositions. A homepage's job also needs to be clear. A team can use different messages while understanding whom each one helps and what choice it helps them make.

A leader can choose a version, but that doesn't establish the buying rationale behind it. Conflicting instructions or copy that hasn't been approved can also hold up the work; positioning disagreements don't explain every delay. Clarifying the comparison, doing more research or rewriting the copy doesn't guarantee agreement.

But connecting a real observation to the buying judgment it can support gives the next revision a specific question to answer: Does this sentence address the objection, or does it just restate our own reason in different words?

AI Can Improve Service Delivery. That Doesn’t Show Clients Will Buy the Plan.

Dan Liang — Mon, 09 Nov 2026 13:30:01 +0000

Some professional-services work is already being handled by AI. If your next investment is in planning, review or judgment, start with what you need that capability to accomplish.

It might make an existing service better: more accurate plans, fewer omissions, less rework or lower delivery costs. Or it might become a service clients pay for separately, with the planning or review itself as the outcome they buy.

The same capability can serve both purposes. Better delivery may help a separate service take shape. But improving an existing project doesn’t, by itself, show that clients want to buy the planning involved as a distinct offering. A new paid service still needs evidence that its delivery is valuable and that customers want to purchase it separately.

That distinction matters when deciding where the next investment belongs.

What the tool already covers

Before investing in planning as work that sits outside AI tools, look closely at which parts those tools already cover—and which still require human effort.

FastRuby.io’s own free and paid offerings provide a concrete example.

According to its README, the free Claude Code Rails Upgrade Assistant skill can analyze an actual codebase and generate upgrade reports, provide before-and-after code examples, preview configuration changes and plan a migration step by step across versions. “Free” here refers to the published skill, not a claim that running it is free.

The README also describes limits. Deployment strategies are outside its scope. Investigating complex runtime patches and resolving dependency conflicts require manual work. Time estimates are rough guidelines. The skill supplies guidance and examples; the user implements the upgrade.

The same team’s paid The Roadmap to Upgrade Rails is described on its official page as an application-specific audit. Two developers each estimate the best- and worst-case time and cost for every version upgrade. They combine scripts with manual checks of gems, deprecation warnings, technical debt and upgrade obstacles to produce a 15-to-50-page, step-by-step plan.

Clients can use that plan to carry out the upgrade themselves or ask FastRuby.io to perform it.

Based on these official descriptions, the free skill and the paid Roadmap partly overlap in generating upgrade reports and plans from a codebase. That overlap does not establish equal quality or capability. It doesn’t show that the skill has replaced the Roadmap, or that clients will necessarily continue buying the paid service.

These are the supplier’s descriptions of its offerings—not independently verified performance, substitution, customer demand or business results. No tool comparison tests or customer purchase data were collected for this discussion.

Still, the same provider has put part of its upgrade-planning work into its own free tool. “AI handles execution; planning and judgment stay outside” is no longer enough to identify which specific capability deserves further investment.

And work outside a tool’s scope is not automatically work clients will buy.

Match the evidence to the investment

If the investment is intended to improve existing upgrade delivery, start with the projects you already do.

Are upgrade plans becoming more accurate? Are there fewer omissions? Is manual checking or rework falling? How much additional effort is still needed for work the tool doesn’t cover?

Those changes can support continued investment in an existing service. They help explain whether the capability is making delivery better, while leaving room to consider the effort and cost required to achieve those gains.

If you also want to sell the plan separately, there’s another question: why would clients choose that purchase rather than use available tools, assign an internal team or seek help elsewhere?

The answer needs to be tested against clients’ actual choices and their responses when offered something to buy. Uncovered technical work may help explain the value of an offering, but its existence alone doesn’t establish demand.

That doesn’t mean a small experiment must wait for completed sales. It means customer response is evidence in its own right. More accurate plans and less rework cannot stand in for it, and delivery improvements don’t justify further investment at any cost.

For an upgrade-planning service, both lines of inquiry can develop together. Improving plans within existing projects may reveal a useful separate offering. Testing that offering may clarify what clients value about the work. Neither possibility removes the need to show that the service delivers something useful and that clients want to buy it in that form.

Making delivery better can support investment in the service you already provide. It does not, by itself, establish that a new paid service is worth building.

Your Customer Said the Product Was Too Cumbersome. You Fixed It. They Still Left.

Dan Liang — Fri, 06 Nov 2026 13:00:00 +0000

A proposal software company kept losing customers. Revenue was falling, and the founder was under pressure.

They needed to understand why people were leaving. So the team collected more cancellation feedback. Most departing customers said the product was too cumbersome to use.

That gave them a direction. They cut steps in the parts customers complained about and made proposals faster to create. After one round of changes, churn fell by 30%.

That's a good result. But it's pain relief, not growth. Fewer customers leaving doesn't mean the product has found a new direction for growth.

Making a product easier to use relieves the pain. Helping customers get the result they paid for is where growth begins.

When a customer says the product is cumbersome, we immediately want to cut steps and redesign the interface. But customers usually aren't buying fewer clicks. They're buying the ability to get something done. If they still can't do it, they can leave even when the product is easier to use.

Ruben, the founder of Bidsketch, once shared the story of a customer. I'll call him Alex here.

When Alex canceled Bidsketch, he only said he wasn't using it anymore. In the follow-up interview, he explained that he didn't create many proposals and couldn't get the design to match his brand.

At first, it sounded like he barely needed the product and found it awkward to use.

But the full story pointed somewhere else.

After seeing a beautiful proposal from another designer, Alex decided to update his brand. He wanted his proposals to carry the same design, so he tried to make it work in Bidsketch and ran into trouble. He switched to another tool and still could not get it right. For two months, he paid for both subscriptions. In the end, he used Word and spent a lot of time doing the design. He only canceled the Bidsketch subscription when he reviewed his quarterly expenses.

If he only wanted fewer steps, why spend so much time in Word?

He wanted a proposal that reflected his brand. The story suggests he wasn't unwilling to work. He was unwilling to keep paying without getting the result.

The difficulty he ran into was worth fixing. But simply helping him click fewer times and finish faster might not have addressed what he needed the design to do.

Ruben thought that showing existing custom templates during onboarding might have helped Alex implement the design. That's an improvement worth making: it helps a customer get the result they want.

But if a simpler process only gets him to a proposal he still dislikes, why would he renew?

A customer may truly be struggling to use the product. But when deciding what to change next, look beyond the clicks saved. Is the result they paid for actually within reach?

Ruben later wrote in a comment that products in this space only partly met expectations, and sometimes weren't serving the right customers. He said fundamental changes to the product and its positioning were needed.

When growth stalls, should you double down on higher-revenue customers?

Dan Liang — Tue, 03 Nov 2026 16:06:02 +0000

Suppose your small team sells a proposal tool. Independent consultants sign up and pay on their own, with little need for support. Agency customers take longer to close, but bring in more renewal revenue.

Growth has stalled. You're thinking of building more features for agencies and finding more customers like them. That's where next month's time and budget would go.

Forget the Funnel described research on Invoice Simple, an invoicing tool with plenty of signups and ongoing experiments, but too few signups becoming long-term customers. Their research found two needs. Some users simply wanted an invoicing tool. Others wanted to replace documents and spreadsheets and invoice from their phones on a job site.

According to Forget the Funnel, that second group had the highest lifetime value (LTV), even though it wasn't the easiest to convert.

Back to your proposal tool. Who accounts for that higher agency revenue?

If it mostly comes from one long-standing customer, look at what happened to the other agencies. Compare those that started paying around the same time. Include the ones that left, and give newer customers time to reach their renewal date. Then you can see whether several agencies keep renewing.

Similar renewal revenue can require very different workloads.

You might spend time connecting the tool to the first agency's existing workflow, then reuse much of that work for the next few. Or each agency might need a fresh setup and regular help from you. The setup and support records show how much work another customer adds.

Reusable work still costs money to build and maintain. Doing fresh work for each customer can be worthwhile too, if the fees cover it and your team can handle it. Look at the extra revenue alongside the extra work.

Where will the next agencies come from? The last few came through friends. Your sales records can show who else you can reach, and how much time and money it took to win a customer. That affects how much you can afford to spend next.

If several similar agencies keep renewing, you can handle their setup and support, and you have an affordable way to reach more, there's a case for putting more time and budget into that group. Weigh the longer sales process against what those customers bring in later.

If one old customer drives most of the revenue, and you're still unsure how much work the next one needs or where to find them, that case is weaker. Continuing the existing relationship and funding more development and sales for that customer group deserve separate decisions.

In a direction review, I compare payment, renewal, sales and support records for the same customer group. A high revenue total might come from several customers renewing at a service cost you can carry. Or one long-standing customer might account for most of it. Those records give you very different reasons to invest again.

That higher revenue is a reason to look more closely. To decide whether to find more customers like them, look at what it takes to win and serve more of them, and what you'd have left.

A fair price doesn't make a plan the right fit

Dan Liang — Mon, 02 Nov 2026 13:40:17 +0000

Your software has paying customers, but revenue hasn't grown in a while. You could work on SEO, improve the website, or revisit pricing. You only have the time and budget for one or two of those.

If you're considering pricing, first separate two jobs: changing the price of the existing plan, and designing a plan for teams. Those projects don't necessarily deserve the same priority.

A survey about the existing plan's price can inform the first decision. It doesn't answer whether teams need a different plan.

Revenue at Tom's Planner, a Gantt chart tool, had been flat for a few years. Growth consultancy DemandMaven worked with founder Tom to send a price sensitivity survey to more than 100 active users.

Tom said his pricing seemed to be in the right range. That gave him one less thing to consider.

Yet developing a team plan was still one of his priorities for the coming year. That work included both features and pricing.

A customer can be happy with what they pay to use a product on their own, then struggle to find a suitable plan when they want to bring in colleagues. Changing the price they pay today and designing a plan that works for their team are different pieces of work.

When reviewing a business that's stalled, I separate those decisions. Then I look at how customers use the product, what came up during purchase discussions, and why they didn't buy or renew. Those records help show which job deserves attention first.

Suppose individual users are renewing, but teams aren't buying. Some teams have tried the collaboration features and need them, but the minimum seat purchase is larger than they need.

If usage records, purchase discussions, and reasons for walking away repeatedly point to that issue, the team plan is worth investigating first. The question is how to offer those teams a suitable plan. It doesn't necessarily call for changing everyone's price.

But if teams aren't buying because the product doesn't support the way they need to work together, there's a feature gap to address. A lower price won't let them do work the product can't support. "Too expensive" alone doesn't tell you which problem you're dealing with.

The existing plan may be able to wait. Suppose your next round of work is still aimed mainly at the customers covered by the survey. Their purchase, renewal, and usage records don't suggest that price is preventing purchases or renewals. Another problem you've already identified is causing customers to leave. In that situation, a broad price change may not deserve to go first.

That doesn't make the current price optimal or rule out room to charge more. It means you don't yet have a strong enough reason to spend your limited capacity on a broad price change ahead of the other work.

You still need records from customers who left, people who never bought, and customers with a new use for the product. Without those, you can defer a broad price change. You haven't ruled out a pricing problem.

You might leave the current price alone while making the team plan a priority. Before deciding what comes next, be clear about the job: changing the price of an existing plan, or designing a suitable plan for teams?

More services. Still the same clients.

Dan Liang — Sun, 01 Nov 2026 12:54:47 +0000

Suppose you run a small web agency. Projects are ending, and new work hasn't come in. You're considering training the team to offer AI workflow services, starting with past clients.

It's a reasonable place to start. They know you. They've bought from you. What you learned about their businesses while building their websites may still be useful.

But what do you want that investment to buy? More work from existing clients, or revenue that no longer depends on just those few businesses?

That changes how much you can justify spending on the new service.

A Promethean Research interview roundup describes Fountain City's experience. Work from existing clients was expanding, while new-client acquisition received less attention. Then a major client of six years completed its digital transformation project. The engagement ended, leaving a substantial revenue gap.

Client projects end. Six years together doesn't mean another six years of work are waiting.

Back to the web agency. Suppose the AI service sells, mainly to the same clients. Revenue may recover. But if one client cuts its overall budget for outside services or stops working with you, both website and AI revenue may be affected.

More services. Still the same clients. You may earn more from them without gaining another group of clients.

If the revenue gap came from projects ending without new clients coming in, how much the new service can replace depends on the work those remaining clients can buy. When I review a stalled business, I look at project revenue alongside why the work ended. Can another project from the same client fill the gap, or do other clients need to replace that account?

A list of past website buyers can't answer that. An AI service needs current work to discuss, and the person buying it may not be the person who bought the website.

If that work exists, you can reach whoever buys it, the return after delivery costs and the additional investment is worthwhile, and someone can deliver it, expanding the relationship may make sense. It could even fill the immediate gap. You don't have to fix the whole old business first.

But restoring revenue from the same clients leaves you dependent on them. Selling those extra projects doesn't mean the next clients are lined up.

If you want the AI service to bring in new clients, you still need to work out where they are and how to enter their buying process. Training builds delivery capability. It hasn't built that route to new buyers.

With specific projects to discuss with existing clients, you can judge the training and delivery investment against that work. If you're counting on the service to replace ending projects over time, but have no route to new clients, you can't treat the whole expansion as if it already has a market.

Adding a service can be good business. Be clear whether you're investing in more work from existing clients or also giving the next clients a way in. Training isn't the whole cost of both.

Two weeks to ship. Then what?

Dan Liang — Sat, 31 Oct 2026 13:38:40 +0000

A new feature can be live in two weeks. After that, it still needs two days of maintenance and support every month. If it really brings in customers who are ready to pay, those two days may be worth it. The question is: who will do the work?

You've built the product. You've tried promotion. Revenue still isn't where you need it to be. Add features, redo the website, run ads—each option sounds reasonable. You only have the money and the people for one or two.

I've built game and blockchain projects myself, and I've felt how difficult product promotion can be. When several moves all look useful, the hard part isn't making a list. It's deciding where the next dollar goes.

That's when it's easy to compare only the visible cost: how long something takes and what it costs to launch.

Two weeks of development is easy to see. The two days every month don't end at launch. If you keep doing the work, that's six more days over the next three months.

Those days come out of the same calendar where you're already trying to meet potential customers. The feature may ship while the customer-acquisition problem stays exactly where it was.

Those six days belong in the cost. If suitable customers are willing to pay for the feature, and you can staff the ongoing support, it may be a good investment. A higher development cost doesn't automatically make it the worse choice.

But if the reasoning is only, “More features should make it easier to sell,” and you're the only person available to maintain them, “only two weeks” has left out the price. You can reduce the scope and make fewer promises. Or wait until the work has an owner. Whether the money should go to ads is a separate question.

Tom's Planner, a Gantt-chart planning product, offers a useful reminder. In a DemandMaven case study, its founder was looking at several growth opportunities while trying to keep the team small. He said he could put five things in motion at the same time, but then he would be trying to manage them for years to come.

Starting five things and carrying them for years are two very different demands on the same small team.

The same applies to a new channel. Opening an account or putting up a page can be quick. Continuing to write, follow up, and deliver on what you promised is work someone has to keep doing. Maintenance and operations aren't bad. Treating them as a problem for after launch is what makes an investment look cheaper than it is.

So the next time someone says, “It's cheap. We can have it done quickly,” I would ask one more question: what happens after it's done?

List the ongoing work. Decide who will own it and what it will displace. If nobody can carry it right now, shrink the plan or pause it. If someone can carry it and the customer benefit is worth it, ongoing work is not a reason to abandon the idea.

This still won't tell you whether the next dollar belongs in the product or in finding customers. It won't tell you whether the whole direction deserves to continue. It will keep one false bargain out of the comparison: something can be cheap to start and still have no one to carry it.

Orders Are Down. Should You Lower Your Hourly Rate?

Dan Liang — Fri, 30 Oct 2026 13:08:06 +0000

You charged 100 an hour. Now you're considering 80 because an empty calendar earns nothing.

A lower rate might bring work back. Fair enough.

In our work with founders whose businesses have stalled, we review decisions like this. Before changing it, I ask what the client means by “too expensive.”

Sometimes the project is worth doing and the budget is simply short. A lower rate may close that gap.

Sometimes the client has not decided whether the work is worth doing, or what the total bill will be. In that case, changing 100 to 80 does not explain what the hours will achieve or where the final bill may land.

If the concern is that the hours will keep expanding, clarify the scope, estimated hours, and deliverable before offering an even lower number.

The useful question: what specific piece of work is this lower rate meant to make more likely?

Fewer orders explain why you feel pressure to cut your rate. They do not, by themselves, give the client a reason to buy.

Industry data reflects the pressure. The 2026 Freelancer Study for the DACH region found that 9% of respondents planned to lower their hourly rate; among them, 61% cited a lack of orders. The study records an intention to cut rates; it does not show whether orders returned afterward.

Consider this. A client is ready to buy 10 hours of work and has an 800 budget. At 100 an hour, the quote is 1,000; at 80, about 800. If the scope, hours, and budget are real, the lower rate has a concrete reason to help close that deal. It still does not guarantee a signed contract or payment.

But getting the work and improving your income are different questions.

Suppose you used to sell 50 billable hours a month at 100, for 5,000 in revenue. Orders fall and you sell 40 hours, for 4,000.

If those 40 hours can still be billed at 100 and a new client buys 10 additional hours at 80, total revenue becomes 4,800. That may help.

If every new quote is now 80, selling 50 hours again produces only 4,000.

The workload came back. The revenue did not.

If the old-rate work has already disappeared, the 4,800 calculation no longer applies. To get back to 5,000 at 80 an hour, you would need to sell 62.5 hours. That is arithmetic, not proof that those hours exist, and it is before costs.

“Give me a lower rate and I’ll send you more work later” is not revenue. Scheduled or agreed hours is more concrete, but it still has to be delivered and paid for. A one-time discount can become the starting point for the next negotiation.

The market may genuinely have moved to a lower price. Then the service’s economics need another look. One discount will not fix a long-term lack of orders.

Lowering your rate is not automatically a step backward. When cash is tight, a lower-priced job can be worth taking.

The danger is dropping every quote before you can say what extra work the lower rate is meant to bring.

Why Aren't Potential Customers Replying to Your Emails?

Dan Liang — Thu, 29 Oct 2026 12:30:00 +0000

You've sent ten emails. Maybe more. No replies.

We hear this often when helping founders rethink a business that's stalled.

These people look like a good fit for your product. The company size is right, the work they do matches, and they seem to face the very problem you're trying to solve.

But the messages go out, and nothing comes back.

Send another, and you might become a nuisance. Walk away, and you wonder whether you're giving up too soon. Wait long enough, and even the product you believed in starts to look doubtful. Does anyone actually need it?

The hard part is wanting to change something without knowing what to change.

Hunter's 2026 report analyzed 31 million emails sent by its users in 2025. The average reply rate for initial emails in that sample was about 3%. Ten unanswered emails aren't enough to conclude that something is wrong with the product.

A message can go unseen. An address can be wrong. Bounces and messages sent to the wrong person are worth checking first. But even if the email arrived and they read it, the question remains: they have this problem, so why aren't they responding?

The same problem can mean different work

Say you've built a tool that automatically follows up on overdue invoices for independent consultants. Fewer payment dates to remember. Fewer reminders to write. It sounds useful.

Contacting consultants who've been paid late makes sense.

But "chasing payment" can mean very different things in someone's working day.

One consultant occasionally gets paid late. An email usually sorts it out. It's annoying, but not annoying enough to justify setting up another tool. A spreadsheet, calendar and inbox do the job well enough.

Another can't collect the final payment because the client says the last round of revisions isn't finished. They need to agree on whether the work is complete. An automated reminder can arrive right on time without bringing the money any closer.

A third is short on cash. They need to find whoever can authorize payment and establish whether it will arrive this week. "Spend less time chasing invoices in future" and "Will this money arrive by Friday?" carry very different weight right now.

All three might agree that chasing payment is a pain. The same invoice tool would be useful to them in very different ways, if at all.

This is where the mismatch can begin. We describe their need as "late payment." They are dealing with forgotten invoices, disputed work or a payment waiting for approval.

We haven't invented the need. We've treated several different problems as one.

Even knowing that someone is under pressure doesn't close that gap. Urgency can push someone to look for a new approach. It can also leave them with no room to evaluate one while they deal with the immediate problem. What matters is which piece of work we can actually help move forward.

So an unanswered email may have more behind it than unconvincing copy. The recipient may not see how this conversation connects to what they're trying to get done.

What can the next email say?

If all we know is that they're an independent consultant, we don't yet know which payment, if any, they're worried about. We can keep exploring. The next conversation could be about where payments tend to get stuck, without assuming that automated reminders are what they need most.

If they've recently written publicly about checking invoices one by one and sending reminders every month, we have a specific use for automation to discuss. The next message can pick up that piece of work without introducing the whole product again.

If we've already spoken, they asked for a proposal and we agreed to talk on Friday, silence on Monday is different again. We can follow up on that agreement. They may have missed the message, or their plans may have changed. A reminder can serve a purpose without a new feature or discovery attached.

We don't know who will reply in any of these situations. But what we already know does change what the next message can reasonably say.

And having something relevant to say still doesn't guarantee an answer. A clear no means we stop. Repeated silence, with nothing specific left to pursue, can be a reason to put our time into other conversations. A reply or a change in circumstances can give us a reason to return.

Putting one conversation aside doesn't require us to write off the product.

We've spent a lot of time building something. Of course we want people with the problem to hear us out. That urgency is understandable.

But they may be trying to collect a disputed final payment while we keep explaining how to send fewer reminder emails. Both sides are taking their work seriously. We just haven't found the same thing to talk about yet.

Before sending another email, I'd want to understand where that payment is stuck.

Where Do You Find Your First Customers?

Dan Liang — Tue, 27 Oct 2026 13:27:58 +0000

You know roughly who your product is for.

Developers. Agencies. Small-business owners.

Ask where to find them and someone says LinkedIn. Someone else says Reddit. Now you have another platform to search. You still don't know who to approach.

A customer description gives you a group. The work those people are trying to finish can give you somewhere to look.

A question that led to a customer

In a Mixergy interview, Zapier co-founder Wade Foster explained how he found Andrew Warner, who became the company's first customer.

Foster was looking for people who needed help connecting software. He came across a question Warner had posted on Web Applications Stack Exchange:

"How can I auto-import contacts from PayPal into Highrise?"

PayPal had his customers' addresses. He wanted them in Highrise, his contact-management software.

A person. Two tools. A job he was struggling to finish. Foster had something concrete to follow.

By the time Foster got in touch, Warner no longer needed that particular integration. Their conversation uncovered a related need: moving email addresses from a Wufoo form into AWeber, his email-marketing tool.

The question helped Foster find him. The conversation established what he still needed.

What would you look for in your market?

Say you offer returns automation for small online stores.

Search for "small online-store owners" and you can collect plenty of profiles. Which one do you approach? Why that one?

Ask how stores handle returns today, and the search has somewhere to go.

An operator may be discussing refunds in a support-tool community. That gives you a discussion to read and, where appropriate, contribute to.
An order-management consultant may show the kinds of stores they serve. That helps you learn which businesses do this work and who already helps them.
An industry event about returns may offer a way to meet practitioners.

You can explain why you're looking in each place. That's already better than trying another platform because the last one disappointed you.

A name still leaves questions

Of course, you have to check what you find. The discussion may be old. The group may be full of other sellers. The person doing the work may have no authority to buy.

Finding someone isn't permission to pitch. You can listen or contribute in a community without treating its member list as an invitation to send automated messages. A service provider isn't automatically a referral partner.

You've found a possible way in. Whether contact is welcome, and whether the person needs what you offer, still need checking.

Give yourself something to look for

Look at your customer description. If all it gives you is an industry or a job title, add a piece of work that person is trying to finish.

What do they use? Where do they ask for help? Who already works alongside them? Follow a connection that could lead to an actual person.

Sometimes the work leaves little public trace. An introduction, an industry association or an in-person event may be the sensible route. Finding that out beats another week of switching platforms without knowing why.

Your first customers may never gather in one room marked "your market."

Look at what they're trying to get done. The work can tell you where to look.

They have the problem. So why won't they give you feedback?

Dan Liang — Mon, 26 Oct 2026 12:30:00 +0000

You send out invitation after invitation, asking potential customers for feedback. Not a single reply.

You need feedback before spending another month on the product. Do you change how you reach people, or go back and change the product?

"Could you take a look and give me some feedback?"

A small favor. At least, that's how it sounds when you're asking.

But a useful answer can mean learning an unfamiliar tool, explaining how they work today, then figuring out what you should change. You're asking them to help shape a product you hope to sell them.

That is a lot to pack into "take a look."

Your product might save them time later. Giving you feedback costs them time now.

Someone can be drowning in admin and still have no appetite for another tool to evaluate. Their problem is urgent. Helping you doesn't automatically join the queue.

The conversation needs a reason of its own.

Suppose you're building a tool for agencies that spend too long chasing client approvals. Come prepared to discuss a tradeoff: keep reviews in email, where clients already work, or move them into a portal that collects comments in one place but gives clients another place to check.

Now there's something for an agency owner to think through about their own business, whether or not they ever buy your tool.

And yes, you still want to learn from them. Say so. But do some of the thinking before asking them to do theirs. Give them something worth discussing.

Before treating silence as a verdict on the product, look at what you asked them to take on. Another feature may leave that request exactly as it was.

Your need for answers is real. It isn't their reason to say yes.