Customers Finished Setup. Can They Do the Job?

The account exists. The customer has connected their data, invited a colleague and reached the dashboard. Every step in your onboarding checklist is green.

Imagine asking what they have done with the product since then. They have looked around. They have opened a few screens. But the report they needed still has to be assembled elsewhere, or the action they expected to take cannot be completed without another explanation.

From inside the startup, this can look like a promising activation followed by disappointing engagement. From the customer's side, the useful part may never have started.

That gap is easy to miss when the team has spent weeks getting signup, authentication and integrations to work. Those are real achievements. They also make convenient events to track. The customer, however, came for something that happens after them.

I would give an early product a more demanding finish line: a first result the intended customer can use in their own work. That does not require a perfect product or a grand claim about retention. It requires being precise about what the customer gets after the setup is over.

A setup event answers a technical or procedural question. Has the account been created? Is the integration connected? Has the user reached this screen? Those questions help you find broken steps, but they cannot automatically answer whether the customer received value.

Consider a hypothetical tool that prepares a supplier comparison. Connecting data is necessary. Seeing a table is encouraging. But if the customer cannot distinguish current prices from old ones, the table may not support the purchasing decision they came to make.

You could improve the welcome sequence and move more customers to that table. The original gap would remain. You would have made it easier to arrive at an output they still cannot use.

The same issue appears when the product produces something technically valid that does not fit the customer's next step. The information is present, but the person who needs it cannot access it. The export works, but omits the detail required for the decision. The workflow accepts a submission, but provides no way to tell what happens next.

A founder does not need to assume all of these problems exist. The point is to inspect the boundary your milestone currently ignores. If onboarding ends before the customer's work can begin, completion is an incomplete description of success.

Choose one intended customer and one task. Avoid defining value as a broad feeling such as confidence or productivity when you cannot observe what changed. Describe the result in language the customer would recognise.

For the supplier tool, that might mean being able to compare the relevant offers and identify which one to take forward. For another product, it could mean sending a usable proposal or processing a real request. The precise result depends on the promise you are testing.

Then identify the smallest credible evidence that the result was useful. A generated file is weaker evidence than a file the customer can use for the intended decision. A button click is weaker than completion of the task that motivated the click.

This is not a demand to instrument every action outside your software. With early customers, you can ask them to show you what happens next and record the answer. If you cannot observe the downstream result, keep that uncertainty visible. Do not quietly replace it with the nearest event you happen to collect.

A useful milestone should also be reachable at this stage. If the first meaningful benefit takes a month, you may need an earlier sign that the customer is progressing. Treat that sign as progress towards value, with its limitations stated, rather than pretending the eventual outcome has already happened.

There is a measurement reason to keep those distinctions. Product analytics systems require you to define the event and the observation window. Amplitude's retention documentation, for example, distinguishes different kinds of return and limits some calculations to users who have had enough time to be observed. The software cannot decide which event represents a useful outcome for your customer.

There is also a causal limit. Research on long term online experiments from Microsoft describes ways that selection and measurement can distort the interpretation of results. Seeing that customers who reach a milestone later remain active does not establish that forcing everyone through that milestone will make them stay.

For a small startup, the immediate purpose is more modest and more practical. Find out whether your proposed milestone corresponds to a task that works. That gives you a better object to improve without turning a convenient correlation into a growth promise.

Ask a recently onboarded customer to attempt the real task with information they would normally use. Let their purpose guide the walkthrough. If you lead them through your preferred sequence, you may learn whether they can follow instructions while missing whether the product makes sense without those instructions.

Watch where they hesitate, what they work around and which output they trust. When they stop, ask what they expected. The first break might concern the interface, but it could also concern readiness: they lack a permission, a source file or a decision from somebody else.

In the supplier example, imagine discovering that the customer can generate the comparison but cannot tell which prices are current. That is a specific obstacle between setup and use. The next work item can address the information needed to make the result credible.

Now imagine the customer has no purchase to make until next month. A lack of completed comparisons today has another explanation. The product may be ready for a task that is not yet due. Pushing the customer through a simulated task might help with learning, but it would not prove that they have received the benefit of a real purchasing decision.

The investigation therefore needs both the path and the occasion. A task can be available in the interface and irrelevant to the customer at that moment. It can also be urgently needed and impossible to complete. Those conditions should lead to different decisions.

Pay attention to what the customer treats as evidence that the result is ready. The team may rely on a completed state in the interface while the customer needs to reconcile a total or have another person review the output. If that acceptance step matters to the intended task, it belongs in understanding first value.

This does not mean the software must perform every downstream action. The product may reasonably stop at a usable export. In that case, check that the export contains what the next step requires and that the customer understands its limits. The boundary can be narrow and still meaningful.

When nobody can describe what would make the output usable, the next investment may be clarification rather than implementation. Ask the customer to show an existing acceptable result or explain the decision it needs to support. Do not add more dashboard detail simply because an empty dashboard is an easier problem to recognise.

Once the gap is clear, resist expanding the work into a complete onboarding redesign. Fix the part that prevents the intended result, and preserve a way to see whether the change helped.

That could mean explaining the origin of the data, making the next action available, preserving a required field or showing an actionable message when an input is missing. It could mean changing the promise made before signup if the product serves a narrower situation than the customer expected.

Agree what the next observation should show. The customer should be able to complete the task and recognise what to do with the result. If you intervene, record the intervention rather than counting the session as independent success.

For an early product, a small set of customer notes can be sufficient to begin. Record the task, whether the customer had a real opportunity to perform it, the point where progress stopped and what happened after the change. Numbers become more useful when the underlying event has a stable meaning.

Keep setup measures as diagnostic measures. A broken connection still deserves attention. The improvement is to connect those measures to the customer's task instead of asking them to carry the whole definition of value.

Finally, give the check an owner. A developer can implement the change while the founder returns to the customer to understand the result. If both people assume the other will follow up, the startup can ship the fix and end up with the same unanswered question.

Consider what would make the milestone misleading after the change. A task event might fire even when the output is empty. A founder may complete the action on the customer's behalf. A customer may use sample information that never enters their actual work. Those observations can help test a path, but they should not be silently combined with useful customer outcomes.

Keep the definition understandable to the people using it. If the founder calls a customer activated because setup is complete while the developer assumes activation means a usable output, the same word will support conflicting decisions.

A short shared definition can state the task, the conditions and the remaining uncertainty. That is enough to make the next customer conversation and the next product change refer to the same finish line.

A first useful outcome is not proof that the customer will return, pay more or recommend the product. It establishes a narrower fact about a specific task under specific conditions.

Assistance changes those conditions. If you cleaned the inputs, interpreted the output or completed a missing step, the result belongs to the combined product and service. That can be a legitimate early offering, provided you do not describe it as independent product use.

Different customers may also require different first outcomes. That does not mean every preference should become a separate activation definition. Start with the customer and task you intend to serve. If the cases are fundamentally different, recognise that you may be testing different product promises.

Some customers are exploring rather than trying to complete work now. Some need an external approval before they can act. These are reasons to qualify the observation, not reasons to abandon it. A useful investigation should tell you what is known, what is blocked and what has not had a chance to happen.

Before spending another cycle polishing onboarding, follow one customer beyond the last checkmark. Ask them to attempt the job that brought them to the product and show you what they do with the result.

If they cannot get there, name the specific missing step. If they can, record the conditions and the help required. If the task is not due, arrange a better moment to observe it.

My standard would be simple: the first milestone should mean something useful to the person using the product. The team can still celebrate a working integration. It should also know whether that integration lets the customer accomplish anything.

A green checklist is a good place to begin that conversation. It is a poor place to end it.