I think growth teams sometimes stop watching one scene too early.
The report was generated.
The study set was created.
The meeting agenda was drafted.
The meal plan was saved.
Those are satisfying events. They are visible, instrumentable, and close enough to the product that a team can improve them. They are also only evidence that the product made an output.
An output does not become valuable merely because it exists.
The report has to change a decision. The study set has to be used before the exam. The agenda has to survive contact with the meeting. The meal plan has to make it into a kitchen on a tired Wednesday.
Growth Product should follow the work past creation and into use.
Creation and use are different jobs
Imagine a product that turns a messy set of notes into a polished project brief.
The onboarding team might define activation as generating the first brief. That is understandable. It is the first moment the product does the thing promised on the landing page. It probably predicts retention better than account creation does.
But the user did not wake up wanting a generated document. They wanted a team to make a clearer decision.
Between those two moments sits a last mile.
Someone has to notice the brief, trust it, bring it into the planning conversation, and make it legible to people who did not help create it. The brief may need a link in a calendar invite, an export into the team’s usual workspace, or a sentence its creator feels comfortable saying out loud.
The product can be excellent at production and weak at passage.
That distinction appears outside software too. Logistics teams know that getting a package near its destination is not the same as completing delivery. Public health programs can have an effective intervention in a warehouse and still fail to reach the person who needs it. The analogy is imperfect, but the product lesson travels well. Value can get stranded after most of the visible work is done.
The UK government’s service standard asks teams to solve a whole problem for users. I like the bluntness of that instruction. A product boundary and a user outcome are rarely in exactly the same place.
The last mile is usually a context change
The first output often happens in the product’s preferred environment.
The user is signed in. The relevant data is nearby. The interface can explain itself. The team controls the empty state, the button, and the celebration.
Use happens somewhere less convenient.
It happens in a classroom, a sales call, a kitchen, a commute, or another tool. It may happen three days later. Other people may be present. Attention is divided. The person who created the output may not be the person who needs to understand it.
This is why another export format is not always the answer. Passage is not only file movement. It is movement across time, attention, audience, and stakes.
Research on implementation intentions offers a useful connection. Peter Gollwitzer’s review describes how specifying when and where an intended action will happen can help turn a goal into action. The original paper is available through the National Cancer Institute’s bibliography. A product output is not an implementation intention, but the underlying gap should feel familiar. Wanting to use something later is weaker than attaching it to a real situation.
That suggests a better product question than asking whether the user saved the output.
Where will this become useful, and what must still be true when that moment arrives?
Follow the output with a last-mile trace
The artifact I would use is a last-mile trace.
Pick one output that the team currently treats as meaningful progress. Then follow a handful of real examples until they are used, abandoned, or impossible to locate. For each one, write down the following.
- The outcome the user was trying to change
- The output the product created
- The real situation where the output could matter
- The expected time between creation and use
- The people who must notice, trust, or interpret it
- The carrier that moves it into that situation
- The context that will be missing when it arrives
- The observable evidence that it was actually used
- The reason it became stranded, if it did
- The smallest product move that could help it travel
The carrier deserves special attention.
It might be a calendar event, printed page, browser tab, notification, shared link, email, or a person remembering to mention something. Teams often treat these as peripheral sharing mechanics. In practice, the carrier may be the only bridge between a strong creation experience and the user’s actual goal.
I would give each traced output one plain status.
- Created when it exists but has no destination
- Placed when it is attached to a likely moment of use
- Received when the relevant person can find and understand it
- Used when it changes an action or decision
- Stranded when the chain breaks
This is not a universal funnel. Some products produce value immediately, and some useful work leaves no clean evidence of consumption. The statuses are prompts for investigation, not a new dashboard religion.
Their value is in making the missing distance discussable.
Instrument the passage without pretending to see everything
A team will naturally want to turn the trace into events.
That can help. A brief added to a calendar invitation is stronger evidence of intended use than a brief generated. A recipe reopened near dinner is different from one saved during a Sunday browse. A lesson plan viewed by the teacher on the morning of class tells us more than the original export.
Still, telemetry has a boundary.
The decision may happen in a room the product cannot observe. The printed checklist may work perfectly while the dashboard calls it dormant. The shared report may influence a colleague who never creates an account.
Do not respond by grabbing more data than the job requires. Combine a few honest product signals with interviews, diary studies, support conversations, and direct observation. The Nielsen Norman Group overview of diary studies explains why longitudinal self-report can reveal experiences that are difficult to observe directly. That is especially useful when creation and use are separated by time or setting.
The goal is not perfect surveillance. It is a better account of where value finishes.
Test the bridge rather than adding another celebration
Suppose people create weekly planning briefs, but interviews show that many briefs are forgotten before Monday’s team meeting.
I would write the hypothesis this way.
We believe letting creators place a brief into an existing calendar event will increase briefs used in planning meetings, because the work will reappear in the situation where it matters rather than relying on memory alone.
The experiment should begin with people who create a brief and have a plausible meeting ahead. Randomly offer some of them a lightweight way to attach the brief to that event. Do not force calendar access as the price of finishing the brief.
The immediate measure might be successful placement. The more meaningful measure is evidence of use near the meeting, such as reopening, presentation mode, collaborator viewing, or a short voluntary confirmation. I would also watch whether creators keep making briefs over the following cycles and whether recipients can understand them without asking for a reconstruction.
Guardrails matter here.
Calendar connection rate is not the outcome. More notifications are not automatically better. A bridge that creates surprise invitations, exposes private work, or fills calendars with product debris is worse than the memory problem it was meant to solve.
Hold out enough eligible users to learn whether the bridge changes use rather than merely generating another trackable action. Talk to people whose work still became stranded. They may reveal that timing was never the issue. The brief may be too polished to edit, too long to discuss, or politically awkward to introduce.
That is useful failure. It moves the team from optimizing document creation to understanding what the document must do.
Acquisition should promise the destination
The distinction changes acquisition too.
An SEO page built around project brief template can easily optimize for producing a project brief. That matches the query, but it may stop short of the searcher’s harder job. They may need agreement on scope, a defensible decision, or a clean handoff to the people doing the work.
Useful acquisition content should help with that destination rather than padding the page around a signup box. Google’s guidance recommends creating helpful, reliable, people-first content instead of content made primarily to attract search visits. For a growth team, that is not merely an editorial rule. It is a reason to let search research sharpen the product’s understanding of what happens after the artifact is made.
The same standard applies to landing pages. If the headline promises aligned teams while the product celebrates generated briefs, there is a missing claim to test. Either show how the brief travels into a decision or narrow the promise.
Lifecycle can help when it knows the intended use. A reminder the morning of the meeting can be service. A generic message two days after creation asking the user to make another brief is just the product admiring its own output.
Sometimes the honest boundary is enough
Not every product should own the last mile.
A writing tool cannot guarantee that a proposal will persuade. A budgeting product cannot make a household agree. A learning product cannot sit the exam for the student.
Trying to absorb the whole outcome can produce bloated software, invasive measurement, and claims no team can defend.
The better move may be to name the boundary and make the handoff sturdy. Let the user choose the destination. Preserve enough context for the next person. Make the output easy to retrieve at the right moment. Confirm what the product did and avoid claiming what it cannot know.
This is where product judgment matters more than funnel neatness.
Sometimes the last mile needs a feature. Sometimes it needs a better export, a timely reminder, a printable view, or one line of copy that tells the user what to do next. Sometimes research shows that the artifact was never the right unit of value at all.
The first output is still worth celebrating. It proves that the product can make something.
Just do not confuse making something with making a difference.
