Product teams spend a lot of energy on strategy and development. We discuss the roadmap, build the features, launch, and then move on to the next request. The question I keep coming back to is: what happened after the release? Without performance tracking and continued improvement, we can deliver a product without knowing whether it delivered value.
My way of thinking about the process is a continuous loop: Discovery → Strategy → Development → Go to market → Iteration → Back to discovery. These activities can overlap. The loop is a reminder to connect decisions to learning throughout the product’s life.
Connect the work before and after launch
Discovery tests the problem; strategy chooses the value and priorities; development turns those choices into a usable product. Go to market prepares positioning, onboarding, sales, operations, and support. These stages work better when the intended outcome and its success signals carry through to the release.
Agree who will review performance and feedback after launch. A launch checklist can confirm readiness, but it cannot establish whether people are getting value. Leave time and ownership for that investigation, rather than handing the product straight to the next feature request.
Iteration: measure, understand, and improve
Track a small set of signals tied to the intended outcome. Depending on the product, these might include successful task completion, repeat usage, conversion, support demand, or revenue. Combine the numbers with feedback to understand why people succeed, struggle, or leave.
- Define the intended outcome and its success signals before release.
- Assign someone to review performance and feedback at an agreed cadence.
- Use the findings to improve, investigate further, or reconsider the direction.
- Bring the next important question back into discovery.
A hypothetical launch: starts increase, successful use does not
Suppose a new onboarding flow attracts more starts, but users still fail to reach their first useful result. The Product Owner owns the follow-up investigation, working with a designer, an analyst, and support. More starts are encouraging; they do not answer whether onboarding now works.
- Behavioural metric: the share of users who start setup and complete the core task correctly without help, measured over the same agreed observation window.
- Support feedback: repeated questions about an import error and uncertainty about which step comes next. Review these alongside where users leave the flow.
- Investigation: observe an affected user, inspect the failed step, and check whether the issue is unclear guidance, a defect, or a mismatch with the user’s task.
- Changed decision: prioritise error recovery and clearer guidance before adding the planned dashboard. Review successful task completion and related support demand after the change.
In this scenario, the release changes the next priority. That is the loop doing useful work: assign an owner, combine behaviour with feedback, and let the evidence alter the decision.
For me, product management means staying interested in the product after it ships. The work continues as long as there is value to understand, deliver, and improve.