Asher's Blog

When you are building for businesses, how do you discover what customers value enough to pay for?

The simplest answer is: ask them.

Talk to your customers, listen carefully and allow them to explain what is happening inside their organisations. Yet that answer is only the beginning, because customers do not always express value in a neat sentence, and what they say they want is not always what they will ultimately buy. If you want to understand value deeply, you have to observe their behaviour, examine the workarounds they already tolerate, identify the consequence of the problem and discover who inside the company has both the motivation and authority to spend money on solving it.

In B2B, value often hides inside a process. It may be the hours a finance team spends reconciling transactions, the anxiety before a regulatory deadline, the revenue lost because sales information is fragmented, the reputational damage caused by paying employees late or the executive time consumed by approving work that should be automatic. The customer may initially ask for a feature, but the thing worth paying for is usually the business outcome behind that feature.

Your job is not merely to collect requests. Your job is to understand the customer’s reality well enough to connect your product to an outcome that matters.

Asking is useful, but listening is the real work

Founders frequently say they talk to customers, but many customer conversations are disguised sales presentations. The founder explains the product, lists the features, talks about the vision and then asks, “Would this be useful to you?” The customer, trying to be polite, says yes. Everybody leaves encouraged, but very little has been learned.

A useful customer conversation should contain far more listening than explaining. Ask the customer to describe the last time the problem occurred. What were they trying to do? Who was involved? Which systems did they use? Where did the process slow down? What went wrong? What did the failure cost? Who noticed? What did they do afterward? How frequently does the problem return?

Questions about actual events are more reliable than questions about an imaginary future. “Would you pay for an automated compliance platform?” invites speculation. “Walk me through what happened the last time you filed this return, including the people, time and external costs involved,” produces evidence.

Rob Fitzpatrick’s The Mom Test became popular among founders because it makes this distinction clearly: even someone who loves you may give encouraging but commercially useless feedback, so the conversation should focus on the person’s life, past behaviour and real problems rather than asking for approval of your idea. The principle is especially valuable in B2B, where courtesy, procurement language and organisational politics can make weak demand sound stronger than it is.

Do not ask only whether customers like the product. Listen for what they have already tried, what they have already paid for and what they are unable to ignore.

Go to the customer’s office and watch the work happen

One of the best things a founder can do is to sit with customers and watch them use the product in their real environment. I try to do this as often as possible—ideally at least once or twice a month—because a screen recording or analytics dashboard cannot reveal everything that becomes visible in the room.

When you sit beside a customer, you see the sequence in which the work actually happens. You see the spreadsheet opened before your product, the WhatsApp message required to obtain missing information, the colleague called to confirm a number and the paper file kept because nobody completely trusts the digital record. You notice where the user hesitates, which label is misunderstood, what they write down separately and which feature they ignore despite your team believing it is important.

You also hear the surrounding conversation. Someone complains about a deadline. A manager asks why a report is late. An employee mentions that the same data must be entered into three systems. Those comments may not be direct feedback about your product, but they reveal the larger job the organisation is attempting to complete.

This form of observation is close to what researchers call contextual inquiry: learning from users in the context where the work is performed. The official Value Proposition Canvas similarly encourages companies to map what customers are trying to accomplish, what obstructs them and what outcomes they want, rather than beginning with a catalogue of features.

The important word is context. A customer does not experience your product in isolation. They experience it inside an organisation with existing tools, authority structures, deadlines, habits, fears and incentives. If your product does not fit that context—or improve it enough to justify changing it—the customer may appreciate the idea and still refuse to buy.

Watch what they do, not only what they request

Product usage can tell you where value is being created, although usage data must be interpreted carefully. A frequently used feature may be valuable, or it may simply be compulsory. A rarely used feature may be irrelevant, or it may solve a high-stakes problem that occurs once a quarter. The founder needs both quantitative evidence and customer context.

Before changing pricing, study how different customers use the product. Which workflows are completed most consistently? Which features correlate with renewal? Which capabilities are heavily used by the customers with the highest retention? Where do customers invite colleagues or export reports? Which events cause support requests? What happens in the weeks before a customer churns?

Then speak with the customer about what the data appears to show. You may discover that the value is not where your marketing says it is. Your team may promote speed while customers care more about accuracy. You may emphasise automation while the economic buyer cares about auditability. You may celebrate a broad collection of features while the customer renews because one recurring task no longer creates anxiety.

When usage and conversation point to the same outcome, you have a much stronger signal of value.

This is one reason founders should remain close to customers even after hiring sales, product and customer-success teams. Those functions can multiply learning, but they also filter it. Sales may emphasise what helps close a deal. Support sees what breaks. Product hears feature requests. Finance sees discounts and collections. The founder needs a way to connect these fragments into an understanding of what customers truly value.

Find the business consequence behind the complaint

Businesses do not usually pay because a problem is annoying. They pay because the problem affects money, risk, time, reputation, control or strategic opportunity.

A slow process becomes commercially important when it delays revenue or requires additional staff. An error becomes valuable to prevent when it creates penalties, refunds or lost trust. Poor visibility becomes urgent when an executive cannot make a decision. An unpleasant interface may not justify a purchase by itself, but if it causes employees to avoid a critical system, data quality and compliance may deteriorate.

I find it useful to translate customer problems into a few categories of value:

• Does the product increase revenue or make revenue arrive sooner?
• Does it reduce cost, manual effort or the need for additional headcount?
• Does it reduce the probability or consequence of fraud, error, penalties or business interruption?
• Does it save senior people time or improve the speed and quality of decisions?
• Does it increase trust among customers, employees, regulators or partners?
• Does it create a capability the company could not reasonably build on its own?

The strongest value propositions often combine several. A payroll and compliance product, for example, may reduce administrative time, lower the risk of remittance errors, produce clearer records and protect employee trust. The customer is not buying “a payroll button.” The customer is buying certainty around a sensitive responsibility.

Michael Skok has described the strongest B2B opportunities as problems that are both blatant and critical: the customer recognises the problem, and failure to solve it obstructs the business or puts money, reputation or careers at risk. That is a useful standard. A latent problem may be real, but selling it requires first convincing the customer that the problem exists. An aspirational improvement may be desirable, but it will be the first item removed when budgets tighten.

The closer your product sits to an acknowledged and consequential problem, the clearer the willingness to pay becomes.

Identify the user, buyer and person carrying the risk

B2B value is complicated because “the customer” is usually several people.

The daily user may be an HR officer, accountant, operations manager or analyst. The economic buyer may be a chief executive, finance director or department head. Procurement may negotiate the price. Information security may determine whether the product is allowed. Legal and compliance may impose conditions. An executive sponsor may defend the purchase internally, while employees who never selected the product must live with it every day.

Each person experiences value differently. The user wants the work to become easier and faster. The executive wants a measurable outcome and confidence that the organisation is under control. Finance wants a justifiable return. IT wants security and compatibility. Procurement wants credible terms and reduced vendor risk.

If you speak only to the user, you may build something people enjoy but nobody can approve. If you speak only to the executive, you may sell a powerful story that employees refuse to adopt. If you ignore security or procurement, a deal that appears finished can remain stalled for months.

Customer discovery should therefore map the buying group. Who first feels the pain? Who searches for a solution? Who controls the budget? Who can block implementation? Who will be blamed if the problem remains? Who benefits personally or professionally when the solution succeeds?

The last two questions are especially important. Organisations make rational decisions through human beings who also care about reputation, workload, career risk and trust. A product may create obvious value for the company while making the internal champion feel exposed. If implementation fails, who pays the reputational price? Your sales and onboarding process must reduce that risk.

Study what customers already pay—even when it is not called software

Customers reveal willingness to pay through their current workaround. They may employ staff to perform the task manually, hire consultants, pay penalties, maintain several tools, carry excess inventory or accept revenue leakage. Those costs create an economic baseline against which your product can be evaluated.

Suppose a company says it will not pay ₦500,000 annually for software, but the same problem consumes one employee’s week every month, requires an external adviser and produces recurring errors. The customer may not yet understand the total cost of the current process. Your job is not to manipulate the numbers; it is to help the organisation calculate them honestly.

Include direct and indirect costs. Direct costs are salaries, vendor fees, penalties, refunds and infrastructure. Indirect costs include executive attention, delayed decisions, employee frustration, customer distrust and opportunities abandoned because the company lacks reliable information.

Not every benefit can be converted perfectly into money, but a commercial case becomes stronger when the customer can explain why the purchase is better than maintaining the status quo.

The status quo is often your real competitor. A spreadsheet, WhatsApp group, manual employee, accountant or familiar inconvenience may be harder to replace than another software company because it carries no new procurement process and feels psychologically free. Your product must create enough additional value to overcome both the visible price and the invisible cost of change.

Do not ask customers to set your price for you

Asking customers is important, but “How much would you pay for this?” is often a weak pricing method. Customers have an incentive to suggest a low number, may not know the budget, and may answer differently when no real purchase is required. A hypothetical willingness to pay is softer evidence than an approved invoice.

Instead, use the conversation to understand value and constraints. What does the current process cost? Which budget would fund the purchase? What alternatives are being considered? What approval is required at different price levels? What return would make the decision easy to defend? Is the price small relative to the avoided loss or expected gain?

Then present a real offer. State the price, scope, implementation requirements and outcome. Ask for commitment. The response will teach you more than another round of abstract praise.

Price discovery is a sequence of tests. You may offer different packages to comparable segments, examine conversion and retention, and learn which value metric feels fair. A value metric is the unit through which price grows: employees managed, transactions processed, locations, users, revenue, assets or another measure connected to the benefit received.

The best metric is understandable, measurable and aligned with value. If customers receive more benefit as the metric increases, higher pricing feels like participation in their growth. If price grows with a number customers do not associate with value, the model creates resentment or encourages avoidance.

Do not confuse a discount with discovery. A customer may buy because the product is unusually cheap, but that does not prove the full-priced proposition works. Record discounts, the reasons for them and the conditions under which they expire. Otherwise temporary concessions quietly become the business model.

Listen to objections without surrendering your economics

Pricing feedback contains information, but not every complaint about price means the price is wrong.

“This is too expensive” can mean several things. The customer may not experience the problem strongly enough. The buyer may not understand the value. The product may lack a requirement necessary for adoption. The wrong segment may have been targeted. The budget cycle may be closed. The internal champion may lack authority. The customer may simply be negotiating.

Ask what the objection means. Compared with what is the product expensive? What outcome would justify the price? Which part of the business case is unconvincing? Would a different scope solve the problem, or would the customer still not buy at half the price?

Sometimes the correct response is to reduce price. Sometimes it is to improve the product, change packaging, demonstrate the value more clearly or walk away from a customer who will be expensive to serve and unwilling to pay sustainably.

A founder should not use “listening to customers” as an excuse to build an unprofitable company. The customer’s responsibility is to protect the customer’s economics; yours is to create a transaction that works for both sides.

Do not let competitors define value for you

Competitors are worth studying. Their positioning, prices, customer base and product choices can reveal how the category is evolving. Ignoring them completely would be careless. Being controlled by them is equally dangerous.

A competitor may be underpricing to acquire market share, subsidising the product with capital or serving a different segment. It may be copying popular features without understanding which ones drive retention. It may appear successful publicly while experiencing poor economics privately. If you follow every competitor announcement, your roadmap becomes a delayed version of somebody else’s assumptions.

The customer should remain your primary source of truth. Ask whether the competitor solves the customer’s problem better, not whether it has a longer feature list. A feature only matters if it improves an outcome customers value. A lower price only matters if the alternative can deliver the required trust, reliability and support.

There is also value in differentiation. When all competitors build the same product, the category becomes a price comparison. Deep customer understanding allows you to solve a more important layer of the problem and explain why your approach is different.

Focus on the customer’s work, not the competitor’s press release.

Build a customer-learning system, not occasional conversations

Customer discovery should not depend entirely on the founder remembering to arrange a visit. As the company grows, learning needs a rhythm.

Set a regular target for customer observation and interviews. Include different segments: new customers, long-term customers, highly engaged users, customers who use only one feature, customers who recently expanded and customers who churned. Record the context, not merely a list of requests. Connect qualitative themes with usage, support, retention and financial data.

Product, sales, customer success, support, finance and marketing should share what they are learning. A recurring complaint seen by support may explain a churn pattern in the data. A sales objection may reveal weak positioning rather than a missing feature. A finance discussion about discounts may expose that one segment does not value the product sufficiently.

Close the loop with customers. When their feedback leads to a change, tell them. When you decide not to build a request, explain the broader problem you are solving. Customers who see that the company listens thoughtfully are more likely to continue contributing useful insight.

The founder should continue to participate personally. A monthly or twice-monthly visit can prevent the executive team from becoming separated from the work customers actually do. Nothing replaces watching a user struggle with a flow your internal team described as simple.

A practical B2B value test

Before concluding that a customer values something enough to pay for it, I would look for evidence across five levels.

First, the problem is real and recent. The customer can describe an actual occurrence rather than merely agreeing with a general statement.

Second, the consequence is meaningful. The problem affects revenue, cost, time, risk, trust, control or a strategic outcome.

Third, the organisation already attempts to solve it. Existing labour, software, advisers or workarounds demonstrate priority.

Fourth, the buying group is understood. You know the user, economic buyer, internal champion, blockers and approval process.

Fifth, the customer accepts a real exchange. They commit time to implementation, provide data, sign an agreement or pay. Commercial commitment is the clearest evidence that the value has moved beyond conversation.

Usage and renewal then complete the proof. A signed contract shows the promise was persuasive. Adoption shows the product fits the work. Renewal shows the value survived experience.

Value is what changes for the customer

The question is not ultimately, “Which feature can we charge for?” It is, “What becomes better in the customer’s business because we exist?”

Ask customers, but do not ask only for opinions about your idea. Listen to the story of their work. Sit in their office and watch the process. Notice the spreadsheets, calls, approvals, frustrations and moments of anxiety surrounding the product. Study actual usage. Find the economic and emotional consequence behind the feature request. Understand who uses, who pays, who can block and who carries the risk.

Then quantify the value, design a real offer and ask the customer to commit. Do not allow competitors to dictate what you build or how you price when they may be solving a different problem—or solving the same problem badly. Let your customers’ reality remain the source of truth, while your own economics determine whether the exchange can become a durable business.

When customers value a product enough to pay for it, they are rarely paying for the software itself. They are paying for the time returned, the loss prevented, the revenue enabled, the control restored or the worry removed.

Discover that outcome, build more deliberately around it, and tell its story clearly. That is how a B2B product stops being a collection of useful features and becomes something a business considers necessary.