Lookback: PRD vs. Roadmap — Thematic Shift Analysis¶
Created: 2026-03-18T22:00:00-07:00 Comparing: PRD v1.6 (2026-03-12) → HJ Roadmap (2026-03-18, built from Bawa calls 34+35)
Summary¶
The PRD was written from the builder's perspective — a technically ambitious vision of what the system could be. The roadmap was built from the customer's mouth — what Dr. Bawa and Lauryn Cooper actually said they need. The gap between them reveals where we were building ahead of demand, where we were building the right thing, and where the customer's priorities surprised us.
1. From Platform Architecture to Operational Pain Relief¶
PRD emphasis: Three-layer model (protocol → care plan → patient journey), 8 new database tables, daily AI briefing assembly, component delivery tracking, authority zones, behavioral modifiers.
Roadmap emphasis: "Can the app tell me when a patient is running low on Percocet before they call me at midnight?" "Can I log in the morning and see who needs attention?"
The shift: The PRD thinks in systems. The roadmap thinks in workload. Bawa doesn't care about the three-layer model — he cares that his office phone rings less and nobody falls through the cracks. The architecture is a means, not an end. The roadmap re-anchors every feature to a specific office pain point: refill crises, repetitive calls, missed feedback, anxiety-driven questions about bruising.
What this means: The three-layer model is still the right foundation. But the roadmap surface (what gets built next, what gets demoed) should be described in Bawa's language, not ours.
2. The Companion App Reversal¶
PRD emphasis: Multi-sided platform — patients, doctors, PTs, DME providers. Four stakeholder types, four interfaces. The DME provider is listed as a first-class persona.
Roadmap emphasis: Backend dashboard first. Companion app deferred. "Otherwise you're gonna end up having to literally, every time you change one thing on this, you're gonna have to go change it on that."
The shift: On the 3-3 call, Bawa showed high excitement about the caretaker companion app — it felt like the next big feature. Two weeks later on 3-18, when forced to choose, he reversed: get the main system stable first. The PRD's multi-sided platform vision is still correct directionally, but Bawa gave us a clear sequencing constraint we didn't have before.
What this means: The PRD's v4 roadmap has "Doctor Dashboard + DME Integration" as the next version. The customer confirmed the dashboard but pushed DME and companion surfaces further out. The PRD's stakeholder model (doctor, PT, DME, patient) should hold — but the build order is now: patient → doctor's office staff → doctor (protocol) → PT → caretaker → DME.
3. Daily Card vs. Provider Dashboard — Who Gets the Morning View?¶
PRD emphasis: Feature 10 (Daily Card) is the patient's primary interaction surface. Phase-adaptive, behavioral modifiers, inquiry/advocacy ratio, Today's Focus ownership transfer. Significant design and engineering investment.
Roadmap emphasis: Provider Dashboard is the office's morning view — triage ranking, conversation summaries, action items, refill alerts. Bawa described this unprompted as his ideal workflow.
The shift: The PRD invested heavily in designing the patient's morning experience. The roadmap reveals that the staff's morning experience is more urgent. Lauryn and Dr. Bawa need to see which patients need attention before the patients even need to see anything. The Daily Card is still valuable, but the provider dashboard may deliver more immediate ROI because it replaces a manual triage process that's happening (poorly) right now.
What this means: Consider whether the provider dashboard's "morning briefing" and the patient's "Daily Card" share backend infrastructure. They should — both are assembled from check-in data, alert state, and protocol context. Build the assembly engine once, render it twice.
4. Medication Management — From Missing to Most Detailed¶
PRD mention: Medication is barely present. Check-in captures "red flags" but there's no medication tracking, no refill workflow, no dosing reminders. The word "medication" appears only in the context of pain medication and pre-op reminders.
Roadmap emphasis: 12 detailed requirements. Tab counting, proactive refill identification, dosing timers, lower-dose trials, link-to-medication-sheet, 24-48 hour refill notice. The most specified feature area in the entire roadmap.
The shift: This is the biggest gap between the PRD and what the customer actually needs. Bawa described medication management with more detail than any other feature — because medication crises (running out of Percocet on a Sunday, pharmacy doesn't have it, no prior authorization) are a real, recurring, expensive problem. The PRD didn't see this coming because it was thinking about clinical intelligence. The customer was thinking about operational logistics.
What this means: Medication management needs a first-class presence in the PRD. It's not a check-in sub-feature — it's a standalone workflow with its own data model (med list, dosing schedule, tab tracking, refill state), its own patient interactions (opt-in, timers, proactive prompts), and its own provider surface (dashboard action items).
5. Visual Content — From Text-Only to Photo-Driven¶
PRD mention: Exercise videos are mentioned. Equipment diagrams are mentioned. Clinical photos? Not once.
Roadmap emphasis: Both Bawa and Lauryn independently described using photos of normal bruising/swelling to preempt patient anxiety. "Show them a worst case but that's still normal." This was a consensus moment on the call.
The shift: The PRD assumes the product is text and conversation. The customer assumes it should include images — and not generated or stylized images, but real clinical photos. "We probably have so many pictures in our email and text messages from patients." The content already exists; it just needs to be curated and integrated.
What this means: The product's content model needs to expand beyond text and video links. Clinical reference images are a new content type that the protocol system should support — photos attached to protocol components, surfaced during relevant conversations, with educational context.
6. Triage Sophistication — From Rules to Multi-Signal Reasoning¶
PRD emphasis: Symptom state machine with priority rules. Binary escalation: calf pain → DVT → escalate. Location-based disambiguation. Clean, rules-based.
Roadmap emphasis: Driving clearance triage that integrates procedure type, surgery side, post-op day, medication status (from tracking), assistive device status (walker/cane), and recovery progress — then explains its reasoning using the patient's actual data, and still defers to PT.
The shift: The PRD's triage is about safety (catch DVT, catch PE). The roadmap's triage is about clinical judgment (should this person drive?). Safety triage is binary — the answer is always "call the office" or "go to the ER." Clinical judgment triage is nuanced — the answer is "here's where you stand on multiple dimensions, and here's who to discuss it with." These are fundamentally different problems.
What this means: The triage system needs two modes. Mode 1 (safety, existing): rule-based, no ambiguity, immediate escalation. Mode 2 (clinical judgment, new): multi-signal integration, explanatory reasoning, provider deferral. Mode 2 is what the Conversation Factory needs to support — staff reports a driving question, the system checks protocol + patient data, and either handles it or identifies the gap.
7. Conversation Factory — PRD's Best Prediction¶
PRD mention: Protocol learning is listed under v4/v5 — "suggest protocol improvements based on patient outcomes."
Roadmap emphasis: Conversation Factory is Tier 1. Phase 3 (the gap-closing loop) is what's being built right now. Bawa explicitly validated the model: "Each failure is essentially an opportunity for improvement, right?"
The shift: The PRD predicted this need but placed it late in the roadmap (v4/v5). The actual customer validated it in week 3 of BETA. This is the feature with the strongest product-market signal — Bawa understood it immediately, confirmed the mental model, and set a quality bar ("it shouldn't fail on the same thing twice").
What this means: The Conversation Factory should be elevated in the PRD from a future-vision item to a current core feature. It's not "adaptive intelligence" — it's the operational mechanism by which the protocol improves. Every call Lauryn gets that the AI should have handled is a factory input.
8. Patient Agency Model — Validated but Reframed¶
PRD emphasis: Detailed agency model with inquiry/advocacy ratios per phase, behavioral modifiers, Daily Card as primary surface, Today's Focus ownership transfer. Sophisticated.
Roadmap emphasis: Goals feature confirmed, but reframed through a liability lens. "We have to be cautious... there's like liability to that too." The system should NEVER clear patients for activities — always redirect to provider. "Make sure you bring that up at your next visit."
The shift: The PRD's agency model gives patients increasing autonomy. Bawa's feedback adds a hard constraint: the system can support patient agency in tracking and motivation but not in clinical decision-making. The patient can set goals, track progress, and feel empowered — but the system never says "you're ready" for anything clinically significant. That's always the provider's call.
What this means: The agency model's late-phase posture (80/20 patient-led) needs a persistent guardrail: autonomy in planning and tracking, but deferral in clearance. This isn't a phase-dependent constraint — it applies at every phase. Even a return-to-activity patient who "authors their own day" still gets "discuss with your PT" when they ask about hiking.
9. The Onboarding Survey — From Quick Win to Protocol Customizer¶
PRD mention: Magic link onboarding is Feature 1. The survey is barely mentioned — just a security gate (last 4 digits of phone number).
Roadmap emphasis: 10 specific requirements for the onboarding survey. Procedure type, surgery side, surgery date (editable), vaping, activity/function tracking opt-in. Each answer customizes the downstream protocol experience.
The shift: The PRD sees onboarding as a gate. The roadmap sees onboarding as the first customization event. What the patient tells us during onboarding determines which protocol content they see, which reminders they get, and how much the system engages them. It's not a form — it's the beginning of personalization.
What this means: The PRD should reframe onboarding from "magic link + security" to "magic link + intake survey that configures the protocol." This is already partially there (blood thinner → suppress DVT reminders) but the roadmap makes it explicit and expands it.
10. Who the Customer Actually Is¶
PRD persona: Dr. Bawa is described as "Protocol Owner" — prescribes surgery, oversees recovery, defines clinical protocols, sees longitudinal data, gets alerted to symptoms.
Roadmap reality: Dr. Bawa is a busy surgeon who can't get his own office firewall to let him access the system. He has 4 minutes between patients. He wants to log in once in the morning and see who needs attention. He delegates most patient interaction to Lauryn. His PA is the actual day-to-day user.
The shift: The PRD's surgeon persona is accurate but incomplete. The missing persona is the PA/clinical coordinator (Lauryn) — the person who actually answers the phone, handles refill requests, fields patient anxiety, and would be the power user of the provider dashboard. She's not in the PRD at all.
What this means: Lauryn needs her own persona section. She's the care team user. She's the one who would log into the dashboard every morning. She's the one who knows what questions patients ask. She's the one Chris is going to spend hours with at the 3/25 visit. The PRD has "Physical Therapist" as a persona but not "PA/Clinical Coordinator" — and for Bawa's practice, the PA is more important than the PT for this product.
Thematic Summary¶
| Theme | PRD (builder's view) | Roadmap (customer's view) |
|---|---|---|
| Priority | Architecture, data model, agency model | Reduce phone calls, catch refill crises, morning triage |
| Sophistication | Three-layer model, behavioral modifiers, inquiry/advocacy ratios | "Can it tell me when someone's running low on Percocet?" |
| Sequencing | v3 → v4 → v5 (features per version) | Backend dashboard → onboarding → meds → goals → companion app |
| Content | Text + video links | Text + video + clinical photos |
| Safety | Rule-based escalation (DVT, PE, infection) | Rule-based + clinical judgment triage (driving, activity clearance) |
| Agency | Patient autonomy increases with phase | Patient autonomy in tracking, never in clearance |
| Users | Doctor, PT, DME, Patient | Lauryn (PA), then Doctor, then Patient |
| Learning loop | Future vision (v4/v5) | Already validated, being built now |
The PRD is not wrong. It's aspirationally correct but operationally misweighted. The roadmap reweights toward what the customer actually asked for — and the customer asked for medication tracking, a morning dashboard, and clinical photos before they asked for behavioral modifiers and Daily Cards.