Win Work You Can Deliver

Chapter 2 of 10 · 10 min read

Test a customer problem before building an offer

Use observation, interviews and bounded pilots to test a customer problem without mistaking polite interest for dependable demand.

A convincing offer can be built around a problem that customers do not care enough to solve. The wording may be attractive, the website professional and the explanation technically correct. None of those things establishes that someone will change their behaviour or pay for the work.

Research is valuable when it changes a decision. Before speaking to customers, identify what you are uncertain about and how different answers would affect the offer. Otherwise the conversation can become a search for encouraging comments rather than a test of a business assumption.

For Fieldnote Studio, the initial assumption is that small service firms lose useful time explaining inconsistent package information. That sounds plausible. It still needs evidence about who experiences the problem, when it occurs and whether a document package is an appropriate response.

Write a claim that can be challenged

A broad statement such as “small businesses need clearer information” is difficult to disprove. Narrow it to a situation: “Firms with several service packages and more than one person answering enquiries repeatedly correct inconsistent explanations.” This defines a group, a circumstance and an observable behaviour.

Then identify alternatives. Perhaps enquiries are confusing because prices change too often, because the service itself is unclear or because staff have no authority to answer. A rewritten pack may help one cause and leave another intact. Research should be allowed to change the diagnosis.

The Australian Government’s market research guidance describes several sources of evidence, including existing customer records, interviews and feedback. For this book, the practical recommendation is to combine more than one kind of evidence rather than treating a single agreeable interview as a verdict.

Start with the records you already have

Before arranging interviews, look at the evidence already in the business. Enquiry emails, call notes, frequently asked questions, complaint records and quotes that did not proceed all contain information about what customers find confusing or important. Reviewing them costs nothing but time and involves no one else.

For Fieldnote’s own offer, the team reads the enquiries its contacts are willing to share, with personal details removed, and notes each time a customer asked what a package included, or received an answer that later had to be corrected. The aim is not to produce a percentage but to collect concrete examples: the exact question, the answer given and what happened next. Those examples make later interviews sharper, because the interviewer can ask about situations that are known to occur.

Records also have limits. They show what customers asked, not what they wanted and did not ask, and they show only the customers who made contact. People who gave up before enquiring leave no record at all, which is one reason interviews remain necessary.

Plan the conversation before the call

An interview without a plan tends to drift towards the interviewer’s idea. A short written guide keeps it on the customer’s experience. Fieldnote’s guide for a 30-minute conversation has five parts:

  1. Context: the person’s role and how enquiries reach the business.
  2. A recent event: the last time a customer misunderstood a service, told in sequence.
  3. The workaround: how the problem is handled today, by whom, and what it costs in time or goodwill.
  4. Priority: what else competes for attention, and what has already been tried.
  5. Close: whether there is anything the interviewer should have asked, and permission for any follow-up.
Figure 1A 30-minute discovery conversation
  1. Contextrole and how enquiries arrive
  2. A recent eventtold in sequence
  3. The workaroundwho handles it and what it costs
  4. Prioritywhat competes, what was tried
  5. Closewhat was missed, permission to follow up
The solution is not described until the end, if at all, so it cannot shape the account of what happened.

Take notes in the customer’s words where possible, and write a short summary within a day, while the conversation is fresh. Note where the customer was uncertain or contradicted an earlier point; those moments often matter more than the confident statements.

Ask about events rather than approval

Questions about recent events tend to produce more useful detail than invitations to admire an idea. Ask the customer to describe a particular enquiry, what happened next and what information was missing. Explore the current workaround before introducing your solution.

For example, a Fieldnote interview might begin with: “Walk me through the last time a customer misunderstood what was included.” Useful follow-up questions concern who noticed, how it was corrected and whether the correction affected time, money or trust. Ask permission before viewing any actual document; a redacted example may be enough.

Compare this with “Would a clearer pack help?” A yes is easy and may be sincere, but it tells you little about priority. The person may like the concept while having no intention of changing anything this year.

Separate three things in your notes: what happened, what the customer believes caused it, and what you infer. A repeated correction is an observation. “Our old document causes it” is an explanation to test. “They will buy our package” is a further inference. Keeping these apart stops a short conversation from becoming a chain of unsupported conclusions.

Silence is useful too. After a customer finishes describing an event, waiting a few seconds before the next question often brings out the detail that matters most: the second correction, the customer who did not come back, the manager who was annoyed. Interviewers who fill every pause with their next prepared question tend to hear only the first, tidiest version of each story. Practising this takes some discipline, but it costs nothing and frequently changes what the research finds.

Figure 2Keep observation, explanation and inference apart
  1. Observation"Staff corrected an explanation twice last month"
  2. Customer's explanation"Our old document causes it", to be tested
  3. Your inference"They will buy our package", the weakest claim
Each step needs more evidence than the one before it; a short conversation should not jump straight to the last.

Ask questions that do not lead

The wording of a question can produce the answer the interviewer hopes for. Leading questions are easy to write and hard to notice in the moment.

Figure 3Leading questions and better alternatives
LeadingBetter
Need"Wouldn't a clearer pack save you time?""What happens when a customer misreads a package?"
Priority"Is this a big problem for you?""What else is competing for attention this quarter?"
Price"Would you pay A$2,000 for this?""What have you spent, in time or money, on this so far?"
Solution"Do you like our approach?""What would have to be true for a change to be worth making?"
The better versions ask about events and consequences, and leave room for an answer the interviewer did not expect.

The better questions share three features. They ask about past events rather than hypothetical futures, they do not mention the proposed solution, and they allow the person to say that the issue is minor. A research conversation in which every answer agrees with the interviewer should be treated with suspicion, not celebration.

Look for variation and disconfirming evidence

Interviewing only friendly contacts can produce a narrow picture. A customer who already trusts you may tolerate weaknesses that a new buyer would not. A person who rejected a similar service can explain obstacles that enthusiastic prospects overlook.

Fieldnote deliberately includes a firm that recently rewrote its information internally. It discovers that the firm had a capable writer but struggled to obtain a final approval from several managers. That finding changes the proposed service: the approval process matters as much as the writing.

A small sample is useful for discovering questions and failure modes. It does not establish the percentage of a whole market that will buy. Avoid converting a few interviews into a market-size forecast with precise-looking numbers. Record the composition of the sample and the missing perspectives.

Treat participants fairly

People who give their time to research deserve to be treated as participants, not as sales targets. Say clearly at the start that the conversation is to understand their situation, not to sell, and keep to that. If they later ask about the service, a separate conversation can follow.

Ask permission before recording or before keeping any document they show you, and store notes so that personal and commercial details are protected. Share only de-identified examples within your own team, and never use one participant’s information in a conversation with another. If a participant raises something that makes them uncomfortable, such as a dispute with a client, move on rather than probing. These practices are courteous, and they also make the research more honest: people describe problems more frankly when they trust how the information will be used.

Test the smallest meaningful commitment

The strength of a signal depends on what the person actually does. Agreeing to another conversation is different from supplying information, allocating staff time or accepting a paid pilot. These actions are not interchangeable, and none guarantees long-term demand.

Figure 4How strong is the signal?
  1. Accepts a bounded paid pilotdefined fee, output and time limit
  2. Allocates staff timethe work matters enough to resource
  3. Supplies informationredacted examples, current documents
  4. Agrees to another conversationinterest, but little commitment
None of these guarantees long-term demand, but each step up costs the customer more and so says more.

A bounded pilot can test a delivery assumption as well as demand. Fieldnote offers to review one existing service page, identify inconsistencies and discuss a sample rewrite. The pilot has a defined fee, output and time limit. It does not pretend to deliver the full package for a token price.

Before running it, the team writes what it expects to learn: whether the customer can supply usable input, whether staff agree about the service, how long review takes and whether the result is useful enough to support a larger commission. A pilot that merely gives away extensive work may generate appreciation without testing a viable business.

Keep a compact evidence table

AssumptionCurrent evidenceRemaining uncertaintyNext useful test
Staff give different explanationsCustomer describes two recent correctionsFrequency and cause are not confirmedCompare approved wording with redacted enquiries
A pack could reduce confusionStaff identify missing informationService rules may themselves be inconsistentResolve one ambiguous inclusion with the owner
The customer can approve the workOne manager supports the ideaOther reviewers are unknownConfirm who approves and consolidates feedback
The service can be delivered economicallyInitial task estimate existsRevision time is uncertainTrack actual time on a bounded pilot

This is a working table, not proof that the opportunity is good. Update it when evidence changes. If a test contradicts a claim, change the offer or stop. Do not quietly replace the original success criterion after seeing the result.

Figure 5The evidence table is a loop, not a verdict
  1. State the assumptiona claim that can be challenged
  2. Record current evidencewhat has actually been observed
  3. Name the remaining uncertaintywhat would change the decision
  4. Run the next useful testsmall, specific, decision-changing
If a test contradicts a claim, change the offer or stop; do not move the success criterion after seeing the result.

Decide what the research permits

Evidence can support different next steps. Repeated, costly confusion with a willing owner may justify a scoped offer. A vague concern with no recent example may justify a lighter educational resource. Inconsistent service definitions may require internal decisions before a writing job can begin.

An honest conclusion can be “we do not know enough yet”. Attach that conclusion to a specific missing fact rather than making research endless. The amount of evidence should fit the reversibility and cost of the decision. Publishing a test description is easier to reverse than hiring staff around an untested service.

Know when to stop

Research can expand indefinitely, especially when the result might be disappointing. A practical signal for stopping is when new conversations stop changing the evidence table: the same causes, workarounds and obstacles recur, and no new question appears. At that point, further interviews of the same kind add little, and the next useful step is a test of behaviour, such as the bounded pilot.

Set the limit in advance where possible. Fieldnote decides to hold six to eight conversations across different kinds of firm, then review. If those conversations produce conflicting pictures, the review may justify more; if they converge, the team moves to the pilot. Either way, the decision is made on the evidence collected, not on how comfortable the team feels about the answer.

Write the findings for a decision, not a report

At the end of a round of research, write a one-page summary that someone could use to decide what happens next. It should state the original claim, what the evidence showed, what it contradicted, what remains unknown, and the recommended next step with its cost and stopping point. Quotes from participants can illustrate a point, but they should not replace the summary of what was observed across conversations.

For Fieldnote, the summary might read: the claim that inconsistent package information costs time was supported in four of six conversations with recent, specific examples; in two, the underlying issue was undecided service rules rather than wording; approval by several managers emerged as a common obstacle; willingness to pay was not tested. The recommendation is a bounded paid pilot with one firm that has agreed service rules and a single approver, to test delivery time and usefulness.

Note what the summary does not claim. It does not estimate how many firms in the market share the problem, and it does not predict sales. It records what a small, described sample showed and what the business will do next because of it. That is enough to make a sound decision, and it can be revised when the pilot produces its own evidence.

Exercise: challenge your preferred explanation

Write the explanation you currently favour for a customer’s problem. Then write two other explanations that could produce the same observation. Identify a question or small test that would distinguish them. Do not ask the customer to choose from your explanations until you have heard their account in their own terms.

The outcome of this chapter is a more credible problem definition and a bounded offer hypothesis. The next task is finding a repeatable way to meet suitable customers without confusing activity with demand.