These notes began across four pages of my diary. They are not a universal playbook. They are the questions and reminders I want close by when I am building a product and the answer is not obvious.
The central idea is simple: product management is a loop, not a launch.
Build. Put the product near real users. Listen. Rework it. Then go around again.
What changes after release?
Compare a launch that ends at shipping with a product loop that turns evidence into the next decision.
Ship before certainty
There is no perfect time to develop a product. The useful time is when I can put the smallest honest version in front of the people it is meant to serve.
The faster I reach that point, the faster I can replace assumptions with evidence. A launch is not the end of development. It is the beginning of the feedback cycle:
- Build the smallest useful version.
- Launch it to a specific group of users.
- Observe what they do and ask what they need.
- Reiterate.
Speed matters because learning matters. Shipping quickly without listening is just moving fast in the dark.
Find the aha moment
Before I can talk seriously about product–market fit, I need to know the moment when the product becomes useful in a way the user can feel. That is the aha moment.
I can begin with a small set of users—perhaps the first hundred—and identify the people who completed the action I believe creates value. Then I can ask them a more revealing question:
How would you feel if this product no longer existed tomorrow?
My diary divides the answers into three groups:
- Very disappointed: understand them more deeply. They may be closest to the product's real value.
- A little disappointed: learn what is missing, confusing or not yet essential.
- Not disappointed: do not let their requests control the roadmap. They may not be the users I should build for.
I had written a working target of roughly 35% of users answering “very disappointed.” The exact number is less important than the discipline behind it: find the people who would genuinely miss the product, understand what it does for them and serve that value better.
AI can help me draft interview prompts or a Mom Test-style questionnaire, but it cannot do the listening for me. Good feedback is about what people already do, where they struggle and what they have tried—not whether they like my idea.
That feedback should become an input to the roadmap, not a pile of quotes I collect and forget.
Prioritisation is the job
I can only launch a finite set of features. Time, engineering capacity, attention and energy are all limited. That makes prioritisation less of a planning exercise and more of the work itself.
One useful frame is RICE:
| Factor | Question |
|---|---|
| Reach | How many people will this affect? |
| Impact | How much will it improve the outcome for them? |
| Confidence | How strong is the evidence behind my estimate? |
| Effort | How much work will it take from the team? |
The score is (Reach × Impact × Confidence) ÷ Effort.
The formula is not a machine that makes the decision for me. It makes my assumptions visible. Beside the score, I also want to record how often users mention the problem. Frequency is not automatically priority, but repeated language is a signal worth seeing.
Measure the journey, not just the launch
The AARRR funnel gives me five different questions about the product:
| Stage | Behaviour I am looking for |
|---|---|
| Acquisition | A person arrives and creates an account. |
| Activation | They complete onboarding and reach the aha moment. |
| Retention | They return and use the product weekly, daily or monthly. |
| Referral | They review it, recommend it or bring another person in. |
| Revenue | They pay, subscribe or receive their first invoice. |
Each stage needs a clear definition and an owner. “Growth” is not a sufficient answer if nobody knows which behaviour matters or who is responsible for improving it.
The old Facebook example in my notes—an account becoming meaningful after a person added seven friends—reminds me that activation should be behavioural. “Signed up” is an event. “Experienced the value” is the milestone.
Retention is built into the product
Retention is difficult because it cannot be repaired with one reminder email. It comes from a product being worth returning to.
At the macro level, the product should reduce something the user does not want: time, effort, uncertainty or a bad feeling. It should also create some positive attachment—a sense of progress, relief, competence or even love for the experience.
At the micro level, small mechanisms can help people continue:
- feature sequences that reveal value over time;
- streaks, points or other forms of visible progress;
- useful communication and notifications;
- saved work, history and personal investment that make the product more valuable with use.
These mechanisms should reinforce value, not manufacture anxiety. A notification cannot rescue a weak reason to return.
My diary also contains a reminder that some people can take six or seven months before buying an app. Whether that timing applies depends on the product, but the larger lesson holds: not every user journey converts on my preferred schedule. Retention requires patience as well as tactics.
Revenue follows the value curve
Price and conversion pull against each other. As price rises, fewer people may convert; as it falls, more may enter but each transaction contributes less.
The product manager's task is not simply to pick one point on that curve. It is to understand the different shapes of value underneath it. A subscription, a bundle or a smaller in-app purchase can serve different levels of need without turning the product into a collection of traps.
Designing those offers well is a high-leverage skill. Monetisation works best when the offer makes the value easier to choose, not harder to understand.
Referral needs its own reason
I had written 5% as a referral benchmark. I would now treat any global benchmark as a question to investigate, not as a law to obey. Products have different users, different levels of trust and different reasons to be shared.
The better question is: what makes this product worth mentioning to another person?
Every traction channel has a different benefit. Referral should therefore have a clear path and a benefit that fits the product rather than a generic reward attached at the end.
The operating loop
When I compress the diary pages, the loop looks like this:
- Define the user and the problem.
- Ship the smallest version that can create an aha moment.
- Watch the full journey from acquisition to revenue.
- Talk to the users who would genuinely miss the product.
- Prioritise their recurring problems with reach, impact, confidence and effort in view.
- Improve the product's reason to return.
- Repeat.
App Store optimisation, benchmark tests and tools such as Google Play Console can help me see the system. They are instruments, not the system itself. The work still comes back to reducing a real difficulty for a real person and learning whether I succeeded.
Small changes ripple outward. The product is never only the thing I launch; it is what I learn to improve after it meets the world.