Skip to content
pm-skills

Brainshelf: Follow the Product

Post-seed, ~20 employees, ~22,000 MAU. Building Resurface: contextual morning email digest.

Prompt style: Casual: rough, fast, enough context to work. Bullet points and shorthand.

Phase: Foundation

Section titled “Phase: Foundation”

Build Risk Review

Section titled “Build Risk Review”

Brainshelf consumer PKM app - whether to build AI auto-tagging as a new bet before validating demand

Full output: Build Risk Review

Build Risk Review: AI auto-tagging

Section titled “Build Risk Review: AI auto-tagging”

Mode: Pre-build | Date: 2026-06-22

Lean Canvas

Section titled “Lean Canvas”

Brainshelf Resurface lean canvas for framing the morning email digest as a retention and referral lever in a consumer PKM app

Full output: Lean Canvas

Lean Canvas: Brainshelf Resurface

Section titled “Lean Canvas: Brainshelf Resurface”

Created: 2026-04-15 Author: Brainshelf PM Mode: content Overall confidence: Low-Medium Purpose: New feature thesis. Pre-scope sanity check and board-update anchor.

Meeting Agenda

Section titled “Meeting Agenda”

resurface-algo-review

Full output: Meeting Agenda 
---
artifact_type: meeting-agenda
version: 1.0
generated_at: 2026-04-20T08:30:00Z
generated_by_skill: foundation-meeting-agenda


meeting_title: "Resurface Algorithm Review"
meeting_date: 2026-04-22
meeting_start_time: "11:00 PT"
meeting_type: review
meeting_duration_minutes: 45


project: resurface
topics:
  - current-behavior
  - option-a-recency-weighted
  - option-b-topic-clustered
  - direction-decision


attendees:
  - name: priya-pm
    role: decision-maker
  - name: elena-algo
    role: contributor
  - name: mia-design
    role: contributor


desired_outcomes:
  - "Shared understanding of current Resurface algorithm's observed user behavior"
  - "Direction committed for next sprint (Option A, Option B, or hybrid)"
  - "Owner and success metrics assigned for chosen direction"


related_brief: null
input_quality: medium
confidence: medium
visibility: team
status: draft
---


# Resurface Algorithm Review


</details>


---


### Meeting Brief


*curator-tier-pitch*


:::note[Prompt]

foundation-meeting-brief “weekly product mtg tomorrow, pitching curator tier to leo and noor, leo prob skeptical noor open, 30 min”

:::


<details>
<summary>Full output: Meeting Brief</summary>


```markdown
---
artifact_type: meeting-brief
version: 1.0
generated_at: 2026-04-19T18:00:00Z
generated_by_skill: foundation-meeting-brief


meeting_title: "Curator Tier Pitch at Weekly Product Meeting"
meeting_date: 2026-04-20
meeting_start_time: "10:00 PT"
meeting_type: stakeholder-review


project: curator-tier
topics:
  - tier-pitch
  - concerns
  - decision-or-defer


attendees:
  - name: priya-pm
    role: contributor
  - name: leo-cofounder-1
    role: decision-maker
  - name: noor-cofounder-2
    role: decision-maker


stakeholders:
  - name: leo-cofounder-1
    position: "⚠ likely skeptical of subscription expansion [inferred: medium]"
  - name: noor-cofounder-2
    position: "⚠ open-but-not-committed [inferred: medium]"


primary_ask: "greenlight for a 4-week Curator tier experiment with explicit kill criteria"


related_agenda: null


input_quality: low
confidence: medium
visibility: private
status: draft
---


# Meeting brief: Curator Tier Pitch at Weekly Product Meeting


</details>


---


### Meeting Recap


*resurface-scope-cut*


:::note[Prompt]

foundation-meeting-recap @priya-notes.md

:::


<details>
<summary>Full output: Meeting Recap</summary>


```markdown
---
artifact_type: meeting-recap
version: 1.0
generated_at: 2026-04-15T21:45:00Z
generated_by_skill: foundation-meeting-recap


meeting_title: "Resurface Sprint Scope Cut"
meeting_date: 2026-04-15
meeting_start_time: "13:00 PT"
meeting_type: decision-making


project: resurface
topics:
  - scope-cut-decision
  - kept-scope-confirmation


attendees:
  - name: priya-pm
    role: decision-maker
  - name: elena-algo
    role: contributor
  - name: mia-design
    role: contributor
attendees_absent: []


related_agenda: null
related_brief: null


agenda_reconciliation:
  topics_planned: []
  topics_hit: [scope-cut-decision, kept-scope-confirmation]
  topics_skipped: []
  topics_emerged: []


meeting_quality:
  outcomes_achieved: "no agenda outcomes to reconcile"
  started_on_time: null
  ended_on_time: null
  key_attendees_present: true


meeting_type_source: inferred
unassigned_action_ratio: 0.0


input_quality: medium
confidence: medium
visibility: team
status: draft
---


# Meeting recap: Resurface Sprint Scope Cut


</details>


---


### Meeting Synthesize


*resurface-design-iteration*


:::note[Prompt]

foundation-meeting-synthesize @resurface-*.md

:::


<details>
<summary>Full output: Meeting Synthesize</summary>


```markdown
---
artifact_type: meeting-synthesis
version: 1.0
generated_at: 2026-04-05T11:00:00Z
generated_by_skill: foundation-meeting-synthesize


project: resurface
topics:
  - algorithm
  - ux
  - notification-timing


time_range:
  start: 2026-01-15
  end: 2026-03-31


scope_filter: "project=resurface"


source_meetings:
  - 2026-01-20_11-00PST_resurface-kickoff_recap.md
  - 2026-02-03_11-00PST_resurface-algo-v0_recap.md
  - 2026-02-17_11-00PST_resurface-notification-copy_recap.md
  - 2026-03-03_11-00PST_resurface-user-feedback-session_recap.md
  - 2026-03-17_11-00PST_resurface-algo-v1_recap.md
  - 2026-03-31_11-00PST_resurface-ux-refinement_recap.md


input_quality: medium
confidence: medium
visibility: team
status: draft
---


# Meeting synthesis: Resurface Design Iteration Q1 2026


</details>


---


### OKR Writer


*Brainshelf prosumer knowledge tool. Resurface team Q3 2026 OKR set following the March 2026 algo v1 ship and beta validation.*


:::note[Prompt]

foundation-okr-writer

Scope: Resurface team, Brainshelf Cycle: Q3 2026 (July 1 to September 30) Level: team OKR type: aspirational

Strategic context:

  • Company objective: increase 30-day member retention from 31% to 42% [fictional] by year-end 2026.
  • Resurface team owns the algorithm-driven content surfacing system.
  • Algo v1 shipped March 2026; beta cohort showed 3.4x retention lift vs control [fictional]; rolled out to all activated users in May.

Empowerment signal: empowered team. Leadership picks problems, team picks KRs and bets.

Draft objective: “Resurface should be the reason people come back.”

Candidate KRs (rough):

  • More weekly engagement with Resurface
  • Resurface-engaged users retain better
  • Don’t surface low-quality items

Constraints:

  • Engineering capacity: 3 engineers, 1 ML engineer, 1 designer
  • No new platform dependencies
  • Cannot influence top-of-funnel acquisition (other teams)

Source of truth: company OKR doc in Linear at L-OKR-Q3-Resurface

:::


<details>
<summary>Full output: OKR Writer</summary>


```markdown
# OKR Set: Brainshelf Resurface Team, Q3 2026


(Mode: Guided. Empowered-team signal: empowered. Disclosure section omitted.)


</details>


---


### Persona (Marketing Brief)


*Brainshelf marketing persona for newsletter-creator acquisition and content-curation positioning*


:::note[Prompt]
```text
foundation-persona marketing brief


marketing persona for newsletter creator acquisition channel.


context: brainshelf users who share 3+ items/week have 3.4x retention
and 2.1 referral signups/quarter [fictional]. newsletter creators are
a natural fit because they already curate. want a persona for
acquisition messaging and potential "Curator" tier positioning.


competitors in this space: Readwise Reader, Raindrop, Pocket.
keep it brief but actionable for growth experiments.

:::

Full output: Persona (Marketing Brief)

Persona Dossier: Amara Osei, The Creator Who Curates Before She Writes (Marketing, Brief)

Section titled “Persona Dossier: Amara Osei, The Creator Who Curates Before She Writes (Marketing, Brief)”

Persona (Marketing Detailed)

Section titled “Persona (Marketing Detailed)”

Brainshelf Resurface marketing persona for freemium-to-paid conversion strategy and subscription messaging

Full output: Persona (Marketing Detailed)

Persona Dossier: Jess Okafor, The Reluctant Subscriber (Marketing)

Section titled “Persona Dossier: Jess Okafor, The Reluctant Subscriber (Marketing)”

Persona (Product Brief)

Section titled “Persona (Product Brief)”

Brainshelf Resurface activation persona for early-retention product decisions

Full output: Persona (Product Brief)

Persona Dossier: Maya Torres, The Habit Builder Under Time Pressure (Product, Brief)

Section titled “Persona Dossier: Maya Torres, The Habit Builder Under Time Pressure (Product, Brief)”

Persona (Product Detailed)

Section titled “Persona (Product Detailed)”

Brainshelf Resurface product persona for power-curator workflows and advanced resurfacing customization

Full output: Persona (Product Detailed)

Persona Dossier: Tomás Reyes, The Architect of His Own Library (Product)

Section titled “Persona Dossier: Tomás Reyes, The Architect of His Own Library (Product)”

Prioritized Action Plan

Section titled “Prioritized Action Plan”

Brainshelf consumer PKM app. The Resurface morning digest launched six weeks ago with bimodal click-through; the solo PM dumps rough context and needs a ranked plan before the next board update.

Full output: Prioritized Action Plan

Step 0: Source ledger

Section titled “Step 0: Source ledger”
S1: "open rate on the digest is ok (~38% [fictional]) but click-through is all over the place" (origin: pasted prompt)
S2: "small cohort (~12%) clicks every day, rest basically never click" (origin: pasted prompt)
S3: "marco thinks the digest timing is wrong, chloe thinks it's relevance (we resurface stuff people don't care about anymore)" (origin: pasted prompt)
S4: "surveys are contradictory - power users say "love it", others say "felt random" or "too much"" (origin: pasted prompt)
S5: "we have ~2 sprints before the next board update, want to show movement" (origin: pasted prompt)
S6: "20 person team, i'm wearing the PM + launch hat" (origin: pasted prompt)

Section 0. Executive summary

Section titled “Section 0. Executive summary”
  • Situation classification: Complex (Cynefin). Engagement is bimodal (S2), internal theories conflict (S3), and surveys contradict each other (S4), so the cause is not yet knowable.
  • The binding constraint: you do not know what distinguishes the 12% who click daily from everyone else. Tuning timing or relevance now is a guess.
  • The critical next effort (P1): run a safe-to-fail probe to find the distinguishing factor before changing the digest.
  • Overall plan confidence: Low-Medium. Honest: the team is arguing from anecdote, not evidence.
  • Time-to-value: about one sprint to a first read on what the engaged cohort shares.

Section 1. Input mirror - what I understand

Section titled “Section 1. Input mirror - what I understand”
  • What you gave me: Resurface opens fine but click-through is bimodal (S1, S2); marco and chloe disagree on whether it is timing or relevance (S3); surveys are contradictory (S4); you have two sprints before a board update (S5) and are running solo (S6).
  • What you appear to be trying to accomplish: find a real lever for Resurface engagement and show movement to the board. Confidence: Low-Medium (intent inferred from the dump).
  • Adjacent intents I noticed but did not assume: changing digest timing, and a relevance/algorithm rework. Neither is assumed to be the fix.

Section 2. Situation classification (Cynefin)

Section titled “Section 2. Situation classification (Cynefin)”

Domain: Complex. Source: S2, S3, S4.

The test for Complex is whether the outcome is genuinely unpredictable, and it is here. The behavior is bimodal with no known cause (S2), two reasonable people hold opposite theories (S3), and the survey signal contradicts itself (S4). You cannot analyze your way to the answer from this; you have to probe and sense. Posture: safe-to-fail experiments. Confidence ceiling: Medium-Low, and no High marker appears anywhere in this plan.

Section 3. The binding constraint (Theory of Constraints)

Section titled “Section 3. The binding constraint (Theory of Constraints)”
  • System and goal: make Resurface a habit for more than the current minority.
  • The constraint: missing insight into what the daily-clicking 12% have in common (S2). Every proposed fix (timing, relevance) is a bet on an unvalidated theory. Call this the primary planning bottleneck.
  • Source: S2, S3.
  • Candidate constraints considered: (1) Timing (marco’s theory, S3). Plausible but untested. (2) Relevance (chloe’s theory, S3). Equally plausible and untested. Both are subordinate to learning what actually separates engaged from disengaged users.
  • Why P1 lifts it: identifying the distinguishing factor turns the timing-vs-relevance argument into an evidence-backed choice.

Section 4. Prioritized questions, gaps, and open decisions

Section titled “Section 4. Prioritized questions, gaps, and open decisions”
RankQuestion / gapWhy it mattersDecision required?How to resolve
Q1What do the daily-clicking 12% share? (S2)Determines whether timing, relevance, or something else is the leverNo, resolve by probeProfile the engaged cohort vs the rest
Q2Is it timing or relevance? (S3)Settles the marco-vs-chloe split with evidenceNo, resolve by probeRun small parallel probes, not a debate
Q3What does “show movement” mean for the board? (S5)Sets a realistic two-sprint goalYesPM picks a learning-based success signal
Q4Can a solo PM run two probes in two sprints? (S6)Bounds the plan to capacityYesScope probes to the cheapest viable versions

Section 5. The prioritized action plan

Section titled “Section 5. The prioritized action plan”

P1. Profile the engaged cohort (probe)

Section titled “P1. Profile the engaged cohort (probe)”
  • Why: lifts the constraint by finding what the 12% share (S2); this is a probe to learn, not a commitment.
  • What: a read on the differences between daily-clickers and non-clickers (content types saved, recency, source, account age).
  • How: (1) Segment users by click behavior. (2) Compare saved-content and usage attributes. (3) Interview 4 to 5 from each group.
  • Confidence: Low-Medium. Respects the Complex ceiling.
  • Source: S2, S4.
  • Expected outcome / success signal: a candidate distinguishing factor to test in P2/P3.
  • Estimated effort: about one sprint (S5).
  • Dependencies: none.

P2. Relevance probe (safe-to-fail)

Section titled “P2. Relevance probe (safe-to-fail)”
  • Why: tests chloe’s theory (S3) cheaply by improving what is resurfaced for a small cohort.
  • What: a reversible relevance tweak (recency-weighted or topic-matched) for a test group.
  • How: (1) Pick the simplest relevance change. (2) Ship to a small cohort behind a flag. (3) Measure click-through vs control.
  • Confidence: Low-Medium. It is a probe; expect to learn, possibly to revert.
  • Source: S3.
  • Expected outcome / success signal: a measurable click-through lift, or a clear null.
  • Estimated effort: part of one sprint, parallel to P1.
  • Dependencies: none.

P3. Timing probe (safe-to-fail)

Section titled “P3. Timing probe (safe-to-fail)”
  • Why: tests marco’s theory (S3) without committing to a redesign.
  • What: a small experiment varying digest send time for a cohort.
  • How: (1) Define two or three send windows. (2) Assign cohorts. (3) Compare open-to-click behavior.
  • Confidence: Low-Medium.
  • Source: S3.
  • Expected outcome / success signal: evidence that timing does or does not move clicks.
  • Estimated effort: one sprint, lightweight.
  • Dependencies: none; can follow P1 if capacity (S6) is tight.

Sequencing (Now / Next / Later)

NowNextLater
P1, P2 (parallel)P3Commit a direction after probe readouts

What to defer / what NOT to do

  • Do not pick timing or relevance by debate (S3); let the probes decide.
  • Do not rebuild the digest before P1 names the distinguishing factor.
  • Do not over-read the “love it” survey quotes (S4); they are the engaged minority talking.

Section 6. Risks and pre-mortem

Section titled “Section 6. Risks and pre-mortem”
RiskLikelihoodImpactEarly signalMitigationSource
The 12% are simply your most active users, not winnable signalMHP1 shows engagement tracks overall app activityReframe the goal around activation, not the digestS2
Solo capacity can’t run two probes in two sprintsMMP1 slips past sprint oneRun P1 first; defer P3S6
Board pressure forces a “fix” before probes readMHA timing/relevance change ships before P1Frame the board update around the learning plan (S5)S5
Section titled “Section 7. Recommended pm-skill prompts (copy/paste ready)”

To execute P2 and P3: design the probes

Section titled “To execute P2 and P3: design the probes”

Skill: measure-experiment-design Why this skill: both probes need explicit hypotheses, metrics, cohorts, and kill criteria so two sprints produce evidence, not noise. Source: S3, S5

Prompt:

Design two safe-to-fail experiments for the Brainshelf Resurface digest, where click-through is bimodal (about 12% click daily, the rest rarely). Experiment A tests relevance (a recency-weighted or topic-matched resurfacing change for a small cohort); Experiment B tests send timing across two or three windows. For each, state the hypothesis, the metric, the minimum cohort, the read window (we have ~2 sprints), and the kill criterion. Keep both reversible and runnable by a solo PM.

To execute P1: synthesize the cohort interviews

Section titled “To execute P1: synthesize the cohort interviews”

Skill: discover-interview-synthesis Why this skill: P1’s interviews with engaged and disengaged users need to become a pattern, not a pile of quotes. Source: S2, S4

Prompt:

Synthesize 8 to 10 short interviews with Brainshelf users split between daily Resurface clickers and non-clickers. Surface what distinguishes the engaged cohort (content types, saving behavior, recency, account age), reconcile the contradictory survey signal (some say “love it”, others “felt random” or “too much”), and flag where the sample is too thin to generalize.

Section 8. Evidence and source map

Section titled “Section 8. Evidence and source map”
Claim / recommendationSource IDExact quote
Engagement is bimodalS2”small cohort (~12%) clicks every day, rest basically never click”
Click-through is erraticS1”open rate on the digest is ok (~38% [fictional]) but click-through is all over the place”
Internal theories conflictS3”marco thinks the digest timing is wrong, chloe thinks it’s relevance (we resurface stuff people don’t care about anymore)“
Survey signal contradicts itselfS4”surveys are contradictory - power users say “love it”, others say “felt random” or “too much""
Two-sprint horizonS5”we have ~2 sprints before the next board update, want to show movement”
Solo capacityS6”20 person team, i’m wearing the PM + launch hat”

Inferred (Low confidence) claims: none load-bearing. Every effort cites a real quote; the plan is probes by design. Evidence gaps: the entire plan rests on unexplained bimodal behavior. P1 exists to close that gap. No High confidence marker appears anywhere, by design.

Stakeholder Briefings

Section titled “Stakeholder Briefings”

Brainshelf consumer PKM app - the guilt-pile interview synthesis (why users save but never return) fanned out to design, product-marketing, and executive lenses to align before scoping a solution

Full output: Stakeholder Briefings 
# Stakeholder briefings: The "guilt pile" - why users save but don't return


</details>


---


### Stakeholder Briefings


*Brainshelf consumer PKM app - the email-digest-vs-in-app-card A/B experiment results fanned out to the data, executive, and product-marketing lenses after the test concluded*


:::note[Prompt]

/foundation-stakeholder-briefings @resurface-ab-results.md

email vs in-app a/b is done, email won on clicks. need 3 versions:

  • chloe/data (the real read + caveats)
  • marco (ship or not)
  • pmm (is there a story here) go
:::


<details>
<summary>Full output: Stakeholder Briefings</summary>


```markdown
# Stakeholder briefings: Resurface email-vs-in-app A/B results


</details>


---


### Stakeholder Briefings


*Brainshelf consumer PKM app - the Resurface App Store launch plan fanned out to product-marketing, customer-support, and executive lenses ahead of release*


:::note[Prompt]

/foundation-stakeholder-briefings @resurface-launch-plan.md

resurface ships in the next app store update. need:

  • pmm: store listing + announce
  • support: what people will ask
  • marco: launch day go/no-go casual is fine. go
:::


<details>
<summary>Full output: Stakeholder Briefings</summary>


```markdown
# Stakeholder briefings: Resurface App Store launch


</details>


---


### Stakeholder Briefings


*Brainshelf consumer PKM app - the Resurface trigger-model pivot fanned out to executive, engineering, and board lenses, deliberately splitting the operational go-call (Exec) from the strategy/capital narrative (Board)*


:::note[Prompt]

/foundation-stakeholder-briefings @resurface-pivot-decision.md

pivoting resurface from time-based digest to extension-triggered contextual (surface a related saved item when you finish reading something). need:

  • exec/marco: the actual go call
  • alex/eng: what it takes to build
  • board: the strategy version (make this clearly NOT the same as the exec one) go
:::


<details>
<summary>Full output: Stakeholder Briefings</summary>


```markdown
# Stakeholder briefings: Resurface pivot - time-based digest to extension-triggered contextual


</details>


---


### Stakeholder Briefings


*Brainshelf consumer PKM app - the Resurface morning-digest PRD projected to four stakeholder lenses ahead of the Sprint 8 build, with Apple Mail Privacy Protection as the cross-functional wrinkle*


:::note[Prompt]

/foundation-stakeholder-briefings @resurface-prd.md

sending the resurface prd around before sprint 8. need eng + design + data

  • legal versions. heads up: apple mail privacy is the thing that bites all of them differently (open rates junk, image prefetch, etc). go
:::


<details>
<summary>Full output: Stakeholder Briefings</summary>


```markdown
# Stakeholder briefings: Resurface morning digest (PRD)


</details>


---


### Stakeholder Briefings


*Brainshelf consumer PKM app - an unstructured founder Slack thread (the raw/ambiguous source type) that the skill classifies as ambiguous, then projects to the safe-default audience set with input quality flagged low*


:::note[Prompt]

/foundation-stakeholder-briefings

ok brain dump from marco, make this make sense for the team:

resurface is fine but idk it feels like we’re underusing it?? everyone keeps asking for the digest to be smarter. chloe said clicks are way up on weekends weird. maybe we do a weekly “best of your shelf” thing too. also alex is worried mercury parser keeps choking on substack + paywalls. jordan wants to put resurface front and center in onboarding, thinks it’s our actual hook not search. should we just lead with it everywhere?? budget is tight tho. and the apple mail open rate thing makes me not trust any of our numbers honestly. anyway lots here. who needs to know what

:::


<details>
<summary>Full output: Stakeholder Briefings</summary>


```markdown
# Stakeholder briefings: Resurface direction - founder brain-dump (raw notes)


> Source classified as raw/ambiguous (an unstructured Slack thread, no single source type). Proposing the safe-default audience set: Executive, Engineering, PMM. All nine lenses remain available. Input quality is low: several items are musings, not decisions, and are flagged as open, not asserted.


</details>


---


### Stakeholder Update


*resurface-email-beta-users*


:::note[Prompt]

foundation-stakeholder-update @2026-03-17_11-00PST_resurface-algo-v1_recap.md —channel=email —audience=customer-facing —cta=“FYI-only” “email to ~500 beta users, thank them for feedback, signal shipment of algo v1 improvements”

:::


<details>
<summary>Full output: Stakeholder Update</summary>


```markdown
---
artifact_type: stakeholder-update
version: 1.0
generated_at: 2026-03-18T09:00:00Z
generated_by_skill: foundation-stakeholder-update


meeting_title: "Resurface Algorithm v1"
meeting_date: 2026-03-17


project: resurface
topics:
  - algorithm-v1


channel: email
audience_variant: customer-facing
primary_cta: "FYI-only"


thread_continuation_of: null


related_recap: 2026-03-17_11-00PST_resurface-algo-v1_recap.md


input_quality: high
confidence: high
visibility: public
status: draft
---


# Stakeholder update: Resurface v1 Shipped. Thank You for the Feedback


</details>


---


## Phase: Discover


### Competitive Analysis


*Brainshelf consumer PKM app . competitive landscape for content resurfacing features*


:::note[Prompt]

discover-competitive-analysis

pkm and read-later market, focusing on resurfacing and re-engagement features. brainshelf is planning a resurface feature (morning email digest with 3-5 saved items) and need to understand the competitive landscape.

context: brainshelf is a consumer pkm/save-for-later tool, ~85k registered users, ~22k MAU [fictional]. core problem is users save tons of stuff but never come back to read it . 47 items saved/month, <9% revisited within 30 days [fictional].

4 competitors to analyze: readwise, raindrop.io, pocket (mozilla), instapaper. focus on resurfacing features, email digests, pricing, and where the white space is for us.

---
:::


<details>
<summary>Full output: Competitive Analysis</summary>


# Competitive Analysis: PKM / Read-Later Content Resurfacing


</details>


---


### Interview Synthesis


*Brainshelf consumer PKM app . user interviews on saved content re-engagement*


:::note[Prompt]

discover-interview-synthesis

ran 7 user interviews over the past 2 weeks about why people save stuff to brainshelf but never go back to read it. need to synthesize the findings.

interviews were video calls, 30-45 min each. mix of heavy savers, occasional users, and one churned user.

main findings:

  • 5/7 described their library negatively (“guilt pile”, “overwhelming”, etc)
  • nobody has a natural trigger to go back and read saved stuff
  • there’s a weird split between “saving to read later” and “saving to have” that people don’t realize until you ask them

some great quotes. need this formatted for the team before we start building the hypothesis doc for resurface.

---
:::


<details>
<summary>Full output: Interview Synthesis</summary>


# Interview Synthesis: Why Users Save but Don't Return


</details>


---


### Journey Map


*Brainshelf AI book-curation subscription - avid reader from discovery to subscribe to weekly habit*


:::note[Prompt]

discover-journey-map

map the first-time subscriber journey for brainshelf. it’s an AI book recommendation subscription for serious readers who hate generic amazon/ goodreads recs. persona is an avid reader (30-50, reads 2-4 books/month) who’s tired of bad recommendations.

we did 8 interviews with target readers. key signals:

  • people are skeptical that “another algorithm” will do better
  • the moment that hooks them is the first rec that’s genuinely great and not obvious - something they’d never have found themselves
  • a few said they’d churn fast if week 2-3 recs got generic
  • the readers who stuck around started recommending it to friends unprompted

scope it discovery -> subscribe -> weekly habit -> referral. linear, but the weekly-use part is a recurring loop. include a mermaid timeline.

---
:::


<details>
<summary>Full output: Journey Map</summary>


# Customer Journey Map: Brainshelf First-Time Subscriber - "From Skeptic to Evangelist"


</details>


---


### Market Sizing


*Brainshelf consumer subscription - sizing the US market for AI-curated book recommendations*


:::note[Prompt]

discover-market-sizing

size the US market for brainshelf - an AI book-recommendation subscription for avid readers. consumer subscription, ~$8/month. need it for a seed deck.

i don’t have a bought market report. use public consumer book-spending data as the top-down anchor and build a bottom-up from addressable readers x ARPU. show me where the two methods agree.

---
:::


<details>
<summary>Full output: Market Sizing</summary>


# Market Sizing: Brainshelf AI Book-Curation Subscription (US)


> Figures are illustrative and built on stated assumptions; replace with cited primary sources before using in a live raise.


</details>


---


### Stakeholder Summary


*Brainshelf consumer PKM app . internal stakeholder map for the Resurface feature*


:::note[Prompt]

discover-stakeholder-summary

need to map the internal stakeholders for the resurface feature before we kick off the build. brainshelf is a ~20 person startup so this is small-team politics, not enterprise governance.

key people:

  • marco (ceo/cofounder) . big advocate, sees this as the retention bet
  • alex (eng lead) . supportive but worried about A/B test infrastructure
  • jordan (growth) . wants resurface as the retention lever
  • dan (designer) . concerned about the digest feeling spammy
  • chloe (data) . needs instrumentation for the experiment

want a proper stakeholder map with communication plan.

---
:::


<details>
<summary>Full output: Stakeholder Summary</summary>


# Stakeholder Summary: Resurface Feature


</details>


---


## Phase: Define


### Hypothesis


*Brainshelf consumer PKM app . Resurface morning email digest hypothesis*


:::note[Prompt]

define-hypothesis

trying to figure out if a morning digest email will actually get people to re-read their saved stuff. context: brainshelf pkm app, 22k MAU [fictional]. users save ~47 items/month but only go back to read ~9% within 30 days [fictional]. classic guilt pile problem from interviews.

want to run an A/B test on a morning email that surfaces 3-5 items from their library based on what they’ve been reading lately. need a hypothesis doc to align the team before we commit to building it.

primary metric: resurface item click rate. secondary: actual read completion. guardrail: don’t tank unsubscribe rate.

---
:::


<details>
<summary>Full output: Hypothesis</summary>


# Hypothesis: Morning Resurface Email Increases Re-Read Rate


</details>


---


### JTBD Canvas


*Brainshelf consumer PKM app . JTBD canvas for saved content re-engagement*


:::note[Prompt]

define-jtbd-canvas

the core job for the resurface feature. users save stuff to brainshelf with the intent to read it later, but the act of saving satisfies the intent . they never actually come back. so the real job isn’t “save to read later” (that job is already done by the save action), the real job is “rediscover the things I saved that are still worth my time.”

based on 7 user interviews (jan 2026). guilt pile is the emotional dimension. social dimension: people want to seem well-read but their library proves they’re not.

competing solutions: readwise (expensive), browser bookmarks (no resurface), doing nothing (guilt pile grows), raindrop.io (organize but no resurface).

---
:::


<details>
<summary>Full output: JTBD Canvas</summary>


# Jobs to be Done Canvas: Rediscover Saved Content Worth My Time


</details>


---


### Opportunity Tree


*Brainshelf consumer PKM app . opportunity tree for saved content re-engagement*


:::note[Prompt]

define-opportunity-tree

outcome: increase 7-day return rate from 18% to 25% [fictional] by end of Q2 2026.

three opportunities from interviews + data:

  1. re-engagement trigger gap . users have no external prompt to return
  2. content relevance decay . old saves lose timeliness, making the library feel stale
  3. library overwhelm . 400-item undifferentiated list creates avoidance

solutions I’m considering:

  • opp 1: morning email digest (resurface), in-app notification card
  • opp 2: freshness scoring, auto-archive stale items
  • opp 3: intent tagging at save time, smart collections

want to prioritize opp 1 / email digest based on competitive analysis (readwise is the only proof point for email resurfacing).

---
:::


<details>
<summary>Full output: Opportunity Tree</summary>


# Opportunity Solution Tree: Increase 7-Day Return Rate


</details>


---


### Prioritization Framework


*Brainshelf consumer book-curation app - prioritizing 8 candidate features for the Q3 roadmap*


:::note[Prompt]

define-prioritization-framework

prioritize our Q3 candidate features for brainshelf (AI book-curation subscription). decision context: Q3 roadmap, ~14 eng-weeks of capacity.

features (i have engagement data + eng estimates):

  1. rec algorithm v2 2. social follow-friends 3. mobile app
  2. public reading profiles 5. reading streaks 6. audiobook recs
  3. export to goodreads 8. family plan

run whatever frameworks apply and show me where they disagree.

---
:::


<details>
<summary>Full output: Prioritization Framework</summary>


# Prioritization: Brainshelf Q3 Roadmap Candidates


</details>


---


### Problem Statement


*Brainshelf consumer PKM app . saved content re-engagement problem statement*


:::note[Prompt]

define-problem-statement

the guilt pile problem. users save a ton of stuff to brainshelf but never come back to read it. interview data says 5/7 users described their library negatively. behavioral data says <9% revisit rate within 30 days [fictional]. 7-day return rate is 18% [fictional], OKR target is 25% [fictional] by end of Q2.

need a clean problem statement to align the team before we start building the resurface hypothesis.

---
:::


<details>
<summary>Full output: Problem Statement</summary>


# Problem Statement: Saved Content Re-Engagement Gap


</details>


---


## Phase: Develop


### Architecture Decision Record


*Brainshelf consumer PKM app . email sending infrastructure decision for the Resurface digest*


:::note[Prompt]

develop-adr

email sending infra for resurface. we don’t have any email sending today . everything is in-app or firebase push. need to pick a provider for the daily digest.

options we looked at:

  • sendgrid (twilio): mature, everyone uses it, but their free tier shrank and the dashboard is confusing
  • postmark: great deliverability reputation, simple api, but transactional only . no batch/digest support without workarounds
  • resend: new, developer-first, react email templates, free tier covers our a/b test volume

alex ran a quick eval last week. we’re leaning resend. need the ADR written up before sprint 8 starts.

---
:::


<details>
<summary>Full output: Architecture Decision Record</summary>


# ADR-007: Use Resend as the Email Sending Provider for the Resurface Digest


</details>


---


### Design Rationale


*Brainshelf consumer PKM app . digest email layout design decision for the Resurface feature*


:::note[Prompt]

develop-design-rationale

digest email layout for resurface. dan showed three options:

option A: rich cards . article thumbnail, title, excerpt, topic tag for each item. looks great in figma but heavy on images and might trigger promotions tab.

option B: structured text . article title (linked), source domain, topic tag, estimated read time. no images. clean, editorial feel. fast to scan.

option C: minimal plain text . just titles and links, no styling. maximum deliverability but looks like a system notification, not a product experience.

we did a quick preference test with 12 users. 9 preferred option B. reasons: “fast,” “doesn’t look like spam,” “I’d actually read this.”

going with B. need the rationale written up.

---
:::


<details>
<summary>Full output: Design Rationale</summary>


# Design Rationale: Resurface Digest Email Layout


</details>


---


### Solution Brief


*Brainshelf consumer PKM app . Resurface feature solution brief for team alignment*


:::note[Prompt]

develop-solution-brief

resurface one-pager for the team. need to get everyone on the same page before sprint 8 starts. marco wants to see it too.

the solution: daily morning email digest that surfaces 3-5 saved items matched to what the user has been reading recently. opt-in required. 7:30 AM local time. topic matching algorithm picks the items.

key features: email digest, topic matching, opt-in flow, one-click read, cadence setting (daily default, can switch to 3x/week).

primary metric: 7-day return rate, 18% → 25% [fictional]. secondary: email CTR. guardrail: unsub rate ≤2%/week.

explicitly NOT doing: in-app resurfacing (deferred), push notifications (too aggressive for first version), smart collections (too big), annotation-based resurfacing (that’s readwise’s approach, we’re doing topic matching instead).

---
:::


<details>
<summary>Full output: Solution Brief</summary>


# Solution Brief: Resurface . Morning Email Digest


</details>


---


### Spike Summary


*Brainshelf consumer PKM app . topic-matching algorithm spike for the Resurface digest*


:::note[Prompt]

develop-spike-summary

topic matching spike for resurface. alex spent 3 days on it last week. question: can we build something that picks saved items relevant to what the user has been reading recently, accurate enough to not annoy people?

three approaches tested:

  1. tag-based . use OG tags, domain, URL patterns. simplest, no ML.
  2. tfidf . extract article text, vectorize, cosine similarity. no external api. medium complexity.
  3. openai embeddings . text-embedding-3-small. highest accuracy but adds external dependency and per-call cost.

benchmark: 3 real user libraries (anonymized), 50 items each, manually rated as “relevant” or “not relevant” to recent reading.

results: tags = ~55% [fictional], tfidf = ~72% [fictional], embeddings = ~84% [fictional].

recommendation: go with tfidf for mvp. meets the 70% bar we set, no external dependency. plan to migrate to embeddings later if the feature sticks.

---
:::


<details>
<summary>Full output: Spike Summary</summary>


# Spike Summary: Topic-Matching Algorithm for Resurface Digest


</details>


---


## Phase: Deliver


### Edge Cases


*Brainshelf consumer PKM app . Resurface digest edge cases and error states*


:::note[Prompt]

deliver-edge-cases

resurface edge cases for sprint 8. need to cover:

  • what happens when the user’s library is too small
  • what happens when all items have been resurfaced recently
  • timezone weirdness (DST, user changes timezone, half-hour offsets)
  • text extraction failures
  • resend api outages
  • user clicks a link to a dead URL
  • email bounces
  • concurrent opt-in/unsubscribe race conditions

alex wants this documented so QA can build the test plan from it.

---
:::


<details>
<summary>Full output: Edge Cases</summary>


# Edge Cases: Resurface Digest


</details>


---


### Launch Checklist


*Brainshelf consumer PKM app . Resurface feature launch checklist for Sprint 8 ship*


:::note[Prompt]

deliver-launch-checklist

resurface launch checklist. shipping at end of sprint 8 (feb 14-16). this is our first email feature so dns, deliverability, and compliance are all new for us. need the full checklist.

key stakeholders: priya (pm/launch owner), alex (eng), jess (eng), dan (design), sam (frontend), chloe (data), jordan (growth), marco (ceo, go/no-go).

go/no-go meeting: feb 12. launch window: feb 14-16 behind feature flag. opt-in enrollment starts mar 2. a/b test starts mar 9.

---
:::


<details>
<summary>Full output: Launch Checklist</summary>


# Launch Checklist: Resurface . Morning Email Digest


</details>


---


### PRD


*Brainshelf consumer PKM app . Resurface feature PRD for Sprint 8 build*


:::note[Prompt]

deliver-prd

resurface prd for sprint 8. pulling everything together: solution brief, adr (resend), design rationale (text layout), spike (tfidf).

building the daily email digest that surfaces 3-5 saved items matched to recent reading. opt-in required. 7:30 AM local time. tfidf for topic matching. resend for email. text-only layout.

target users: active savers (10+ items, active in last 30 days) . about 9,800 users [fictional].

metrics: 7-day return rate 18%→25% [fictional], email CTR ≥15% [fictional], unsub ≤2%/week [fictional].

scope: digest email, topic matching, opt-in flow, cadence setting, one-click read, analytics events. NOT doing: in-app resurfacing, push notifications, smart collections.

timeline: sprint 8 build (feb 3-16), setup week (mar 2-8), a/b test (mar 9 - apr 5), decision (apr 11).

---
:::


<details>
<summary>Full output: PRD</summary>


# PRD: Resurface . Morning Email Digest


</details>


---


### Release Notes


*Brainshelf consumer PKM app . Resurface feature release notes for users*


:::note[Prompt]

deliver-release-notes

resurface release notes. feature shipped feb 16 behind flag. opt-in enrollment starts mar 2. writing for the in-app changelog and blog.

tone: friendly, plain language. not techy. our users are knowledge workers who save articles . talk to them about reading, not about algorithms.

highlights: daily email digest with your most relevant saved content, delivered every morning. opt-in from home screen. one-click to read. change frequency or unsubscribe anytime.

also: fixed the timezone bug from sprint 8 that sent early-morning digests to UK/EU users. and improved text extraction for paywalled articles (better fallback to article metadata).

---
:::


<details>
<summary>Full output: Release Notes</summary>


# Brainshelf 2.8.0


**Release Date:** March 2, 2026


</details>


---


### User Stories


*Brainshelf consumer PKM app . Resurface user stories for Sprint 8*


:::note[Prompt]

deliver-user-stories

resurface stories for sprint 8. need the full set with acceptance criteria.

stories:

  1. receive daily digest (P0) . the core email delivery
  2. opt in to digest (P0) . home screen card + settings toggle
  3. click item to read (P0) . one-click from email to article
  4. change cadence (P1) . daily vs 3x/week
  5. unsubscribe from digest (P0) . one-click from email footer

keep them tight. alex and jess need to estimate on monday.

---
:::


<details>
<summary>Full output: User Stories</summary>


# User Story: Receive Daily Resurface Digest


</details>


---


## Phase: Measure


### Dashboard Requirements


*Brainshelf consumer PKM app . Resurface experiment dashboard requirements for Amplitude*


:::note[Prompt]

measure-dashboard-requirements

resurface experiment dashboard for amplitude. need it ready before the a/b test starts (mar 9).

two audiences:

  1. product team (priya, chloe, alex, jordan) . daily monitoring during the 4-week test
  2. marco (ceo) . weekly exec check-in, needs a single-screen summary

questions the dashboard should answer:

  • is the treatment group returning more than control?
  • are users clicking items in the digest?
  • is the unsubscribe rate within the guardrail?
  • what’s the opt-in funnel conversion rate?
  • are there segment differences (library size, cadence)?

charts i want:

  1. 7-day return rate trend (treatment vs control, weekly)
  2. email CTR trend (daily)
  3. opt-in funnel (card viewed → opted in)
  4. unsubscribe rate trend (weekly, with guardrail line)
  5. segment breakdown table (library size, cadence)

filters: date range, experiment variant, library size segment.

---
:::


<details>
<summary>Full output: Dashboard Requirements</summary>


# Dashboard Requirements: Resurface Experiment Dashboard


</details>


---


### Experiment Design


*Brainshelf consumer PKM app . Resurface A/B test experiment design*


:::note[Prompt]

measure-experiment-design

resurface a/b test. feature is shipped behind a flag. need the full experiment design for chloe to set up in amplitude.

hypothesis: daily digest → higher 7-day return rate.

design: intent-to-treat. treatment gets the opt-in prompt + digest. control gets nothing (current experience). measure 7-day return rate for both groups.

secondary metric: email CTR (treatment only . control doesn’t get email). guardrail: unsub rate ≤2%/week.

sample: 400 per variant from the 9,800 eligible users [fictional]. duration: 4 weeks (mar 9 - apr 5). 50/50 split on enrollment cohort.

want to have the design doc locked before the setup week (mar 2-8).

---
:::


<details>
<summary>Full output: Experiment Design</summary>


# Experiment Design: Resurface Daily Digest A/B Test


</details>


---


### Experiment Results


*Brainshelf consumer PKM app . Resurface A/B test results and ship decision*


:::note[Prompt]

measure-experiment-results

resurface a/b test results. test ran mar 9 - apr 5 (4 weeks). 800 users, 50/50 split [fictional].

headline: treatment won.

primary metric (7-day return rate):

  • control: 18.1% [fictional]
  • treatment: 23.4% [fictional]
  • delta: +5.3pp, p = 0.008 [fictional]

secondary (email CTR, treatment only): 17.2% [fictional] opt-in rate: 41% of treatment group (164/400) [fictional]

guardrails all passed:

  • unsub: 1.3%/week [fictional] (under 2% threshold)
  • app uninstall: no difference
  • save rate: no difference

segments:

  • heavy savers (100+ items): return rate lift = +7.1pp [fictional]
  • light savers (10-50 items): return rate lift = +3.8pp [fictional]
  • daily cadence users: CTR 18.6% [fictional]
  • 3x/week users: CTR 14.1% [fictional]

surprising: opt-in rate was 41% [fictional], way above the 10% target. also surprising: week 4 return rate was HIGHER than week 1 (not novelty decay . habit formation).

recommendation: ship to all eligible users.

---
:::


<details>
<summary>Full output: Experiment Results</summary>


# Experiment Results: Resurface Daily Digest A/B Test


</details>


---


### Instrumentation Spec


*Brainshelf consumer PKM app . Resurface feature analytics instrumentation spec*


:::note[Prompt]

measure-instrumentation-spec

resurface analytics events for amplitude. need the full spec before sprint 8 starts so alex and jess can instrument during the build.

events:

  1. resurface_opt_in . user enables the digest
  2. resurface_digest_sent . server sends a digest email
  3. resurface_digest_opened . user opens the email (caveat: apple MPP)
  4. resurface_item_clicked . user clicks an item in the digest
  5. resurface_unsubscribe . user unsubscribes
  6. resurface_cadence_changed . user changes frequency
  7. resurface_digest_skipped . server skips sending (no qualifying items, exclusion window exhausted, etc.)

also need user properties: digest_enabled, digest_cadence, digest_timezone.

keep it tight. chloe wants to review before sprint planning on monday.

---
:::


<details>
<summary>Full output: Instrumentation Spec</summary>


# Instrumentation Spec: Resurface Digest


</details>


---


### OKR Grader


*Brainshelf prosumer knowledge tool. Resurface team Q3 2026 cycle review at quarter close (October 2026). Scores the OKR set produced in the foundation-okr-writer brainshelf sample. Demonstrates aspirational sweet-spot scoring with an invalidating signal on the retention-multiplier hypothesis.*


:::note[Prompt]

measure-okr-grader

Original OKR: see sample_foundation-okr-writer_brainshelf_resurface-q3.md Cycle: Q3 2026 (July 1 to September 30, 2026) OKR type: aspirational

Final KR values:

  • KR1 (weekly Resurface-active members): 36% [fictional] (target 41%, baseline 22%)
  • KR2 (30-day retention among Resurface-engaged members): 59% [fictional] (target 68%, baseline 56%)
  • KR3 (guardrail, member-reported relevance): 4.3 / 5 [fictional] (target hold at or above 4.2 / 5, baseline 4.2 / 5)

Guardrails (health):

  • “Resurface item felt repetitive” rate ended at 6.4% [fictional] (baseline 5%, threshold 8%)
  • Push notification opt-out rate ended at 5.1% [fictional] (baseline 3.1%, threshold 6%)

Initiative status:

  • Initiative 1 (Algo v1.5): shipped August 4 (on plan). Hit-rate on first-impression items rose from 64% to 71% [fictional].
  • Initiative 2 (Push notification triggers for high-confidence surfaces): shipped July 28. Push open rate 41% [fictional]; click-through to Resurface item 18% [fictional] vs the 2x in-app rate hypothesized from beta data.
  • Initiative 3 (Personalized first-session Resurface onboarding): shipped September 12 (delayed by 4 weeks due to onboarding team capacity). Q3 first-session cohort is too small for a clean read.

Cycle context:

  • Sharing team’s Q3 KR (items shared per week +30%) hit 23% [fictional]; the surface-able content pool grew slightly, not enough to require algo retraining cadence change.
  • The 500-user beta cohort that produced the original 3.4x retention multiplier was re-run in August at the broader population scale (n=12,400 [fictional]). The replication observed a 1.6x multiplier, not 3.4x.

Stakeholder interpretation: Resurface leadership reads the cycle as a “strong engagement quarter, retention thesis needs more time.” Looking for grader’s independent read on whether the retention-multiplier hypothesis should be retired or carried forward.

:::


<details>
<summary>Full output: OKR Grader</summary>


```markdown
# OKR Cycle Review: Brainshelf Resurface Team, Q3 2026


</details>


---


### Survey Analysis


*Brainshelf consumer subscription - quarterly NPS survey (N=1200) with an open-text follow-up*


:::note[Prompt]

measure-survey-analysis

analyze our Q2 brainshelf NPS survey. 1200 subscribers responded. standard NPS question (0-10) plus an open text “what’s the one thing you’d change?” last quarter’s NPS was 18. mine the open text for what we should build next.

---
:::


<details>
<summary>Full output: Survey Analysis</summary>


# Survey Analysis: Brainshelf Q2 NPS Pulse


</details>


---


## Phase: Iterate


### Lessons Log


*Brainshelf consumer PKM app . timezone handling lesson from the Resurface Sprint 8 launch*


:::note[Prompt]

iterate-lessons-log

lesson from: timezone bug at resurface launch what happened: ~340 UK/EU users got their digest at 7:30 UTC instead of 7:30 local because the backend didn’t recognize “Europe/Kyiv” and silently fell back to UTC.

detected: feb 18, 2026 . alex noticed the send log timestamps were wrong for EU users. fixed: feb 18, same day . updated IANA database, added explicit fallback logging, patched within 2 hours.

lesson type: failure pattern / technical the real lesson isn’t the specific bug . it’s that we had ZERO integration tests for timezone-dependent behavior. the unit tests mocked the timezone, so they never caught the gap between the device timezone string and the server’s IANA database.

---
:::


<details>
<summary>Full output: Lessons Log</summary>


# Mocked Timezones Hide Real-World Failures: Always Integration-Test Time-Dependent Features Against the Live IANA Database


</details>


---


### Pivot Decision


*Brainshelf consumer PKM app . post-experiment persevere decision for Resurface*


:::note[Prompt]

iterate-pivot-decision

post-experiment pivot decision for resurface. a/b test showed +5.3pp lift in 7-day return rate, p=0.008 [fictional]. all guardrails passed.

recommending: persevere . ship to all eligible users, invest in v2.

alternatives considered:

  1. persevere: ship email digest, iterate on relevance and cadence
  2. pivot to push notifications: replace email with mobile push as the trigger mechanism
  3. pivot to in-app resurfacing: replace email with in-app notification card (deferred from the original opportunity tree as solution 1B)

need the formal decision doc for marco. decision date: april 11, 2026.

---
:::


<details>
<summary>Full output: Pivot Decision</summary>


# Pivot Decision: Resurface . Post-Experiment Evaluation


</details>


---


### Refinement Notes


*Brainshelf consumer PKM app . Sprint 9 refinement for Resurface v2 improvements*


:::note[Prompt]

iterate-refinement-notes

sprint 9 refinement for resurface v2. session was april 15, 2026. 45 minutes. priya facilitated.

stories discussed:

  1. RSF-010: embedding migration (tfidf → openai text-embedding-3-small) . BLOCKED, waiting on openai api key + budget approval from marco
  2. RSF-011: in-app resurfacing card on home screen . Ready, 5 pts [fictional]
  3. RSF-012: cadence experiment (daily vs 3x/week, larger sample) . Ready, 3 pts [fictional]
  4. RSF-013: small-library handling (users with <20 items, shorter exclusion window) . Needs Work, alex wants to see the data first

questions raised: should the in-app card show different items than the email digest or the same items? what’s the minimum library size where tfidf actually produces useful results?

decision: in-app card shows different items (complementary, not duplicate).

---
:::


<details>
<summary>Full output: Refinement Notes</summary>


# Refinement Notes: April 15, 2026


</details>


---


### Retrospective


*Brainshelf consumer PKM app . Sprint 8 retrospective after Resurface launch*


:::note[Prompt]

iterate-retrospective

sprint 8 retro . resurface launch sprint. need to write this up.

what happened: we shipped resurface on time! first big feature in 6 months. but we also had a timezone bug that sent the morning digest at 5am to UK/Europe users (~340 people [fictional]). caught it 6 hours after launch, patched within 2 hours of catching it, but some users were not happy.

format: start/stop/continue. small team (7 people in the room). 2 wins, the timezone thing, and a few process issues that came up.

previous retro action items were: (1) set up staging environment email testing . DONE, (2) add integration test for notification delivery . NOT DONE (this contributed to the bug), (3) weekly eng/pm sync . IN PROGRESS.

---
:::


<details>
<summary>Full output: Retrospective</summary>


# Retrospective: Sprint 8 . Resurface Launch


</details>


---


*48 artifacts generated across the full PM lifecycle.*


---


**Explore other journeys:**


- [Storevine (B2B Ecommerce Platform)](storevine.md)
- [Workbench (Enterprise Collaboration)](workbench.md)