I took Daily Diary from 0.5% to 12% of weekly active users, and adoption held between 10% and 15% for six months.

Role

Product Manager, owned the feature end to end

Team

Me, as product manager, designer and engineer

Timeline

August 2024 to January 2026, then six months of post-implementation measurement

Users

Patients on a rare disease health platform, plus the research clients who rely on their data

Metrics

Weekly adoption 0.5% to 12%, held at 10% to 15% for six months

I ran a round of patient conversations before building anything. Patients who had tried the diary once told me they did not see enough value in what they had recorded to come back. A discoverability fix alone would have brought people in once and lost them again.

• "I filled it in for a week and then nothing happened. What was it for?"
• "I would do it if I could see whether my bad days line up with anything."

1. 01

   Split the work by the problem it solved, not by the screen it touched

   Two problems needed two kinds of fix. Finding the feature and having a reason to return are different jobs, and I wanted to be able to tell which change moved the number.

   Tradeoff. Sequencing the releases slowed the headline number by a few weeks, but it meant the adoption chart could show what each change did.

2. 02

   Finding it: a post-login prompt that people can dismiss, plus persistent quick access

   The prompt had to interrupt once and then get out of the way. A "don't show again" option kept it from becoming nagware, and a quick-access entry point gave people a path back after they dismissed it.

   Tradeoff. Some teammates wanted the prompt to persist until the first entry. I argued that forcing it would cost us trust with exactly the patients we were trying to win.

3. 03

   A reason to return: richer charts and notes for reflection

   Patients wanted to see patterns in their own data. Charts that showed a week or a month at a glance, with notes attached to the days that mattered, gave the diary a payoff beyond the act of filling it in.

   Tradeoff. This was the most expensive piece of the work. I cut a planned export feature to make room for it, because reflection in the app was the thing patients had actually asked for.

4. 04

   Understanding the value: lifecycle emails that explained what tracking could show you

   People who had never tried the diary did not know what they would learn from it. A short series of emails, timed to the first weeks after sign-up, explained the value in patients' own terms.

   Tradeoff. Email volume is a sensitive thing on a health platform. I kept the series short and made every message easy to opt out of.

Each change shipped with a before-and-after comparison on weekly adoption, so the chart could show what each one did. After the last release I spent six months on the post-implementation data, watching whether adoption held rather than spiked, and ran a second round of patient interviews to check that the numbers meant what I thought they meant.

• Weekly adoption rose from 0.5% to 12% of weekly active users.
• Adoption held between 10% and 15% for six months after the last change shipped. The holding number is the retention proof.

Discovery gets someone to try a feature. Value gets them to return. You need both, and the dashboard will usually only show you the first one.

• →Test a weekly summary notification that shows the patient one pattern from their own data, to see whether it lifts the return rate further.
• →Try a shorter first-run flow that asks for one data point instead of a full entry, and measure whether the easier start changes the six-month hold.

Activation, onboarding and lifecycle messaging sit at the centre of growth and self-serve PM roles. I have used lifecycle messaging to drive feature adoption, and I measured whether people kept coming back. The onboarding prompt pattern here (show once, let people dismiss it, keep a quick path back) is the same thinking any product's or agent's first-run experience needs.