Turning avoidance
into activation.

Deathwishes sits in a high-intent, high-avoidance category. People understand that legacy planning matters. They avoid it because it feels morbid, legalistic, asset-coded, and too far away. The product can be excellent and the funnel will still collapse at the door.

That collapse is the brief. Not a positioning brief — an activation brief. The work isn't to acquire more skeptics into the same flow; it's to lower the emotional cost of starting, give the first session a meaning it didn't have before, and instrument the system carefully enough to know which moments actually moved someone from installed to committed.

Three forces compound the avoidance, and each shaped a different part of the operating system that follows.

Emotional friction is the dominant cost.

Most categories trade in money, time, or status. This one trades in mortality. Standard onboarding patterns — feature tours, checkbox progress, gamified streaks — read as wrong when the underlying task is imagine attending your own funeral. The product needs softer entry points and a tone that earns the next tap.

The trigger is unpredictable.

There is no monthly buying window. People arrive after a diagnosis, a death in the family, a milestone birthday, a re-read of a will. Acquisition can't be optimized around a calendar; it needs to be optimized around readiness. Lifecycle has to hold the relationship between visits that may be months apart.

Trust is the unit of conversion.

The product asks for medical directives, financial logins, the names of children, the wording of an obituary. If the welcome email, the first prompt, or the paywall tone breaks faith even slightly, the user leaves and does not come back. Every system below — onboarding, lifecycle, paywall, instrumentation — is calibrated to that fragility.

The competitive set sells legal completeness. Trust & Will, FreeWill, Cake — all framed as a task to finish. That framing inherits the avoidance: the headline reads as homework, the CTA reads as obligation, the abandonment is structural.

The reframe is small but load-bearing. Deathwishes is a personal archive — a place to leave the playlist, the toast, the recipe, the apology, the password — that happens to also organize the legal and logistical work. The legal stuff is what you do because you opened the app. The legacy stuff is why you opened the app.

That move did three things at once: it unlocked a different content surface (prompts about life, not just about death), a different lifecycle (return for meaning, not just for compliance), and a different price point — habit, not transaction.

The content system has two surfaces: Plans (the prompts a user fills in) and Lifetime (the artifacts they accumulate — playlists, bucket list, "My Story" micro-journals, vault items). Plans is the activation surface; Lifetime is the retention surface.

Plans is sequenced into three tiers — The Basics, Beyond the Basics, and My Legacy — and every prompt carries scaffolding copy that does the emotional work the question itself can't. The scaffolding isn't decoration. It is the product. It tells you that other people have answered this. It explains why an option exists. It makes a strange question feel routine.

Below are real prompts from the live content system, exactly as they ship in the app. The structure repeats: a question, a set of choices that lower the activation cost, and a paragraph of warm explanation that says here is what other people have done.

The Basics opens with What should happen to your body? — concrete, optionable, finite. It is the question every user assumes a death-planning app will ask, so answering it confirms the product is the product.

My Legacy arrives after the user has invested. By the time we ask What are you most proud of?, the user has already trusted the product with body and service decisions. The hard, meaningful question is now safe.

Beyond the Basics — healthcare, financial, legal — is intentionally last. These are the questions a legal product would lead with. They are the questions that, asked too early, cause users to close the app and never reopen it. The product earns the right to ask them.

The onboarding instrument has three events — onboarding_step, onboarding_complete, and the first complete_category1_subcategory1 ("My Body" finished). Each is wired to a different post-event consequence, and the gaps between them are where retention is won or lost.

The activation contract — articulated in the welcome email, repeated by lifecycle, reinforced by the home feed — is small enough to keep: one answer. One moment. You can come back. The product is explicit that it does not need to be finished. That single permission is the largest behavioral change vs. the category default.

The first-launch QA pass treated every onboarding screen as a trust contract: persistence on refresh, no skipped state, no silent failures on the verification email, no orphan accounts after deletion. From the live Q3 backlog: account deletion process does not work — can still log in with same credentials after deleting an account. Marked High priority. Shipped to staging within the sprint.

That same backlog includes "improve the quality of the email confirmation email (to avoid going to spam)" — a marketing-domain ticket living inside the product roadmap. The line between PMM and product engineering is not maintained, because the user can't see the line and neither can the funnel.

The lifecycle architecture maps every meaningful state — installed, account, trial, paid, renewed, expired, canceled — to a specific event, a system of record, and a campaign. The map below is the working version that shipped: which event fires, which system originates it, and what the user receives downstream.

The non-obvious work is the identity bridge. RevenueCat issues an anonymous app_user_id on install. Customer.io expects an email. The backend produces a user_id only after registration. Without a deliberate plan, those three IDs never reconcile and the lifecycle silently breaks at the account-created handoff. The architecture below resolves it: app calls Purchases.identify(user_id) and Purchases.setAttributes({ email, $customerioId }), so RevenueCat syncs the email to Customer.io against a shared identifier and the same person carries through every subsequent event.

The Firebase taxonomy ships with 90+ events across 12 app sections. Of those, only a small set are flagged as conversion events — the ones GA4, RevenueCat, and the media plan use to score channels and cohorts. Another small set are flagged as in-app feed events — the ones that surface back into the activity feed and create the "I see myself in the product" moment that drives return.

The discipline is what the taxonomy doesn't tag. view_inspiration is not a conversion. profile_color_updated is not a feed event. The line between "we track it" and "we optimize against it" is enforced by a column, and that column is what makes the funnel readable to a non-analyst.

The pricing decision is downstream of the positioning. If the product is a legal task, price scales with the document — $99 for a will, $200 for a trust. If the product is a personal archive, price scales with the habit — coffee money, paid once a year, no decision fatigue.

The trial does the heavy lifting. The user starts 7 days free, RevenueCat fires trial_started, Customer.io sends the trial activation message, and the user has a week to see whether the practice fits their life. If they convert, initial_purchase fires and the subscriber-onboarding series begins. If they don't, trial_expired fires and a discounted winback runs at day 1, day 7, day 30.

Every monetization signal is owned by RevenueCat and forwarded to Customer.io. Payment failures, refunds, cancellations — they all flow through the same pipe. The operator does not need a separate billing dashboard to know the state of the business.

Branch is the deep-link and click-attribution layer. AppsFlyer was integrated at Ticket Timeline as the MMP of record; the same playbook informs Deathwishes' channel measurement and gives the team a clean view of which campaigns actually drove installs vs. which ones merely correlated with them. Firebase + GA4 own the post-install funnel.

The discipline is not the tools — it is the signal model. CPI is measured on Branch installs. CAC is measured on registered users, not installs. ROAS is measured on RevenueCat revenue, not in-app event proxies. Each channel is judged on the metric it actually controls, which is the difference between a media plan that learns and one that just spends.

The launch plan is small on purpose. The point of the first paid quarter is not volume — it is calibration: which channel actually clears the trust bar, which audience converts post-install, which week's cohort retains into renewal. The numbers below are the live model; each row is judged on its own CAC and download-to-user conversion.

Direct & organic show the floor. Search ads carry the volume. App store ads carry the efficiency (CPI $3.08, CAC $12.31). Paid social is the most expensive on a per-user basis ($13.51) but earns its place by retargeting site visitors who already self-selected. Offline (launch party, networking) is intentionally inefficient on CPI because it pays back in seed-stage signal, not installs.

The launch timeline is not a marketing schedule with a product side. It is a single operating cadence: feature work, instrumentation, paywall integration, and lifecycle copy live in the same backlog, sequenced so each piece unblocks the next. Marketing soft launch begins only after the activation event chain is wired; paid full launch begins only after RevenueCat is in production.

The QA backlog is the second discipline. The Q3 production board ran 16 high-priority items in parallel — paywall integration, activity-log eventing, Branch SDK install, Customer.io SDK install, GA4 data-stream config, account-deletion fixes, friend/legacy-contact privacy defaults — each tracked with an estimation in hours and a release tag. That backlog is the operating system. PMM lives in it.

The reason a single operator can take a sensitive consumer subscription from concept to App Store in three months — and then maintain a 90-event taxonomy, a four-system lifecycle, a quarterly media model, and a production QA backlog — is not unusual hours. It is the compression of the loop between noticing and shipping.

Customer-research synthesis through Claude. Spec-drafting through Codex and Cursor. Flutter implementation against the live RevenueCat / Customer.io / Branch APIs, with the operator reading the code that ships. Email copy iterated against tone references, not templates. The lifecycle copy in this case study, the event taxonomy, the prompt scaffolds — none of it left the operator's hands to get drafted, reviewed, and shipped.

The result is not a faster PMM. It is a different shape of PMM — one who shows up to a design review with the spec already written, the events already named, the welcome email already in Customer.io, and the question on the table being whether the activation moment lands.