Blog

How to choose the first customer for a focused offer

A practical way to turn a broad audience into a reachable first customer, a specific problem and a useful test.

By Michael Santiago6 min read
A team examining a first customer workflow

A first customer choice gives a new business something concrete to learn. A broad audience such as small businesses or growing teams contains too many different situations to guide a useful offer. The founder needs a person they can reach, a recurring problem they can recognize and a piece of work they can deliver well. Choosing that starting point makes conversations, prototypes and early sales efforts easier to compare.

This guide uses a fictional example: a founder considering a service that helps small agencies improve client onboarding. The method also applies to an early software product or a practical training offer. The aim is to finish with a working customer definition and a small test. Adapt the timing and scope of each exercise to the work the team can deliver.

Describe a recent situation

Begin with a situation someone has already experienced. For the agency example, it might be a new client who signed a proposal but took weeks to provide access and materials. Ask what happened from the moment the work was agreed. Who requested information? Where was it stored? What did the project manager have to chase? A recent sequence gives the founder specific steps to examine.

Write the problem as a task with a consequence. “The project manager needs the client to supply access before the scheduled start so the delivery team can begin” is a useful working description. It identifies a person, an action and a reason. It is also possible to ask someone for an example of that situation. A phrase such as “agencies need more efficiency” leaves too much for the listener to interpret.

The GOV.UK guide to learning about users and their needs recommends understanding users' existing activities, problems and goals. Its setting is public services, but the research habit is useful here: look closely at the task before committing to a solution. A founder can record the evidence in a simple table with a source, a situation and an unresolved question.

Separate the person using the offer from the person buying it

In the example, a project manager might do the daily work while an agency owner approves spending. Both people matter. The manager can describe the handoffs and missing information. The owner can explain how onboarding fits the agency's priorities and what would justify trying a new approach. Interviewing only one of them can leave the founder with half of the picture.

Prepare a few questions for each role. Ask the manager to show a recent onboarding sequence with appropriate private information removed. Ask the owner how a change to that process would be evaluated and who else needs to be involved. Avoid turning the conversation into a presentation of the proposed product. The first objective is to understand the work and the decision path that surrounds it.

Compare a small set of candidate groups

List a few groups that experience the problem in different ways. A small design agency, a recurring marketing service and a specialist development firm may all onboard clients, but the access requirements and delivery patterns differ. Compare their situations using criteria tied to the first offer: how often the problem appears, how easy the people are to reach, who can authorize a test and whether the founder can deliver a useful change.

A short written comparison is enough. Give each group a plain-language note rather than a false sense of precision from an elaborate score. For one group, the problem may be frequent but the buying process difficult to access. For another, a founder may already have relevant relationships and understand the workflow. The selection should reflect the work that can actually be tested during the next few weeks.

Write the first offer in terms of a deliverable

An initial agency-onboarding offer could be a review of one recent client setup, followed by a revised request sequence and a trial on the next suitable project. State the inputs required, the output the client receives and the responsibilities on both sides. A prospective buyer should be able to understand what will happen during the engagement and what they will hold at the end.

Keep the scope small enough to deliver with the current team. A founder can learn a great deal from improving one handoff. It is harder to interpret a project that changes the sales process, the delivery software and the account-management model at once. A bounded offer also makes it easier to see which part of the work the buyer values and which part consumes most of the delivery effort.

Choose a test that matches the question

Different uncertainties call for different tests. An interview may help understand the current process. A walkthrough of a proposed workflow may reveal confusing steps. A pilot with a real project can show what happens when people use the new sequence. Before choosing a method, write the question the founder needs answered. Then choose an activity that can produce relevant evidence.

Nielsen Norman Group’s overview of user-research methods distinguishes reported attitudes from observed behavior. That distinction helps when a founder hears encouraging comments about an idea. Someone saying a workflow sounds useful is different from watching them use it on a real task. Record each kind of evidence clearly, then decide what question remains before the next commitment.

Make the invitation easy to understand

An early invitation can be brief. State the situation being investigated, who the session is for and what participation involves. If the founder wants to observe an onboarding handoff, say that. If the founder is selling a paid pilot, describe it as a paid pilot. Clear expectations produce a more useful conversation than an invitation that hides a sales presentation behind a research request.

Reach out through relationships and communities where the selected group already gathers. Ask relevant contacts for introductions to the specific role. Keep a record of which invitation led to which conversation and why someone declined. A pattern of declines may reveal that the proposed task is poorly timed, the audience is hard to reach or the description does not match the language people use about their work.

Decide what to keep after the first round

After the first set of conversations or pilots, review the evidence against the original customer definition. Which situations repeated? Which buyer could describe the value in their own words? What work took longer than expected? Which requests were outside the planned scope? These questions help the founder refine the offer and choose the next group of people to approach.

Write a short decision note. It can say that the next test will focus on one agency type because its onboarding pattern is consistent and the decision maker is reachable. It can also identify what remains unknown. Keeping that note allows the next review to compare a deliberate choice with what happened, instead of remembering only the most enthusiastic conversation.

Carry the choice into the business identity

A focused customer does not require a company name tied to one temporary feature. A founder building under GrowBy could describe a specific onboarding offer while keeping room for adjacent work revealed by experience. The customer definition belongs in the offer and the sales conversation. The company name can remain consistent as the founder learns which problem deserves a deeper product.

The practical next step is to write three sentences: the person being served, the recent situation they face and the deliverable that will help them act. Use those sentences to arrange the next conversation. Once a real person can respond to that concrete description, the founder has a better starting point for deciding what to build.

A company built around progress

Your first offer. The name to carry it forward.

Ask about GrowBy.com, or describe a different name PremiumBrands can help you acquire.

Request pricing