A new customer creates an account, watches the welcome animation and reaches a dashboard full of empty charts. The product records an activation event. The customer still has no useful result and no clear idea how to obtain one.
That gap is the real onboarding problem. Time to value measures how long a defined customer takes to reach a first successful result, from a stated starting event and under stated conditions. Reducing clicks can help, but a short path to a meaningless dashboard does not create value.
This chapter of The AI Software Factory focuses on the first accepted outcome. Selling outcomes defines the promise; this article turns its first delivery into a measurable journey. Retention and habit addresses what happens after that first result.
Define the value event in customer terms
The value event should represent something the customer can use. For a hypothetical merchant app, it might be an accepted exception report with source references and an understood next decision. Producing any report is too weak if unsupported inputs yield an unusable result.
Write the acceptance condition before instrumenting the interface. Does the customer need to review the result? Must a teammate receive it? Does it have to include every source item? The answers determine which event deserves to count as first value.
A customer’s delighted reaction can be informative, but it is not a substitute for the job definition. Some useful products are quiet and procedural. A clean invoice reconciliation may not create an emotional “aha” even though it completes valuable work.
Distinguish initial demonstration from customer value. A sample report shows the product’s shape. A report based on the customer’s valid input completes a different step. Both may belong in onboarding, but they should be recorded separately.
Choose a start event that matches the question
Time from account creation answers a different question than time from a valid file upload. The first includes obtaining data, setup and possible interruptions. The second isolates processing and review after prerequisites are met.
Measure both if they inform different decisions. The founder may need the whole customer journey while the engineering team investigates a processing delay. Do not silently switch denominators because one makes the product look faster.
State the start event in every comparison. If a pricing experiment attracts customers without the required data, account-to-value time may worsen even when the processing flow improves. The product needs that context rather than a single celebratory number.
For a proposed app, define account created, required source available, valid input accepted, result produced and result accepted as separate events. They make the path explainable and reveal which delay the team can reasonably affect.
Draw the prerequisite path before the screen path
A customer may need an export, an account permission, a colleague’s approval or knowledge of a business identifier before they can succeed. Those tasks exist whether the interface shows them or not.
List prerequisites in the order customers can obtain them. Explain requirements before asking the customer to begin an expensive or frustrating step. A file template can save more time than removing a decorative onboarding screen.
Identify prerequisites outside the user’s control. If a staff member cannot authorize the integration, the flow should provide a clear handoff to the appropriate person. Repeatedly asking the same user to retry does not shorten the journey.
A proposed readiness check can separate customers who can proceed now from those who need help. It should provide useful next actions rather than treat missing prerequisites as personal failure. The check also prevents unsupported input from consuming paid processing before the problem is discovered.
Instrument states that explain delay
A single completion event cannot tell the team where customers stall. Record meaningful transitions such as setup started, source validated, mapping confirmed, processing queued, result ready and result accepted.
The event definition should include the relevant account and job identity without collecting unnecessary private content. Privacy design matters here: instrumentation should explain the workflow while respecting the product’s data boundaries.
Distinguish user waiting from system waiting. A customer may leave to obtain a file, while another waits for a long queue. Both increase elapsed time, but they require different interventions. A queue optimization will not fix a missing permission handoff.
Preserve failure states and abandonment. Customers who never reach value are central to the analysis. Removing them from the denominator creates a fast-looking success group while hiding the people the onboarding failed.
Compare cohorts with relevant context
A new customer using a supported template may reach value differently from a customer migrating a large dataset. Treating them as one average can hide both an excellent simple path and an unusable complex path.
Choose cohorts that correspond to a product decision: source format, account size, acquisition channel, required integration or onboarding assistance. Avoid slicing so finely that a few observations become an unsupported general claim.
Report completion as well as timing. A flow can reduce median time among successful customers while fewer customers complete it. Both results matter. State the observation window so a customer still working is not silently labeled a permanent failure.
An illustrative analysis might compare first-value completion within a chosen period and elapsed time among completed cases. The period and target should be justified by the customer’s task cadence. No universal activation deadline applies to every app.
Remove work the customer does not need yet
Onboarding often asks for organization details, preferences, team invitations and optional settings before the first useful result. Some are necessary; others exist because the database has fields to fill.
Ask whether each step supports the first accepted outcome. Defer optional configuration until it has a visible purpose. A customer who understands the result can make a better choice about notifications or collaboration than one guessing from an empty interface.
Do not defer information that affects authority or commercial commitment. Permissions, material data use and charges belong before their consequence. A faster flow achieved by hiding those decisions creates misunderstanding rather than better time to value.
Keep defaults reversible when practical. A suggested report format can reduce setup, provided the customer can inspect and change it. An automatic external write is a different consequence and needs the appropriate authority boundary.
Make progress truthful
Long-running processing needs a useful waiting experience. The customer should know whether work is queued, running, awaiting input or failed. A progress bar that advances independently of actual work can make an uncertain wait harder to interpret.
Explain what the customer can do during the wait. Can they leave and return? Will the job continue? Where will the result appear? These answers reduce the need to keep a browser open without inventing a completion estimate.
If an estimate exists, establish how it is derived and how it behaves for unusual cases. An approximate range supported by observed comparable jobs can be useful. A precise countdown that repeatedly resets damages the promise.
Durable workflows addresses technical continuation. The customer experience should reflect those actual states, including a paused job or a required review, rather than hide them behind one generic loading animation.
Treat input repair as part of onboarding
The first file rarely deserves a mysterious rejection. A useful validation result names the problem, shows a safe example and explains how to correct it. It should preserve valid work when possible.
For a hypothetical report app, an invalid date column could be identified before processing. The customer might choose the correct column or download a template. A generic error requiring a new upload forces repeated effort and gives little learning.
Separate correctable input issues from unsupported use cases. A missing required field may be repaired. An entirely different report type may require a separate product path. Pretending every rejection is a minor typo prolongs an unsuitable onboarding journey.
Record repair attempts and eventual success. If the interface repeatedly produces the same validation error, it may be explaining the requirement poorly. Those cases are valuable evidence for improving instructions and examples.
Assistance changes the measurement
A founder can guide early customers through setup and learn where the flow fails. That assisted path is useful, but it is not evidence that an unassisted customer can reach value at the same speed.
Record the assistance provided: preparing a file, mapping fields, explaining a result or contacting an integration owner. Include the human time when evaluating delivery economics. A product can appear effortless because the founder performs its hardest work offscreen.
Compare assisted and unassisted results honestly. Assistance may be an intended paid service, a temporary research method or a signal that the product needs better setup. Choose the role explicitly rather than allowing it to become a hidden permanent dependency.
Concierge MVPs explore manual learning. For activation analysis, the key is preserving the difference between a tested software path and a founder-supported demonstration.
Preserve accessibility on the shortest path
A flow that depends on precise dragging, tiny controls or visual-only instructions may be fast for some users and obstructive for others. Shortness should be measured through successful completion, not only screen count.
WCAG 2.2 includes Level AA criteria addressing alternatives to dragging and minimum pointer target size, with specified exceptions. These are concrete design checks; meeting two criteria does not establish full conformance.
Provide a practical alternative to dragging a file or mapping a field when the interface otherwise requires it. Make errors understandable beyond color alone. Test the task through the input methods relevant to the intended users.
Accessibility improvements can also clarify the workflow for everyone, but do not claim a measured activation gain without evidence. The immediate reason to address an inaccessible step is that it prevents a customer from completing the promised job.
Run a bounded improvement test
Choose one suspected bottleneck and state what improvement should accomplish. For example, a clearer file-readiness checklist might increase valid first uploads without increasing confusion about supported formats.
Keep acceptance criteria independent of the changed interface. The result should still meet the same useful-work definition. If the team redefines success as “clicked continue” after simplifying setup, it has changed the measurement rather than solved the problem.
Include protected cases: an unsupported file, an incomplete file, a customer without integration authority and a customer returning after interruption. A change that speeds the easy path while trapping these cases needs further work.
Set a stopping condition and record the evidence. If observations are too sparse to support a comparison, say so and use qualitative findings to guide the next test. A proposed experiment is not a measured activation improvement.
When slower onboarding is appropriate
Some steps deserve time because they protect a consequential decision. A customer may need to review recipients, confirm a financial amount or understand an external write. Removing that review can shorten a clock while worsening the result.
Separate unnecessary effort from necessary deliberation. An interface can make review clearer and preserve context without rushing the customer. The right question is whether the step supports a valid decision, not whether it adds seconds.
For a high-consequence product, first value may be a correctly prepared draft rather than an automatically executed action. That smaller outcome can be honest and useful. Expanding authority later requires evidence and a different onboarding explanation.
Safe writes defines consequential commitment. Activation design should respect that boundary even if a competitor’s demo reaches its final screen more quickly.
Recheck activation after product changes
A new integration or expanded input format changes the first-value path. Existing event names may remain while the work inside them becomes more complex. Review definitions and cohort boundaries after significant changes.
Model substitutions can also alter processing time and result acceptance. A faster generation step may create more correction work. Measure the complete accepted outcome rather than celebrating the isolated latency reduction.
Keep a small set of representative onboarding cases available for review. They should include ordinary success, repairable input, unsupported scope and interruption. Revalidate the journey when changes affect those cases, not only when marketing asks for a new onboarding video.
A customer who has previously used the product may take a different path from a first-time account. Do not let returning-user speed conceal confusion experienced by new buyers.
Follow the handoff after the first screen
A first useful result may need to leave the app before it becomes valuable. A staff member downloads the exception report, sends it to the merchant and answers a question about one item. If the product stops measuring at download, it may miss a confusing handoff that prevents acceptance.
Define the intended recipient and the necessary context. A report shared outside the app should preserve its source date, account scope and unresolved conditions. It should not require the recipient to log in merely to understand what the sender is asking them to review, unless that access is necessary for the product’s data boundary.
A proposed handoff test would ask someone who did not generate the report to identify its purpose and next decision. If they cannot distinguish a draft from an approved plan, improve the representation before optimizing export speed.
Keep the customer informed when a prerequisite expires
A connection can expire, a file can become stale or an approval can change while the customer is still onboarding. The flow should detect the relevant change rather than continue with assumptions that were valid only at the first screen.
Explain the specific new requirement and preserve work that remains usable. If the source date is too old for the promised diagnosis, request a fresh export while retaining the field mapping. If access is revoked, stop the dependent job and identify how an authorized person can restore it.
This gives the customer a predictable restart path. It also keeps elapsed-time records interpretable: a pause caused by changed prerequisites differs from unexplained processing latency. Both belong in the journey, with enough context to choose the next improvement.
What Would We Do at Salars?
For a proposed merchant diagnosis app, we would define first value as a source-linked report the merchant can review for the stated decision. The sample demo would be recorded separately from that customer-specific outcome.
We would measure account creation, source readiness, accepted input, result availability and result acceptance. A proposed review would examine completion and elapsed time by relevant source format and assistance level. These are planned measurements, not reported Salars activation results.
The first improvement would target the largest observed avoidable delay. If customers lacked a supported file, we would clarify the readiness instructions. If valid jobs waited in a queue, we would investigate runtime capacity. If reports required excessive correction, we would improve result quality before polishing the welcome screen.
We would retain unsupported and interrupted cases in the evidence. A proposed change would need to preserve accurate authority and billing explanations while improving successful completion. Faster misunderstanding would not satisfy the test.
The first-value clock is useful because it forces the product team to follow the customer’s work from readiness to a result worth using. Keep that result explicit as you explore the broader AI collection.
Sources
- W3C WCAG 2.2 — Recommendation and criteria 2.5.7/2.5.8; two checks do not demonstrate full accessibility conformance.
Loading comments…