Product Metrics, Launches and Working with Engineering and Design

A city bike-share app launches a redesigned map. Downloads go up that week and the team celebrates. A month later, the number of rides per member has not moved, and support is receiving messages from people who could not unlock a bike. The team measured the number that was easy to see and not the one that reflected the product's purpose. Choosing metrics, shipping carefully and working well with the people who build the product are three parts of one job.

North-star and input metrics

A north-star metric is the single number that best captures whether customers are getting the value your product exists to deliver. It should reflect value delivered, not effort or vanity. For the bike-share app, "downloads" is a vanity number. A better north-star is something like "completed rides per active member per week", because a ride completed means someone found a bike, unlocked it and got where they were going.

A north-star moves slowly and no one can change it directly. Teams therefore work on input metrics: the smaller numbers that feed it and that a team can influence in a sprint. Each team should be able to say which input it owns and how its work is meant to move it.

NORTH STAR
  Completed rides per active member per week

INPUT METRICS (what feeds it)
  1. Findability   - % of map searches that show a bike within a short walk
  2. Unlock success - % of unlock attempts that work on the first try
  3. Time to ride   - median seconds from opening the app to bike unlocked
  4. Return rate    - % of members who ride again within 7 days

GUARDRAIL METRICS (must not get worse)
  - Support tickets per 1000 rides
  - Bike damage or theft reports per 1000 rides
  - App crash rate

COUNTER-CHECK
  If rides rise but guardrails worsen, the win is not real.

Guardrails stop you from winning the wrong way. If you push the ride count up by removing a safety step, the rides rise and trust falls. Pair every growth metric with at least one number that would reveal that kind of damage. And remember that when a metric becomes a target people start optimising the number rather than the goal, so keep looking at the underlying behaviour as well as the figure.

A launch checklist

A launch is a sequence of risk-reducing steps, not a single moment. Ship small and to a limited group first if you can, using a feature flag, so that problems are found by a small share of users and can be switched off without a new release.

BEFORE LAUNCH
[ ] Success metric, target and review date written down
[ ] Guardrail metrics are being tracked and have alert thresholds
[ ] Acceptance criteria all passed in a test environment
[ ] Edge cases tried on real devices (slow network, small screen, old OS)
[ ] Feature flag in place; who can turn it off is named
[ ] Rollback plan: what exactly happens if we switch it off at 2 am?
[ ] Support team briefed, with a short FAQ and known issues list
[ ] Help text, emails and store listing updated
[ ] Legal / privacy / accessibility checks complete where relevant

LAUNCH
[ ] Start with a small group (an internal group or a small share of users)
[ ] Watch the dashboard for a fixed window, with someone on call
[ ] Decide go/no-go to widen based on pre-agreed thresholds
[ ] Announce internally, then to customers, in that order

AFTER LAUNCH
[ ] Review the metric on the date you set, not when it looks good
[ ] Read support tickets and user feedback by hand
[ ] Write down what you learned, including what you would change
[ ] Remove temporary flags and dead code

Working with engineering: a good planning conversation

Product managers are not the bosses of engineers. The best working relationships treat engineers as partners who understand the system and see risks you cannot. The most useful habit is to bring the problem and the constraints rather than a finished solution, and to bring them early, while engineers can still influence the design.

1. Share context ahead of time. Send the one-page PRD and the evidence a day before the meeting, so people arrive with questions and not first impressions.
2. Start with the problem and the goal. Spend the first few minutes on who is affected and what success looks like.
3. Ask for options, not just estimates. "What is the simplest version that tests this?" often yields a smaller first release.
4. Name the appetite. Say how much time the problem is worth, so the team can shape a solution to fit it rather than being handed a fixed scope and a fixed date.
5. Surface risks and unknowns together. Ask "What would worry you about this?" and write the answers down.
6. Agree what is cut first. Decide in advance which part drops if time runs short.
7. Leave with owners and dates. End with who is doing what and when you will check in.

PM:   "Here is the problem: riders cannot find a nearby bike and some give
      up. We think about two weeks of effort is worth spending. The
      measure is the share of searches that show a bike within a short walk.
      I do not have a solution picked. What would you try first?"

Eng:  "The map data is stale for up to five minutes. We could fix that, or
      show a 'last updated' label."

PM:   "What does each option cost, and what would we learn from the cheaper one?"

Eng:  "The label is a couple of days and tells us if freshness is the issue.
      Fixing the sync is a week and a half."

PM:   "Let us ship the label first and decide on the sync once we see the data.
      What would worry you about that?"

Working with design

Involve the designer when you are still defining the problem, not after the requirements are fixed. Share the evidence from your interviews, agree on the goal, and let them explore options. When giving feedback on a design, describe the effect on the user ("I think riders may miss this button in sunlight") rather than prescribing a fix ("make it bigger and red"). The structure in How to Give and Receive Feedback works well for this.

Common mistakes

• Celebrating vanity metrics. Symptom: downloads or page views climb while rides, purchases or retention stay flat. Anchor on value delivered.
• A north-star with no owners. Symptom: everyone agrees it matters and no team can say what they did to move it. Break it into inputs and assign owners.
• Launching to everyone at once. Symptom: a bug reaches all users and the only fix is an emergency release. Use flags and staged rollouts.
• Handing engineers a finished spec in the meeting. Symptom: silence, then objections two weeks later. Bring the problem and options early.
• Skipping the review. Symptom: nobody knows whether the feature worked, so the team never learns. Put the review date in the calendar before launch.

How this shows up in real projects and interviews

In day-to-day work, you will spend more time on follow-ups than on launches: checking dashboards, answering questions, resolving trade-offs. Teams that stay aligned usually do so through small habits: a written goal, a visible metric, a regular check-in and honest postmortems. If you are early in your career, offering to own the post-launch review is a quick way to gain trust.

In interviews, expect questions such as "What is the north-star metric for a music app?" or "How would you know this launch worked?" A good answer names the value delivered, lists two or three inputs, mentions a guardrail and describes how you would roll out. Reasoning like this matters more than a clever metric name. To find product roles to practise on, you can browse current openings on the jobs page and compare what each description asks for.