Identify the Pain Customers Already Pay to Remove

Task

Identify the repeated pain customers already pay you to solve.

Summary

Find the recurring problem supported by actual customer and project evidence.

Find the Problem Customers Already Pay You to Solve

Task ID: S1-03

A consulting-led company often appears to serve many different needs because every proposal and project is described differently. This article explains how to examine paid customer work, identify the problem that recurs beneath the custom language, test whether the pattern is commercially meaningful, and produce evidence strong enough to guide a repeatable offer or product decision.

The problem hiding inside custom work

A founder opens the project archive and sees twenty different statements of work.

One customer bought an assessment. Another hired the company to fix a workflow. A third wanted an integration. A fourth asked for reporting, training, or ongoing support. The invoices have been paid, the work has been delivered, and customers appear satisfied. Yet nobody can answer a basic question:

What problem do customers repeatedly pay this company to solve?

This uncertainty is common in founder-led service businesses. Customers arrive through referrals and warm relationships. The founder adapts the sales conversation to each buyer. Proposals reflect the customer’s vocabulary. Delivery teams solve whatever stands between the customer and the desired result. Over time, the company accumulates revenue without accumulating a clear, shared definition of what it sells.

The operating principle is simple:

Do not begin by asking what the company wants to package or build. Begin by finding the customer problem that has already caused several buyers to spend money.

That requires more than collecting compliments or feature requests. It means examining past sales, delivery, support, and financial records to find a repeated combination of:

• a recognizable type of customer;
• a situation that makes action necessary;
• a problem the customer experiences;
• a result the customer expects;
• a purchase or other meaningful commitment;
• work the company can credibly perform again.

Customer research guidance from the UK government similarly recommends starting with evidence about what users are trying to accomplish, how they currently do it, where they encounter problems, and what they need to reach the right outcome. It advises teams to combine existing operational evidence with interviews and observation, and to treat internal opinions as assumptions until customer evidence supports them.

This task comes before designing a standard package, setting a scalable price, or deciding what software to build. A company that skips it risks standardizing the wrong work. It may turn an incidental project activity into the centre of the offer, confuse a frequently requested feature with a valuable problem, or build software around a process that customers do not value independently.

Research on service productization supports the importance of this sequence. Studies describe productization as the work of making services more understandable, repeatable, measurable, and manageable across the offering, delivery processes, people, information, and technology. That improvement depends on knowing which customer need the service is meant to address; standardization alone does not create value.

The goal, therefore, is not to prove that every customer is identical. It is to determine whether one customer group, one important problem, and one expected result appear often enough—and with strong enough payment evidence—to justify further focus.

What counts as evidence

A customer saying, “That sounds useful,” is evidence of interest. It is not evidence of purchase.

A customer asking for a feature is evidence that the feature matters in that conversation. It is not yet evidence that the customer will pay for it separately.

A signed contract is stronger. It shows that the customer accepted a real tradeoff involving money, time, risk, procurement effort, or internal credibility. Even then, the contract may cover several problems at once, so the analyst must determine which problem actually drove the decision.

This distinction matters because hypothetical answers regularly differ from real economic behaviour. A 2020 meta-analysis covering 77 studies reported in 47 papers found that hypothetical estimates of willingness to pay were, on average, about 21% different from real willingness to pay. The size of the difference varied by product, research method, value, and study design, but the broader lesson is durable: stated enthusiasm should not be treated as equivalent to a purchase made under real constraints.

For this task, existing paid work is especially valuable because it records revealed behaviour. The customer had alternatives: postpone the work, use employees, hire another provider, buy software, accept the problem, or do nothing. The customer nevertheless made a commitment.

Payment is not conclusive proof that every part of the project was valuable. It is evidence that something in the situation justified action.

A useful evidence hierarchy looks like this:

The strongest initial pattern usually combines several forms of evidence. For example, ten customers may have paid for projects containing the same problem, seven may have described the same trigger, five may have returned for related work, and four may have documented the business result. That is more informative than ten unqualified mentions in call notes.

Evidence should also come from more than one internal system. The National Institute of Standards and Technology’s Baldrige guidance recommends examining customer satisfaction and dissatisfaction, retention and account losses, complaints, perceived value, ease of use, referrals, and related customer results rather than relying on a single measure.

For a consulting-led company, useful sources commonly include:

Customer complaints and support records should not be dismissed as operational noise. Research has shown that systematic analysis of complaints can expose customer requirements that are difficult to see through manager judgment alone. One study combined text analysis with a job-focused method and found needs that subject-matter experts had not initially identified. Recent work has also found that later reviews, written after customers have used a product for some time, can reveal requirements and changes in satisfaction that are absent from initial reviews.

The practical conclusion is that evidence must retain its source. A claim such as “customers struggle with reporting” is too weak unless the team can trace it back to the customers, projects, statements, purchases, and results that support it.

How to examine the customer and project records

The analysis should turn an archive of differently worded projects into a comparable set of records without erasing meaningful differences.

The process can be summarized as follows:

flowchart LR
    A[Paid customer and project records] --> B[Extract customer, trigger, pain, purchase, and result]
    B --> C[Code recurring patterns]
    C --> D{Same pain across distinct customers?}
    D -->|Yes| E[Check urgency, payment, results, and delivery fit]
    D -->|No| F[Split the segment or gather more evidence]
    E --> G[Write the problem statement and evidence map]
    G --> H{Strong enough to build around?}
    H -->|Yes| I[Use it to shape the repeatable offer]
    H -->|Not yet| F

In plain language: collect the records, extract the same facts from each one, group similar pains, test whether the group contains independent customers and meaningful purchases, then decide whether the evidence supports a focused problem statement.

Define the unit of evidence before counting

The team must decide whether a proof point represents a customer, a project, a contract, or an invoice.

For strategic decisions, distinct paying customers should usually be the primary unit. Project frequency can be a secondary measure.

Suppose one customer has six change orders concerning the same issue. Those records show repeated work and may indicate expansion, but they do not demonstrate that six independent customers share the pain. Count them as:

• one customer-level proof point;
• six project or transaction occurrences;
• one source of evidence about recurrence within an account.

This preserves useful information without inflating market confidence.

The eligible record set should also be defined in advance. It might include all completed paid projects from the last two years, all active customers in a particular segment, or every project sold through the founder-led channel since a major change in the company’s offer. The right period depends on sales cycle, market change, and data quality. Older projects can be included as a comparison, but patterns that no longer drive current purchases should not dominate the conclusion.

Build one comparable evidence register

Each customer or project should receive a row in a structured register. A practical version includes:

The first pass should preserve the customer’s wording. Do not immediately translate “we cannot close the month without three days of manual reconciliation” into a broad label such as “inefficient reporting.” The broader code is useful later, but the original statement contains the job, consequence, timing, and process constraint.

Separate the problem from the requested solution

Customers often describe solutions rather than problems:

• “We need a dashboard.”
• “We need an artificial intelligence assistant.”
• “We need an integration.”
• “We need training.”
• “We need someone to manage this for us.”

The analysis should ask what would remain painful if that requested solution did not exist.

A dashboard request may mean leaders cannot answer urgent questions. An integration request may mean employees are repeatedly copying information and making errors. A training request may mean the current process depends on one person. Different requested solutions can therefore point to the same underlying problem.

Conversely, identical requests can conceal different problems. Two customers may both ask for a dashboard, but one needs regulatory evidence while the other needs sales forecasting. Combining them merely because the deliverable looks similar would create a false pattern.

The problem code should describe the customer’s failed or threatened outcome, not the company’s activity.

Code before ranking

After the records are extracted, group similar pains into provisional codes. Keep the first set of codes relatively specific. For example:

• cannot produce an accurate report before the executive meeting;
• customer onboarding takes too long because data must be re-entered;
• security evidence is scattered when an enterprise buyer requests it;
• project status depends on the founder answering questions;
• employees cannot complete a recurring task without manual intervention.

Only combine codes when the customers, trigger, consequence, and desired result are materially similar.

Where possible, a second person should review the coding. Independent review does not remove judgment, but it exposes categories that reflect the founder’s preferred solution rather than the records. Qualitative research commonly uses documented coding procedures and comparison across interviews to improve transparency and reduce unsupported interpretation.

The team should also search deliberately for contrary cases. If eight customers paid to speed up onboarding but two rejected the company because they needed deeper customization, those two cases help define the boundary of the problem and the likely target segment.

Write the problem statement after the pattern is visible

A useful problem statement identifies the buyer, the failed or threatened outcome, and the constraint that causes the difficulty:

[Buyer or user] struggles to [achieve or avoid a specific result] when [trigger or situation] because [current constraint], leading to [material consequence].

For example:

Operations leaders at growing professional-services firms struggle to produce reliable project-margin reports before monthly reviews because delivery and financial data sit in separate systems, leading to manual reconciliation, delayed decisions, and low confidence in the numbers.

This is stronger than “customers need better reporting.” It tells the company whom to look for, when the problem becomes urgent, what the customer wants to accomplish, and why the current approach fails.

The statement should be followed by the records that support it. It is a conclusion from evidence, not a replacement for evidence.

How much evidence is enough

The working target of at least ten proof points is a useful starting checkpoint, not a universal law.

Qualitative research offers a helpful analogy. In one methodological study of twenty-five interviews, researchers identified the broad range of recurring topics after nine interviews, but needed sixteen to twenty-four interviews to understand the meanings, differences, and nuances behind those topics. A wider review likewise concluded that sample sufficiency depends on the research purpose, population, sampling strategy, analytical depth, and richness of the data—not merely on reaching a standard number.

That research does not establish that ten customer projects prove a market. Customer-record analysis is not identical to an academic interview study. It does, however, explain why ten can be a sensible first review point:

• it is large enough to expose obvious repetition in a reasonably focused customer group;
• it is small enough for a leadership team to inspect each record closely;
• it can indicate whether a code is recurring or merely memorable;
• it forces the company to move beyond one or two favourite customers.

Ten weak, duplicated, or poorly documented records may provide less confidence than six independent purchases with clear triggers, buyer language, pricing, and outcomes. Twenty mixed records from unrelated customer groups may obscure rather than clarify the pattern.

A credible proof point should therefore meet most of these conditions:

The primary measure is pain frequency, but it should be reported in more than one way.

A basic customer-level calculation is:

A project-level calculation is:

The distinction matters. Customer-level frequency indicates breadth. Project-level frequency shows how often the work appears, including recurring work within the same account.

Pain frequency should be accompanied by several contextual measures:

Revenue should not replace frequency. One large project can dominate revenue while representing an unusual need. Frequency should not replace value either. A common pain may be too minor to command an attractive price.

The practical decision requires both dimensions: enough buyers experience the problem, and solving it matters enough for the economics to work.

Evidence quality should also be shown explicitly. A simple evidence map can separate facts from interpretation:

This format prevents a confident narrative from outrunning the records.

A public example and the limits of analogy

Basecamp offers a clear example of a company noticing a recurring problem inside client work.

The business began as a web-design firm. As its number of projects increased, the team struggled to manage client communication and project information with its existing methods. It built an internal system to solve that problem. According to the company’s account, clients began asking what the system was and whether they could use it for their own projects. Basecamp was then prepared as a commercial product, and roughly a year after release it was generating more revenue than the firm’s web-design work. Independent reporting has similarly described the product as originating in the internal system the firm used to manage client communication.

The useful lesson is not “build the internal tool you use.” Many internal tools solve problems that no outside buyer values enough to purchase.

The stronger evidence in the Basecamp story was the combination of signals:

• the problem repeatedly affected real project work;
• the firm experienced the problem directly;
• clients saw the system in use;
• clients asked to use it themselves;
• the team converted that interest into a paid product;
• product revenue eventually justified a change in business focus.

The customer’s paid problem was not “we need the same software used by our design agency.” It was the broader difficulty of keeping project information, communication, tasks, and client work organized.

That distinction matters when analysing consulting records. The repeated internal activity is not necessarily the product opportunity. A team may repeatedly clean data, configure systems, interview employees, or prepare reports. Those are delivery activities. The valuable problem is what the customer cannot accomplish without that work.

The example also illustrates why a repeated pain should be connected to a defined customer group. Basecamp’s experience came from project-based collaboration, not from every form of organizational work. The initial evidence supported a focused use case; broader adoption came later.

Productization research warns against assuming that full standardization is always desirable. Standardized and modular services can improve consistency, measurability, setup time, sales clarity, and cost control, but excessive standardization may fail to accommodate important customer differences. The purpose of this task is therefore not to eliminate variation. It is to determine which part of the customer problem should remain stable while allowing deliberate variation around it.

What good work leaves behind

This task is complete when the company has more than a workshop conclusion or a phrase on a slide. It should leave behind a reviewable set of evidence that another employee can inspect and challenge.

The core deliverable is a problem statement supported by an evidence register containing at least ten credible customer or project proof points where the available records permit it. The ten-point target should be treated as an initial confidence threshold. A company serving a narrow market with large, infrequent contracts may need to proceed with fewer but richer cases. A company with hundreds of small transactions should normally examine a larger set and use quantitative records alongside interviews.

A credible completion package contains:

The work often looks complete before it is. Common false finishes include:

Counting the same customer repeatedly. Five projects for one loyal client show account depth, not five-customer market breadth.

Grouping work by deliverable. Ten dashboards do not prove one pain unless the buyers, triggers, consequences, and desired results are similar.

Using the founder’s summary instead of the customer’s language. The founder may accurately remember the technical work but misremember which business consequence made the customer buy.

Treating revenue as the only signal. A single exceptional contract can make a rare problem appear strategic.

Treating frequency as the only signal. A frequent nuisance may not justify an attractive price or urgent buying process.

Ignoring the alternative. A pain is commercially stronger when customers already spend money, labour, executive attention, or risk to manage it.

Combining different segments too early. A security leader at a regulated enterprise and an owner of a ten-person agency may use similar words while facing different consequences, budgets, and buying processes.

Recording the solution but not the result. “Implemented an integration” does not explain whether the customer wanted faster onboarding, fewer errors, regulatory evidence, or lower labour cost.

Excluding negative cases. Lost opportunities, disappointed customers, and projects with poor margins help define where the apparent pattern does not hold.

Using artificial intelligence as the decision-maker. Software can search, summarize, and suggest clusters, but it can also merge materially different customer situations. People who understand the sale and delivery must review the source evidence and resolve ambiguous classifications. Recent research supports the use of text analysis for identifying themes in complaints and reviews, but those methods still require sound source selection, interpretation, and validation.

Before the company depends on the result, the leadership team should be able to answer six questions without changing definitions halfway through:

1. Which customers experience the problem most clearly?
2. What event makes them act?
3. How do they describe the problem in their own words?
4. What have they already paid the company—or someone else—to do about it?
5. What result do they expect, and what evidence shows that result is achievable?
6. Which records do not fit, and what do those exceptions reveal?

When the answers converge, the company can make a grounded decision. It may decide that one repeated pain is strong enough to shape a standard offer. It may discover two different problems that must not be combined. It may find that the apparent pattern belongs to one unusually important client. Or it may conclude that the evidence is too thin and further customer research is required.

Each of those is a useful result.

The task succeeds when the company stops saying, “We can do many things for many customers,” and can instead state, with traceable evidence:

This type of customer repeatedly encounters this problem in this situation, pays for help because the consequence matters, and expects this result. We have solved it often enough—and consistently enough—to decide whether to build around it.

Sources

Primary and official sources

• UK Government Service Manual, “Learning About Users and Their Needs.”
• National Institute of Standards and Technology, “Baldrige Criteria Commentary.”
• Steve Blank, “Learn Why It Pays to Get Out of the Building.”
• Basecamp, “Where We Came From.”

Open research

• Hennink, Kaiser, and Marconi, “Code Saturation Versus Meaning Saturation: How Many Interviews Are Enough?”
• Vasileiou and colleagues, “Characterising and Justifying Sample Size Sufficiency in Interview-Based Studies.”
• Saunders and colleagues, “Saturation in Qualitative Research: Exploring Its Conceptualization and Operationalization.”
• Schmidt and Bijmolt, “Accurately Measuring Willingness to Pay for Consumer Goods: A Meta-Analysis of the Hypothetical Bias.”
• Joung and colleagues, “Customer Complaints Analysis Using Text Mining and Outcome-Driven Innovation Method for Market-Oriented Product Development.”
• “Using Supplementary Reviews to Improve Customer Requirement Identification and Product Design Development.”
• Härkönen, “Exploring the Benefits of Service Productisation: Support for Business Processes.”
• Shamsuzzoha, Blomqvist, and Takala, “Service Productisation Through Standardisation and Modularisation.”

Public reporting

• PCMag/Fox Business, “How Basecamp Defined a Movement and Stayed at the Top.”