Product Requirements Document
A structured document that defines what a product or feature should do, for whom, and why - without specifying how to build it.
Product Requirements Document
Section titled “Product Requirements Document”A PRD (Product Requirements Document) is the contract between a product team and an engineering team. It answers: what is the problem, who has it, what does success look like, and what are the boundaries of the solution? What a PRD deliberately does not answer is: how will engineering implement this? That boundary is the PRD’s most important feature.
Canonical template
Section titled “Canonical template”# [Feature Name] - Product Requirements
## Problem Statement[Who has what problem, with what frequency and impact.]
## Goals- [Measurable outcome 1]
## Non-Goals- [What we are explicitly NOT solving in this release]
## User Stories / Jobs-to-be-Done- As a [user], I want to [action] so that [outcome]
## Success Metrics- [How we will know this worked]
## Open Questions- [Assumption not yet validated]When to use
Section titled “When to use”Defining a new feature, aligning engineering on scope, communicating product intent to stakeholders, planning a sprint or milestone.
When not to use
Section titled “When not to use”Operational documentation, post-launch retrospectives, engineering design decisions.
Pairs well with
Section titled “Pairs well with”pragmatic-architect, candid, matter-of-fact, problem-solution
Often confused with
Section titled “Often confused with”adr: An ADR records an architectural decision already made. A PRD defines what should be built before engineering has made the implementation decisions.
- Canonical sections: Problem Statement, Goals, Non-Goals, User Stories, Success Metrics, Open Questions
- Defines what should be built and why, deliberately not how
- A problem statement that names the user, the friction, and the frequency
- Non-goals stated as explicitly as the goals
- Goals and Success Metrics expressed as measurable outcomes
- An Open Questions section naming assumptions not yet tested
Anti-patterns
Section titled “Anti-patterns”- Specifying implementation details - how engineering should build it - A PRD that prescribes implementation is a spec; the what-not-how boundary is the format’s most important feature and signals distrust of engineering when crossed.
- Recording an architectural decision already made and its reasoning - That is the confusable adr; a PRD defines requirements before the implementation decisions exist, while an ADR documents a made decision about how.
- Leaving the non-goals blank or vague - Scope creep lives in what was left ambiguous; goals without matching non-goals let the boundary of the solution drift.
Failure modes
Section titled “Failure modes”- Bloats into an exhaustive spec-of-everything - the document tries to pin down every requirement, edge case, and detail until engineering follows the letter and misses the spirit - A PRD creates alignment without constraining implementation; if it leaves no room for engineering to make tradeoffs, it has overshot into a spec, so pull detail back to intent.
- Over-indexes on metrics and success criteria until the user problem and the non-goals it is meant to serve disappear behind a wall of targets - Metrics measure whether the solution worked, they do not define the problem; lead with the user need and the non-goals, and let the targets follow from them rather than replace them.
Instruction
Section titled “Instruction”Write as a Product Requirements Document (PRD). Cover: Problem Statement (who has what problem),Goals (measurable outcomes), Non-Goals (explicit scope exclusions), User Stories orJobs-to-be-Done, Success Metrics, and Open Questions. Do not specify implementation - the PRDdescribes what should be built and why, not how to build it. Make the problem statement specific:name the user, the friction, and the frequency. Make the non-goals as explicit as the goals -scope creep lives in what was left ambiguous. The open questions section is required: name theassumptions that have not yet been tested.Template
Section titled “Template”See the Product Requirements Document template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Pragmatic Architect, Candid, Matter of Fact, Problem-Solution
Avoid with
Section titled “Avoid with”Pastoral, Devotional Reflection, Warm, Reverent
Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”- Should we adopt async-first standups?
- How to start a morning routine
- How to choose between Postgres and DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
Async Standup Bot - Product Requirements
Section titled “Async Standup Bot - Product Requirements”Problem Statement
Section titled “Problem Statement”Engineering teams using Slack for team communication have no structured way to run async standups within the tool they already use. Current approaches require either a separate SaaS product (Geekbot, Standuply), which adds cost and context-switching, or a manual template posted to a channel, which requires someone to enforce the format and generates no structured data. Teams that need to review standup history, track blocker patterns, or report on team activity cannot do so without manually reading thread-by-thread.
The users who feel this most are engineering managers and team leads at companies with distributed teams (at least two timezones). They run standups daily. They need blockers to surface and resolve without requiring a meeting. They cannot afford a per-seat SaaS subscription for a feature they could implement natively.
- Enable any Slack workspace to run structured async standups with no external tool
- Reduce time-to-resolution for blockers by routing them to the named person via direct @mention
- Produce a structured weekly digest that engineering leads can use for 1:1 and planning prep
- Support teams of 4 to 50 engineers without configuration complexity
Non-Goals
Section titled “Non-Goals”- This release does not replace synchronous standup tooling (Zoom, Meet integrations)
- This release does not include time-tracking or sprint velocity metrics
- This release does not support custom standup prompts in v1 - the three-field template is fixed
- This release is not intended for non-engineering teams (sales, marketing standup formats are different)
User Stories
Section titled “User Stories”- As a team lead, I want to configure a standup channel and prompt schedule once so that I am not manually reminding my team to post each day
- As an engineer, I want to post my standup update in a format that takes less than two minutes so that the daily ritual does not feel like overhead
- As an engineer with a blocker, I want my blocker to reach the specific person who can help so that I am not waiting for them to notice it in a channel they may not read attentively
- As a team lead, I want a weekly summary of standup activity so that I can see blocker patterns and prepare for 1:1s without reading 50 individual posts
Success Metrics
Section titled “Success Metrics”- Average time from blocker posted to first response from @mentioned person: target under 30 minutes during business hours
- Daily participation rate: target 85% of team posts on any given weekday
- Setup time: a team lead can configure and launch a standup channel in under 10 minutes
- Weekly digest open rate: target 70% of team leads open the digest within 24 hours of delivery
Open Questions
Section titled “Open Questions”- Does the bot need to handle engineers across more than two timezones in a single team? If so, how does the “post by 10am local” constraint work when “local” varies by 13 hours?
- Should the bot send direct reminders to engineers who have not posted by their deadline, or only post a channel reminder?
- What happens when someone is out of office - does the bot need OOO awareness, or does the team handle this manually?
- Is there a meaningful integration with GitHub or Jira that would let the bot pre-populate the “shipped” field from closed PRs or resolved tickets?
PRD: Morning Routine v1
Section titled “PRD: Morning Routine v1”- Author: Me
- Status: Draft
- Last updated: 2026-05-14
- Target launch: 2026-05-19 (Monday)
1. Problem Statement
Section titled “1. Problem Statement”The current morning experience (6:30am - 7:30am) is unstructured and reactive. The first action upon waking is phone-checking, which consumes 40-50 minutes and produces measurable downstream effects: elevated baseline stress, slower work start, and a recurring sense of having begun the day in a deficit. Three prior unstructured attempts to “use the phone less in the morning” have failed within a week, indicating the problem is not motivational but architectural.
2. Goals
Section titled “2. Goals”- G1: Establish a repeatable, low-friction routine for the 6:30am - 7:30am window on weekdays.
- G2: Eliminate phone use during this window.
- G3: Arrive at the 9am work start with a written daily plan already in hand.
- G4: Be sustainable for at least 30 consecutive weekdays without willpower spikes.
3. Non-Goals
Section titled “3. Non-Goals”- NG1: Not optimizing weekends in v1. Weekends have different constraints (children, social schedule) and warrant a separate spec.
- NG2: Not solving sleep. Bedtime drift is an upstream issue; will be addressed in a future cycle.
- NG3: Not adopting a meditation practice in v1. Out of scope to avoid scope creep on a fragile habit.
- NG4: Not tracking metrics in an app. Paper-only by design.
4. Success Metrics
Section titled “4. Success Metrics”| Metric | Target | Measurement |
|---|---|---|
| Weekday adherence | >= 80% (4 of 5 weekdays per week) | Paper checklist, weekly review |
| Phone-touch before 7:30am | 0 times per weekday | Self-report, honesty system |
| Daily plan completion before 9am | 100% of weekdays | Notebook timestamp |
| Self-rated morning calm (1-5) | >= 3.5 weekly average | One-line journal entry |
5. Requirements
Section titled “5. Requirements”5.1 Functional
Section titled “5.1 Functional”- R1: Routine MUST execute in this order: water, light, movement, planning.
- R2: Routine MUST complete within 60 minutes of waking.
- R3: Phone MUST remain in the kitchen, plugged in, face down, until 7:30am.
- R4: Planning step MUST produce a written daily shortlist in a designated paper notebook.
5.2 Non-functional
Section titled “5.2 Non-functional”- R5: Routine MUST be executable in under 30 seconds of decision-making (no daily re-planning of the routine itself).
- R6: Routine MUST tolerate one missed module per day without invalidating the rest.
- R7: Routine MUST function in winter (light module has a window fallback for cold or dark mornings).
6. User Story
Section titled “6. User Story”As a working adult who currently begins the day in a reactive state, I want a predefined sequence of four small actions in my first hour so that I arrive at the work day having already chosen how I show up.
7. Open Questions
Section titled “7. Open Questions”- OQ1: What happens when a child wakes early and interrupts the routine? Default behavior: resume at the next module after the interruption ends. Needs trial.
- OQ2: Should travel days use a compressed version (e.g., water + planning only) or be exempt? Lean toward compressed.
- OQ3: Is 10 minutes of planning enough on heavy-meeting days? Possibly extend to 15 on Mondays.
8. Out of Scope (for future versions)
Section titled “8. Out of Scope (for future versions)”- Evening routine design (v2)
- Weekend variant (v2)
- Family-coordinated morning (v3)
9. Approval
Section titled “9. Approval”Self-approved. Re-review in 30 days.
Lattice Notify Notification Service - Product Requirements
Section titled “Lattice Notify Notification Service - Product Requirements”Author: Priya Shah (PM) Engineering lead: Ana Rivera Date: 2026-05-14 Sprint target: 2026-05-25 week Decision dependency: Datastore choice (Postgres vs DynamoDB) locked at the 11am Friday 2026-05-16 sync; this PRD assumes Postgres per ADR-0023.
Problem Statement
Section titled “Problem Statement”Lattice Notify users currently receive product activity (mentions, comments, status changes) only through the monolith’s polling-based feed. The feed updates every 60 seconds, which our users have rated 3.1/5 on responsiveness in the last two quarterly NPS cycles. Account-level usage data shows that customers on larger teams (>50 seats) churn 2.3x more often than smaller teams, and churn interviews consistently surface “I missed something important because the notification was late” as a top-three reason.
The product needs a real-time notification system - sub-second delivery for in-app surface, sub-5-second delivery for email and Slack push - that serves the 500K notification events/day Lattice Notify generates today, with headroom for the 10x growth scenario over the next 12 months if our Slack-partnership deal closes.
- Deliver in-app notifications with p95 latency under 1 second from event to surface
- Deliver email and Slack push notifications with p95 latency under 5 seconds
- Support the 500K events/day launch volume at the SLOs above with no manual intervention from the on-call rotation
- Increase notification responsiveness NPS subscore from 3.1 to 4.0 within 90 days of launch
- Ship to general availability within 6 weeks of sprint kickoff
Non-Goals
Section titled “Non-Goals”- Notification preferences UI beyond the existing per-channel toggles (deferred to next quarter)
- Push notifications to native mobile apps (no mobile clients exist yet)
- Cross-workspace notification routing (single-workspace scope for v1)
- Historical notification search beyond 90 days (use existing audit log for older items)
- Replacing the polling feed (it stays as a fallback for the first 90 days post-launch)
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”- As a Lattice Notify user on a team of 100, when a teammate mentions me in a comment, I want the notification to appear in my in-app inbox within a second so I can respond before the conversation moves on.
- As an admin on a team of 200, when a workspace-wide status change occurs, I want to receive a single consolidated notification within 5 seconds so my inbox is not buried.
- As an on-call engineer at Lattice Notify, when notification volume spikes 5x, I want the system to absorb the load without paging me so I can keep my night.
- As a Lattice Notify product manager, when the Slack-partnership deal closes and traffic grows 10x, I want a documented decision point about when to revisit the datastore choice so we are not blindsided by a scaling wall.
Success Metrics
Section titled “Success Metrics”- p95 in-app notification latency under 1 second, measured continuously and reported in the weekly status report
- p95 email and Slack push latency under 5 seconds
- Notification responsiveness NPS subscore reaches 4.0 within 90 days of launch
- Zero data-loss incidents in the first 90 days of production
- On-call pages attributable to the notification service: under 2 per month after the first 30 days
Open Questions
Section titled “Open Questions”- At what sustained event volume should we revisit the Postgres vs DynamoDB decision? ADR-0023 proposes 5M events/day; this PRD inherits that threshold pending Friday lock-in.
- Should notification preferences live in the notification service’s database or stay in the monolith user table? Ana to propose by sprint kickoff.
- What is the deprecation path for the polling feed after the 90-day fallback window? Priya to draft a follow-up PRD by 2026-06-15.
- How do we handle the partnership-deal trigger if it lands before we cross the 5M revisit threshold? Open with Priya and the partnerships team; not blocking this release.
Insights Analytics Dashboard - Q3 Delivery Revision and Bridge Plan
Section titled “Insights Analytics Dashboard - Q3 Delivery Revision and Bridge Plan”Status: Revised plan
Date: September 2025
Author: Product Management
Audience: Sales leadership and key customer stakeholders
Problem Statement
Section titled “Problem Statement”Sales reps and account managers field analytics requests from customers multiple times per week. Customers want to know how their teams are using the product: who logs in, which features they engage with, and where sessions stall. Currently, customers must contact support to get usage summaries or wait for quarterly business reviews. This manual reporting loop creates a three-to-five-day turnaround and places a recurring dependency on the customer success team for data that customers should be able to pull themselves.
The Insights analytics dashboard was scoped and committed for Q3 to solve this problem directly. It was designed as a purpose-built in-product view giving customers self-serve access to their usage data, filterable by date range, user cohort, and feature area.
In July, a mandatory billing-system migration was escalated to the highest internal priority. The migration required input validation, audit-trail logging, and downstream reconciliation work that had not been visible during the original capacity plan. By August it was clear the migration would consume the remaining engineering bandwidth allocated to Insights for the quarter. Shipping Insights on the original Q3 date would mean shipping without date filtering, without cohort segmentation, and without the data export layer. That is not a useful analytics product; it is a half-built screen that generates confusion and support tickets rather than value.
This document defines the revised delivery plan: what ships by end of Q3, what ships in Q1, and how we will measure whether the interim solution keeps customers unblocked.
Q3 (ship by September 30)
- Customers can download a structured CSV export of their full usage dataset directly from within the product, without contacting support or waiting for a quarterly business review.
- The export covers the core data fields from the Insights Phase 1 scope: login events, feature-level engagement, and session counts, broken down by user and date.
- The export surface is accessible from the account settings area, requires no support ticket or admin intervention, and works for any account currently on the Insights waitlist.
- At least 75% of waitlisted key customer accounts confirm in a follow-up conversation that the export meets their minimum reporting needs as a bridge.
Q1 (ship by March 31 next year)
- The full Insights dashboard ships with all Phase 1 scope intact: date-range filtering, cohort segmentation, feature-level engagement views, and in-product chart rendering.
- No Phase 1 features are removed or reduced relative to the original Q3 commitment; the timeline moves, the scope does not.
- Sales has a demo environment available no later than February 1 to support Q1 pipeline and renewal conversations.
Non-Goals
Section titled “Non-Goals”- No partial Insights UI in Q3. Shipping a partially functional dashboard creates customer-facing confusion and inflates support volume. If any screen is not production-ready, it does not ship. The Q3 deliverable is the CSV export only.
- No custom export formats. The CSV export is a single structured file with a fixed column layout. Customizable column selection, multi-sheet formats, and format variant options are out of scope for the bridge release.
- No scheduled or recurring exports. Customers trigger the export manually. Automated delivery, email scheduling, and API-based export access are Phase 2 features and are not pulled forward to fill the gap.
- No visualization layer in Q3. Customers analyze the export in their own spreadsheet or BI tool. We are not building or bundling charting capability as part of the bridge release.
- No scope reduction on Insights Phase 1 for Q1. The Q1 target is the complete Phase 1 feature set as originally defined. Nothing is removed to make the rescheduled commitment easier to hit.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”Sales rep (internal stakeholder)
- As a sales rep managing a renewal conversation, I want to show a customer their engagement trend over the past quarter so that I can anchor the discussion in actual usage data rather than anecdote.
- As a sales engineer preparing a business review, I want to pull a customer’s usage export without filing an internal data request so that I can build the report without waiting several days on the data team.
Customer account admin (key customer stakeholder)
- As a customer account admin, I want to download my organization’s usage data as a file I can open in a spreadsheet or load into our internal tools so that I can build the monthly report my manager requests without depending on the vendor to generate it for me.
- As a customer data analyst, I want structured export data I can join to our own operational records so that I can see where product engagement correlates with our own team’s outcomes.
- As a customer success lead, I want to see which product areas my team uses most so that I can identify gaps in adoption before our next internal training cycle.
Success Metrics
Section titled “Success Metrics”Q3 (CSV Export Bridge)
- Adoption: 70% of waitlisted key customer accounts download at least one export within 30 days of the feature going live.
- Support deflection: No support tickets requesting a manual usage pull from any account that has access to the export, measured over the final four weeks of Q3.
- Sales enablement: Sales team rates the CSV export as adequate as an interim substitute in an internal survey conducted in early October (target: 75% or higher).
Q1 (Full Insights Release)
- Activation: 60% of eligible accounts open the Insights dashboard at least once within 30 days of launch.
- Engagement depth: Median session includes at least two distinct filter interactions (date range, cohort, or feature area), indicating customers are exploring the data rather than opening and immediately leaving.
- Support baseline: No increase in usage-reporting support tickets relative to the Q3 CSV-export period, measured in the first four weeks after launch.
Open Questions
Section titled “Open Questions”-
Which key customer accounts are on the waitlist, and has every account been contacted directly? This document assumes sales leads have a confirmed list. If any waitlisted account has not been personally notified before this plan is shared more broadly, that account should receive a direct conversation first, not a document.
-
What is the data freshness of the CSV export? The current assumption is a daily batch refresh. If customers expect near-real-time data, the batch cadence will create mismatched expectations. The product UI must surface the data lag explicitly, and that lag must be confirmed by engineering before the feature is announced.
-
Does the export include historical data predating the feature launch? The assumption is a 12-month lookback. If engineering can only provide data from the export go-live date forward, customers trying to build historical trend reports will face a gap that makes the export significantly less useful. This must be confirmed and communicated before any customer announcement goes out.
-
Is the Q1 delivery date firm, given the billing migration tail work? The assumption is that migration work completes by mid-October and does not extend into Q4. If remaining migration tasks slip, Q1 Insights capacity could be affected again. Engineering should flag this risk no later than the October planning checkpoint so Sales has time to set expectations accordingly.
-
What threshold defines “half-built” in a future scenario? The decision not to ship a partial dashboard in Q3 was made on the basis that the missing features were the specific ones customers were promised. But the threshold was not written down. The Q4 planning review should define criteria for when a partial release is acceptable versus when a deferral is required, so the next decision is not made under time pressure from scratch.
Engineer Onboarding: First Two Weeks - Product Requirements
Section titled “Engineer Onboarding: First Two Weeks - Product Requirements”Problem Statement
Section titled “Problem Statement”New engineers joining a fast-moving backend team that ships to production daily face a repeating set of blockers in their first two weeks: access provisioning is scattered across multiple systems and typically takes one to three days to complete; the codebase has no guided entry path, so new hires spend their first week reading code without context or shipping anything; and there is no explicit conversation about team ownership or on-call responsibilities until the new hire is already expected to carry a pager.
The result is that new engineers become functional - they can run the code and attend the meetings - but they do not feel oriented or trusted with real work until week three or four. That delay extends the period of uncertainty about whether they belong, and belonging is not a soft concern: an engineer who does not feel like a team member by the end of week two is more likely to disengage quietly and less likely to ask the questions that would make them effective faster.
This document sets requirements for the onboarding program for Priya, who started Monday on a backend team with a daily ship cadence and an active on-call rotation. The requirements are intended to be reusable for future engineers in the same role.
- Priya ships one real, reviewed, and merged change to production by close of business Friday of week two.
- By end of day Friday of week one, Priya has full working access to every system she needs: source control, the deployment pipeline, secrets management, the ticket tracker, the chat tool, and the on-call runbook.
- By end of week one, Priya can describe the service topology, the team’s ownership boundaries, and the release cadence in her own words without prompting.
- By end of week two, Priya knows who to ask for what, and feels comfortable asking without calculating the social cost first.
- By the end-of-week-two retrospective, Priya can say she feels like a member of this team, not a visitor who has been permitted to attend the meetings.
Non-Goals
Section titled “Non-Goals”The following are explicitly out of scope for weeks one and two:
- On-call rotation entry. Familiarity with the runbook is a week-one goal. Being paged is not a week-one or week-two goal. Rotation entry is a week-three or later decision made jointly with Priya, after she has context on at least the services most likely to alert.
- Comprehensive architecture coverage. A useful mental model of the services most relevant to her first change is the bar. A full walkthrough of every service the team owns is not. Coverage that is too wide at this stage produces surface familiarity and no depth.
- Fixing documentation gaps discovered during onboarding. If gaps surface, they are filed as tech-debt tickets, not resolved in real time at the cost of paired onboarding time.
- A complex or high-risk first change. The first change is defined by three criteria: small, real, and merged. A ten-line fix that closes an actual ticket is better than a hundred-line refactor that took two weeks to scope and review.
- Resolving pre-existing team process issues. Onboarding reliably surfaces process friction. Addressing that friction is a separate workstream. It should not be loaded onto the onboarding program.
User Stories / Jobs to Be Done
Section titled “User Stories / Jobs to Be Done”Access and tooling (week one)
- As Priya, I need my local development environment running the full service stack before end of day Tuesday so that I am not blocked from reading and running code while the rest of the team is shipping.
- As Priya, I need a single reference that names who owns what and how to request access so that I do not spend the first week pinging five different people to ask the same question about permissions.
- As Priya, I need a guided walkthrough of the deployment pipeline before I touch it, so that I understand what I am doing when I deploy for the first time and I know who to call if something goes wrong.
Orientation (week one)
- As Priya, I want a guided walkthrough of the services my team owns - what they do, how they connect, and what breaks when they fail - so that I can ask informed questions by the time I start pairing on real work.
- As Priya, I want to read through the on-call runbook with someone who can explain the context, so I have a mental model of incident response before I am ever expected to respond to one.
- As Priya, I want to meet each team member for fifteen minutes before the end of week one - not just have names on a team page - so that I know who does what and have a real person behind each chat handle.
First change (week two)
- As Priya, I want my first task to be a real ticket - not a synthetic training exercise - so that my work receives the same review bar as everyone else’s and I know it matters.
- As Priya, I want to pair with a teammate on my first change so that I learn the team’s conventions through doing, not just through reading documentation that may or may not reflect current practice.
- As Priya, I want to own the full lifecycle of my first change - branch, pull request, review, merge, deploy - so that I know I can repeat the process independently, and so I have something concrete to point to at the end of week two.
Belonging (continuous, both weeks)
- As Priya, I want to know that asking a basic question will not count against me, so that I do not suppress confusion that a three-minute conversation would resolve.
- As Priya, I want one designated person - not a wiki, not a rotation - who is my first contact for the first two weeks, so that I am not calculating who is safe to interrupt every time I have a question.
Success Metrics
Section titled “Success Metrics”The following signals are assessed at the end of week two:
- Shipped change rate: One merged, production-deployed change by close of business Friday of week two. Binary: either it shipped or it did not.
- Access completeness: Zero days in week two where Priya’s primary blocker was a missing permission or setup issue rather than the work itself. Any blocked day attributable to provisioning failure is a metric miss.
- Orientation confidence (self-report): In the end-of-week-two retrospective, Priya rates her confidence in explaining the service topology, team ownership model, and release process at 4 out of 5 or higher on a five-point scale she controls.
- Belonging signal (self-report): In the same retrospective, Priya answers “yes” to: “Do you feel like a member of this team?” A “not sure” or “no” is not a failure of the metric; it is a signal requiring immediate follow-up.
- Paired working time: At least four hours of active pairing with a named team member during week two, as logged by the designated buddy. Remote or async pairing counts; passive shadowing does not.
Open Questions
Section titled “Open Questions”The following assumptions are baked into this plan and have not yet been validated:
-
Who is Priya’s designated buddy? The plan assumes one named person serves as first contact for two weeks. If no one is available for that commitment, the access, pairing, and belonging goals are all at risk. This decision needs to be made before Priya’s first day. It was not made before this document was written.
-
Is the first-change ticket already identified? The plan assumes a suitable ticket is waiting in the backlog at the right size and complexity. If the backlog has no appropriate ticket, the team either creates one explicitly or accepts a delay in scoping Priya’s first change. The ticket should be reviewed and agreed on by end of week one, not discovered in week two.
-
Does the deployment pipeline documentation match the current process? The week-one walkthrough is only as useful as the accuracy of what it covers. If the runbook is stale, the walkthrough may create false confidence. Someone on the team should verify it before Priya’s first deploy.
-
What is Priya’s prior experience with service-oriented architectures? The orientation scope assumes working familiarity with distributed services. If that assumption is wrong, the week-one mental model goal may need to be scoped to two or three core services rather than the full topology, and the timeline for the first change should be adjusted accordingly.
-
Has the team agreed on what “belonging” looks like in practice? The belonging goal is the most important goal in this document and the least defined one. A single retrospective question is a minimum signal, not a definition. The team has not yet discussed what behaviors, norms, and interactions produce belonging for a new member on this specific team. That conversation should happen before week two ends, not deferred to a future quarter when the window has already closed.
Recognizing the Sponsor-and-Hold Pattern - Product Requirements
Section titled “Recognizing the Sponsor-and-Hold Pattern - Product Requirements”Problem Statement
Section titled “Problem Statement”A first-generation practitioner who has been a manager for eighteen months has been carrying a decade of unacknowledged debt. The specific friction: she cannot fully articulate, in a professional context, what Dana Reyes did in 2015 when she put an underprepared associate (the writer) forward to lead the Cortland Platform migration, then provided coverage without taking over. The debt surfaces with increasing frequency - most recently when the writer applied the same pattern with a direct report named Marcus and watched it work - but has never been discharged. The result is that Dana has no signal that the thing she did mattered, or that it has replicated.
Affected user: Dana Reyes, formerly principal delivery lead at Trevington Group, now independent consultant.
Frequency: This gratitude has accumulated for approximately ten years. The trigger event (watching the pattern replicate through Marcus) occurred in Q1 of this year. The debt is now acute.
Impact: Low on operational continuity. High on relational completion. The thing that Dana did changed what the writer believed was possible for herself. Dana does not know this.
- Dana receives a clear account of what she did in 2015 - not a general “you were a great mentor” but the specific sequence: she nominated, she stayed present, she did not rescue.
- Dana understands the cost she absorbed. The Cortland project ran four weeks over the original estimate. Dana held the client relationship during that stretch. The writer did not understand at the time that holding a client is a separate and taxing skill from managing a delivery.
- Dana learns that the pattern has replicated. Marcus led the Arriola onboarding with less than two years of experience. He was not ready. He found his footing. The debt is propagating forward.
- The letter does not ask Dana for anything. It is not a setup for a referral request, a recommendation, or a reconnection call. If Dana responds, that is a bonus outcome, not a requirement.
Non-Goals
Section titled “Non-Goals”This is not:
- A general endorsement or a professional recommendation
- An attempt to re-establish a working relationship (the writer is not in Trevington Group’s ecosystem and does not expect to return to it)
- An apology for the four-week overrun on Cortland (that ship has sailed and was not the writer’s alone to carry)
- A request for Dana to validate the writer’s subsequent career decisions
- A document meant to be shared with anyone other than Dana
What success is not: Dana mentioning the letter to mutual contacts. Dana responding with detailed memory of Cortland. Dana feeling that she must say something reciprocal. The letter creates no obligation.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”From Dana’s perspective (the primary reader):
- When I receive this letter, I want to understand exactly what act of mine the writer is describing, so that I do not have to guess or reconstruct context from a decade ago.
- When I read the description of Cortland, I want to feel that the writer understands what it cost - not in a way that is heavy or requires me to confirm the cost, but in a way that shows she thought about it.
- When I finish the letter, I want to feel that something has been completed, not opened. No action required of me.
From the writer’s perspective (the author):
- I want to discharge the debt in a form that matches its weight. A text message is too light. A call requires a response. A letter is proportionate.
- I want to name what Dana did at the level of mechanism, not just outcome. “You believed in me” is true but not useful. “You put your client relationship on the line for four weeks while I figured out stakeholder communication” is the thing.
- I want Dana to know that what she practiced is teachable, and that I have taught it, even if the teaching was unconscious at the time.
Success Metrics
Section titled “Success Metrics”- The letter specifies at least three concrete details that only someone present at Cortland would recognize: the platform involved, the duration of the overrun, and the specific skill (client relationship management) that Dana covered.
- The letter contains no asks. Zero calls to action for Dana.
- The letter can be read in under four minutes. Gratitude that requires significant time to receive is not a gift.
- On re-read, the writer does not find sentences that could have been written to anyone. Every sentence is specific to Dana.
- If Dana responds, she references something specific from the letter, not the letter in general. (This is a lagging indicator and not required for the letter to succeed.)
Open Questions
Section titled “Open Questions”-
Does Dana remember Cortland? She ran twelve engagements in the two years the writer knew her. Cortland was formative for the writer and may have been routine for Dana. The letter should not assume Dana carries the same weight of memory.
-
Does Dana know what client coverage costs? She lived it; she presumably knows. But the writer has spent a decade developing a different understanding of what “holding a client relationship” means operationally, and she is now naming it with more precision than she had at 24. The question is whether Dana will recognize the more technical framing as a sign of growth rather than as the writer over-crediting her.
-
Is the pattern actually Dana’s to own? The writer learned the sponsor-and-hold pattern from Dana. But Dana may have learned it from someone else, may not think of it as a deliberate practice, or may resist having it named as a thing she did intentionally. The letter should describe what happened, not prescribe Dana’s intent. What mattered was the behavior, not the theory behind it.
-
Will a letter land? Dana may be in a period where written correspondence is not how she prefers to be reached. The writer does not have a current address. The letter will go through a mutual contact who agreed to forward it. This adds latency and indirection the writer cannot control.
-
Is ten years too long? The writer is aware that gratitude expressed after a decade could read as delayed, or as driven by the writer’s own milestone (managing Marcus) rather than by genuine regard for Dana. The letter should own the timing without apologizing for it. The timing is part of the story.
Prepared by: the writer Status: draft, ready for final edit before transmission Distribution: single recipient (Dana Reyes) Action required: none
Weekly Rest Practice - Product Requirements
Section titled “Weekly Rest Practice - Product Requirements”Problem Statement
Section titled “Problem Statement”The practitioner - a person whose professional and personal identity has been built around consistent output - has no reliable mechanism for the week to close. On any given day, including the designated rest day, the pattern is to check notifications, assess pending work, and re-engage with production before the prior session has fully wound down. This occurs at least once on every nominal day off, often within the first hour of waking. The result is a sustained low-grade fatigue and a narrowing of perspective that compounds across weeks and months without the person noticing.
Previous attempts at a weekly rest practice have failed within the first month, not from lack of intent but from lack of a clear definition of what the practice was meant to accomplish and what was out of scope. The pull to “just check one thing” is strong enough to end a rest day before it begins. Without a shared definition of success, each failed day is indistinguishable from a reasonable judgment call.
- The week contains one day on which no work-related tools are opened and no production output is generated or expected.
- By the fourth week of consistent practice, the person can report a qualitative difference in perspective and steadiness when entering the following week.
- The rest day is experienced as a chosen act, not as lost time, in at least three of four weeks.
- The pull to check one more thing is noticed before being acted on, rather than only noticed in retrospect.
Non-Goals
Section titled “Non-Goals”- This practice does not aim to optimize total work output. Higher productivity is not a success criterion and is not a reason to continue or abandon the practice.
- The practice does not seek to eliminate the feeling of pull toward work. Changing the relationship with that pull is the goal; removing the feeling is not.
- The rest day is not a day of scheduled self-improvement. Learning goals, personal projects, and “productive” recreation are explicitly out of scope for this version.
- This practice does not define what rest looks like on any specific day. Whether the day involves silence, movement, sleep, or conversation is an implementation detail left to the practitioner.
- This is not a time-management intervention. Existing scheduling decisions outside the rest day remain unchanged.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”- As a person who measures days by output, I want one day per week that is not measured by output so that I can discover what my days feel like without that measure.
- As someone who has failed at this practice before, I want a clear definition of what the practice requires and what it does not require so that a hard week does not look like a legitimate reason to cancel the day.
- As a person who finds unstructured time anxious at first, I want the start of the rest day to be marked by a specific, concrete action so that the transition into rest is a clear boundary rather than an ambiguous drift.
- As a practitioner interested in long-term steadiness, I want to observe whether a consistent rest day changes how the following week feels so that I can evaluate the practice on its actual returns rather than its immediate discomfort.
- As someone whose work does not have natural ending points, I want an external commitment that helps close the week so that stopping does not require a fresh willpower decision each time.
Success Metrics
Section titled “Success Metrics”Success is not measured at the end of the rest day. It is measured across the following week.
- The person can, without consulting notes, name what mattered most in the prior week. This is a proxy for the clarity the practice is meant to return.
- Fewer decisions made in the first two days of the following week are regretted by Thursday. This measures reactivity rather than perfection.
- The rest day does not require the person to defend it to themselves mid-day. Noticing the pull toward work and not acting on it counts as a successful day. Noticing very little pull is a very good day.
- Within eight weeks, at least one person in the practitioner’s regular life observes and names a change in how the person shows up. This tests whether the practice has produced a difference visible outside the person’s own internal account.
Open Questions
Section titled “Open Questions”These are the assumptions that have not yet been tested. The practice should be structured to surface answers over the first eight weeks.
-
What actually restores this person? Prior attempts filled rest days with structured leisure that felt productive without being restorative. It is unknown whether the practice will reveal that rest looks different from what the person assumes. The first weeks may surface this.
-
Is the anxiety at the start of the rest day a signal or a habit? The anxious pull to return to work when rest begins might mean the practice is genuinely costly (a signal worth attending to) or it might be a conditioned response that fades with repetition (a habit worth resisting). The difference matters for how to respond to the feeling. This is unknown.
-
What does a partial rest day cost? Previous attempts ended when a single “small” work task early in the day made the rest of the day feel forfeit. It is untested whether a partial day of rest returns partial benefit or whether the boundary is effectively binary. This should be tested intentionally in one of the early weeks rather than discovered by accident.
-
Does naming the day change the practice? The person has tried quiet days without naming them as rest. Something about the explicit name appears to change the quality of engagement with the day, but it is unknown whether this is essential to the practice or incidental to this person’s psychology.
-
Can the practice survive a high-demand week? Every previous attempt collapsed under genuine work pressure, when rest felt like a cost the person could not afford. The real test of the practice is not the ordinary week but the week when the pull is strongest. This has not yet been tested in the current attempt.
Howard Mallory Departure - Organizational Transition Requirements
Section titled “Howard Mallory Departure - Organizational Transition Requirements”Problem Statement
Section titled “Problem Statement”Howard Mallory, Senior Operations Coordinator at Meridian Industrial Services, retires on August 15th after twenty-six years in the same role. Howard is the primary holder of institutional memory for the Operations division. He knows which clients carry informal expectations that never made it into contracts, which vendors have reliability patterns that do not surface in ticket history, and which internal processes were designed around specific past failures that no one else remembers.
He is also the informal crisis escalation point for at least four teams - not because it is in his job description, but because he is the person those teams learned to call when things went wrong and judgment mattered more than procedure. In the 2019 Fairview client outage, when the documented runbook produced no resolution by hour four, the on-call team called Howard at 11 pm. He was back on the call within three minutes and had a workaround in place by midnight. That event is not in any postmortem. Howard did not write it up.
Howard has mentored informally throughout his tenure. Several engineers and coordinators attribute professional turning points to conversations with Howard that he likely does not remember having. He does not seek credit; the mentorship happened in the margins of actual work.
This transition happens once. There is no opportunity to revisit it after Howard leaves.
- Capture and redistribute the operational knowledge Howard carries that exists nowhere in written form
- Identify the informal relationships and trust networks Howard built that the organization has been relying on without naming them
- Recognize Howard’s contribution in a way that reflects what he actually did - not the title hierarchy he never climbed, but the body of work that made other people’s work possible
- Give the team that has worked alongside Howard a structured opportunity to surface what they learned from him, while he is still present to hear it
- Leave Howard feeling accurately seen, not generically praised
Non-Goals
Section titled “Non-Goals”- This is not a headcount backfill exercise; no single hire will replace what Howard provided, and treating this as a hiring problem would misread the situation entirely
- This is not a knowledge management product launch; the output is not a wiki or a documentation system, and if it becomes one, we will have optimized for the artifact over the knowledge
- This is not a performance review retrospective; Howard’s tenure is not being measured against any framework
- This is not a morale event; if the farewell feels like an HR checkbox, we have failed the goal as thoroughly as if we had skipped it
- This is not about the organization’s loss; any framing that centers the company over Howard has the orientation wrong, and Howard will notice
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”Howard: As the person leaving, I want the recognition to feel like someone actually paid attention - not to my years of service or my job title, but to specific moments and specific people - so that the departure does not feel generic, and so that I leave knowing the effect I had rather than only guessing at it.
Colleagues who worked directly with Howard: As someone who relied on Howard in a real crisis and knows exactly what that meant, I want a space to say what happened and what it cost and what it would have cost without him - so that the institutional record reflects something true rather than something diplomatic.
Newer team members who only knew Howard at the end of his tenure: As someone who joined after Howard’s peak years but watched how the rest of the team treated him, I want to understand what I was near - so that I can name what I observed and carry something forward from it.
The organization’s leadership: As a leader signing off on Howard’s departure, I want to honor him in a way that demonstrates what this organization actually values - so that the team can see that staying steady, building others up, and carrying institutional knowledge is recognized, not just velocity and visible promotion.
People whose careers Howard shaped: As someone who had a career-defining conversation with Howard in the margins of a Tuesday morning, I want a moment to say what happened - with Howard present - so that he knows the effect he had, because he probably does not.
Success Metrics
Section titled “Success Metrics”The following indicate that this transition was handled well. None of these are quantitative, because the relevant outcomes are qualitative:
- Howard leaves knowing that his actual contribution was named, not summarized; the recognition named specific incidents, specific people, and specific years - not “years of dedicated service”
- At least three people who directly attribute a professional turning point to Howard said so to Howard, in person, before he walked out
- The operational knowledge transfer produced a working document that the team reaches for in the next six months - not as a memorial artifact, but because it is genuinely useful in a crisis
- The team does not feel that Howard’s departure was processed; they feel it was marked
- Howard’s name comes up in the next crisis, not as an absence but as a template: what would Howard do here
Open Questions
Section titled “Open Questions”These are the assumptions that have not yet been tested:
-
What does Howard actually want? Howard has never sought recognition. A large public event may misread him. We should ask him directly what he would prefer before planning anything. The risk of getting this wrong is that we honor him in the way we want to give rather than the way he would receive.
-
Who are the people whose careers Howard shaped who are no longer at the company? Several former team members left Meridian years ago. Are they reachable? Would they want to participate? The people who benefited most from Howard may not be the people still in the room.
-
What is the right format for the knowledge transfer? A formal offboarding document may not match how Howard actually knows things. If we hand him a template, he will fill it out dutifully and we will capture the structure but lose the judgment. The format should fit how he thinks, not how the offboarding process was designed.
-
Is leadership prepared to name Howard’s quiet mentorship as a recognized organizational contribution - not as a bonus attribute? If the farewell communication positions Howard’s impact as admirable but supplementary to his “real” job, it will feel like the same thing it always was: invisible. This requires someone in leadership to say plainly that this is what good looks like.
-
What happens to the client relationships that are personal to Howard? At least two long-standing clients have a relationship with Howard specifically, not with Meridian as an institution. Has anyone mapped those relationships? Is there a transition plan that is not simply “Howard will introduce you to someone”? If not, that is the first open question to close.
Checkout Platform v2 - Product Requirements
Section titled “Checkout Platform v2 - Product Requirements”This document was written at the start of the project and revised at each major phase gate. It is being distributed now, at launch, as the official record of what this team set out to build and why. Fourteen months later, every goal on this list has been met.
Problem Statement
Section titled “Problem Statement”Customers trying to complete a purchase on Meridian Commerce fail to reach the confirmation screen at an unacceptable rate. The abandonment rate in the final payment step has averaged above 30 percent for two years - a number that remained stubbornly high despite repeated incremental fixes to the existing flow.
The existing checkout system was built in 2018 on a framework the rest of the engineering org has since moved away from. Over five years of patch work, it accumulated state management that no engineer could fully trace, third-party integrations that could not be upgraded without risk of breaking payment, and a session model that failed silently under load. The result is a system that works most of the time but fails in ways that are difficult to observe, difficult to reproduce, and impossible to fix without touching things that should not be touched.
The failure is not random. Abandonment spikes on high-traffic days, when mobile users attempt to switch payment methods mid-flow, and when customers return to a session after leaving for more than 20 minutes. These are precisely the moments when completing a purchase matters most. The system fails the customer when the customer needs it to hold.
- Reduce final-step cart abandonment to below 15 percent, measured over a rolling 30-day window, within 60 days of full rollout
- Achieve a mobile checkout completion rate within 3 percentage points of desktop, closing a gap that has persisted since mobile traffic exceeded desktop
- Reduce the median time from payment entry to confirmation to under 4 seconds on a standard connection
- Enable the platform team to ship checkout improvements on a weekly cycle, without a full regression pass before each release, by establishing clear integration contracts between checkout and downstream services
Non-Goals
Section titled “Non-Goals”The following are explicitly out of scope for this release. Each deserves its own initiative and its own requirements document.
- Guest checkout and account consolidation: The current distinction between guest and registered checkout is out of scope. Changing the account model while rebuilding the payment flow would double the risk surface. This project delivers a rebuilt flow for existing account types only.
- New payment methods: Adding buy-now-pay-later, additional digital wallets, or alternative payment rails is not in scope. The goal is to fix the foundation, not to expand it while it is being replaced.
- Internationalization: Currency handling, tax calculation, and localization for non-US markets are out of scope. The rebuilt platform should make internationalization achievable; it does not need to deliver it.
- Checkout analytics redesign: The current analytics instrumentation is inadequate, but redesigning the measurement layer is a separate initiative. This project will preserve existing events and add session-level logging sufficient for the success metrics above. It will not deliver a new analytics product.
- Cutting over before the new system has proven itself: The old checkout remains in production and handles 100 percent of traffic until the new one has been validated under real conditions. Migrating prematurely to hit a date is explicitly not a goal.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”- As a customer completing a purchase, I want the checkout flow to hold my payment details and cart state reliably across a brief interruption, so that I can return and complete my purchase without starting over
- As a customer on a mobile device, I want to switch between payment methods without losing my place, so that I can use the method that is right for this purchase without abandoning the cart
- As an ops associate investigating a failed order, I want a clear, queryable record of what happened during a checkout session, so that I can confirm what the customer experienced and make the right call on escalation
- As an engineer shipping a checkout improvement, I want a defined contract between the checkout surface and the services behind it, so that I can scope a change with confidence about what I am responsible for and what I am not
Success Metrics
Section titled “Success Metrics”Progress on these metrics will be evaluated at 30 days and 60 days post-full-rollout. The 60-day read is the definitive one; the 30-day read is a leading indicator.
- Final-step abandonment rate below 15 percent (primary metric)
- Mobile-to-desktop completion gap below 3 percentage points
- Median payment-to-confirmation time under 4 seconds at the 50th percentile; under 10 seconds at the 95th percentile under peak load
- Zero silent failure modes: any checkout session that fails must produce a logged, queryable event within 5 seconds of failure
- Engineering cycle time: a contained change touching a single integration point should be deployable without a full regression pass
Open Questions
Section titled “Open Questions”These questions were unresolved when this document was first written. Answers discovered during the project are noted.
1. Can the old and new checkout systems run in parallel without creating inconsistent order state? The plan calls for long-lived parallel operation, but the data model had not been audited for conflicts at the time this was written. Resolved: The data model required a migration that was not in the original scope. The team identified this in month two and negotiated the additional work before it became a crisis.
2. What does peak load look like for the new system? The existing system has never been load-tested at scale because any test risked destabilizing production. The new system needs to be validated before traffic is migrated, but the ceiling is unknown. Resolved: Load testing was built into the rollout plan. The system held through the two highest-traffic days of the year - the first during the incremental rollout and the second at full traffic - without a performance incident.
3. Will new integration contracts break existing downstream consumers? Several services consume checkout events in ways that are undocumented. A silent contract change could break order processing without visible checkout errors. Resolved: The team ran a four-week audit of downstream consumers before cutting the first integration contract. Two consumers required coordinated changes. Both were completed before the first traffic migration.
4. What is the rollback plan if the new system degrades during rollout? Traffic migration will be incremental, but the rollback path was not designed at the time of this writing. Resolved: Rollback capability was built before the first traffic migration. It was exercised twice in staging and once during a production near-miss in month eleven. Both times it worked. The month-eleven incident is the reason the first launch date slipped.
5. Who owns the decision to cut over fully, and what evidence is required? There is no named decision-owner or defined evidence threshold for the final traffic migration. Resolved: Rania Osei, the platform lead, was named as the decision owner in month four. The threshold was defined as 30 days at 80 percent traffic with abandonment tracking below target. The cutover decision was hers. She made it on the third attempt, with the data in hand.
Checkout Platform v2 shipped to 100 percent of traffic on March 14, 2025.
Fourteen months of parallel operation. Two near-misses that tested the rollback path and confirmed it worked. Two launch dates that slipped because the evidence was not there yet, and a lead who called that correctly both times. A peak-load window the system held cleanly on its first real test at full traffic.
The five open questions above were answered the hard way. That is what the work cost, and what it took.
Hybrid Work Model - Product Requirements
Section titled “Hybrid Work Model - Product Requirements”Problem Statement
Section titled “Problem Statement”Employees across the company currently operate under an ambiguous work location policy that has drifted since the organization expanded hiring during a fully remote period. Three distinct groups experience the ambiguity differently:
-
Office-first employees and leaders who believe that co-location drives better alignment, faster trust formation, and the kind of hallway conversation that does not happen on a calendar invite. They feel that full flexibility has eroded the shared context teams need to do hard things together.
-
Fully remote employees, many of whom were hired specifically because they lived outside a commuting radius. They accepted roles based on an implied or explicit promise of location flexibility. A blanket return-to-office mandate would require relocation, commutes of an hour or more each way, or exit.
-
Managers caught between both camps, who cannot make reliable commitments to their teams because the policy keeps shifting. They improvise coordination around an unclear standard, which creates uneven enforcement and interpersonal friction.
The problem surfaces every week. It appears as repeated debates in planning sessions, inconsistent expectations between teams, resentment when policies appear to favor certain roles, and a slow erosion of team cohesion that no single incident can be pointed to as the cause.
The current state is not a decision - it is a deferred decision. The cost of deferring keeps compounding.
- Establish a predictable, written location policy that every employee can describe from memory within one quarter of rollout.
- Ensure every team has at least two shared in-person anchor days per month on which overlap is reliably available for collaboration, trust-building, and unstructured connection.
- Give employees who live outside a commute radius or who have documented caregiving constraints a defined accommodation path that does not require manager discretion to activate.
- Reduce manager escalations related to location inconsistency to near zero within two quarters of launch.
- Retain employees hired under a remote-first expectation by honoring the implicit or explicit terms of their hiring.
Non-Goals
Section titled “Non-Goals”This policy does not address:
- Individual performance management. Whether someone is in the office or remote does not determine whether they are doing good work. This document takes no position on performance criteria.
- Real estate or office cost optimization. Decisions about lease footprints, hoteling ratios, and facility investment are downstream of policy; they are not drivers of it.
- Tooling and async-work infrastructure. This document does not prescribe which tools teams use, how meetings are run, or what the operating norms for async communication look like. Those are implementation decisions for teams once the policy boundary is set.
- A universal definition of “anchor day.” This document defines that anchor days exist and what they are for; it does not define the mechanics of how individual teams schedule them.
- Fully remote exceptions for roles that require on-site presence. Roles tied to physical infrastructure or regulated facilities operate under separate criteria not governed by this document.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”As an office-first leader, I want my team to share physical space on predictable days so that I can invest in the relationship-building moments that cannot be manufactured on a video call - and so my direct reports build relationships with each other that make them more effective collaborators when they are apart.
As a fully remote employee hired for a distributed role, I want my location flexibility to be protected by a written policy rather than manager goodwill so that I can plan my life, my housing, and my schedule without fear that the ground will shift under me.
As a manager, I want a simple, written policy I can hand to any team member so that I spend my time doing management work, not policy interpretation work.
As an employee with no strong location preference, I want clarity about what is expected so that I can make decisions about where I live and how I structure my week without anxiety about changing expectations.
As an HR business partner, I want the policy to have clear carve-outs and accommodation criteria so that I can apply it consistently and defend edge case decisions.
Success Metrics
Section titled “Success Metrics”The policy works if the following are true six months after rollout:
- Employee survey responses on “I understand the company’s expectations about where I work” cross 80% agree or strongly agree (from a baseline measured before rollout).
- Voluntary attrition among employees hired under a remote-first expectation is no higher in the two quarters after rollout than the two quarters before.
- Manager-initiated location-policy escalations to HR drop to under five per quarter company-wide.
- At least 80% of teams report holding a minimum of two in-person anchor events in the first quarter after rollout.
- Zero involuntary terminations attributed solely to an employee’s pre-existing location arrangement that was honored at hire.
Open Questions
Section titled “Open Questions”The following assumptions have not yet been validated and should be treated as risks:
-
What counts as an anchor day for a team whose members are spread across multiple metro areas? The policy as written assumes that team members can plausibly assemble in a shared location. This is untested for teams with members in three or more geographic regions.
-
Will office-first leaders accept two anchor days per month as sufficient? The policy’s credibility with the skeptical office-first audience depends on whether two shared days per month actually changes the collaboration experience in ways they value. This has not been piloted.
-
Is the accommodation path clear enough to avoid requiring manager discretion? The intent is that the path be self-service, but whether the criteria are unambiguous enough to function that way is untested.
-
What happens to the policy during seasonal peaks or product crunches? Teams may want to increase in-person time during critical periods. Whether surge presence is voluntary, encouraged, or required is an open question this document does not resolve.
-
How does the policy apply to employees hired after the rollout date? The current draft focuses on honoring existing hiring conditions. Whether new hire agreements carry different expectations is deferred.
-
What is the enforcement mechanism? The policy states what is expected. It does not yet define what happens when a team or individual does not meet the anchor day requirement. Whether this is a performance matter, a manager-reported metric, or an honor system is unresolved.
Tidemark v1.0 - Product Requirements
Section titled “Tidemark v1.0 - Product Requirements”Status: launch-ready | Author: Priya Osei, Product | Version: 1.0 | Target launch: July 3, 2026
Problem Statement
Section titled “Problem Statement”Small product teams - typically two to fifteen people - that conduct regular customer conversations face a structural failure: feedback arrives in fragments. A customer flags an issue in a support thread. A founder takes notes in a document during a sales call. A designer hears a pattern in a user interview and pastes a quote into a chat channel. Each signal is captured somewhere, but nowhere are they gathered, compared, and ranked against each other.
The PM or founder who owns the roadmap becomes the manual integration layer. They read across all these sources, de-duplicate in their head, and try to construct a priority order in a spreadsheet or a notes file. This process is lossy. It is slow. And it is invisible to the rest of the team: the engineer picking up the next sprint and the designer shaping the next flow cannot see what the feedback actually said or why the priorities landed where they did.
The result is three compounding problems:
- Signal gets dropped because no one has bandwidth to re-read every source before a planning meeting.
- Prioritization decisions look arbitrary to people who were not in every conversation.
- Roadmaps drift from what customers actually said, because the synthesis lives in one person’s working memory.
This pattern repeats every planning cycle for teams of this size. The bottleneck is not collecting feedback - it is synthesizing it into something a whole team can act on and defend.
- A team member can go from a pile of raw feedback themes to a ranked, shareable roadmap in under 30 minutes of active work.
- The ranked themes are visible to every team member involved in prioritization decisions, without requiring a meeting or a forwarded file.
- The reasoning behind the rank order is attached to the roadmap and travels with it, so that anyone who reads the roadmap can understand why it prioritized as it did.
Non-Goals
Section titled “Non-Goals”For the v1.0 launch, Tidemark will not solve the following:
- Integrations with external tools. Feedback ingestion is manual or via CSV import only. Connectors to the ticket tracker, chat tool, CRM, or survey platform are deferred to a future release.
- Automated AI synthesis of raw transcripts. Tidemark does not process raw interview recordings or unstructured text. Users bring already-synthesized themes; the product helps them prioritize and share, not extract.
- Enterprise authentication and access controls. Single sign-on, role-based permissions, and multi-workspace administration are out of scope. Tidemark v1.0 is designed for teams of two to fifteen.
- Analytics or usage data as a prioritization input. Rank order is derived from the criteria the team sets, not from behavioral telemetry or product analytics feeds.
- Notification or calendar integrations. Alerts and reminders exist inside the product only. No email or calendar hooks in this release.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”Primary user: PM or founder on a small team
- As a PM, I want to add the themes I pulled from customer conversations so that I have them in one place rather than distributed across documents and chat threads.
- As a PM, I want to apply my team’s prioritization criteria to each theme so that the rank order reflects our actual decision framework, not a generic default.
- As a PM, I want to generate a shareable view of the ranked roadmap so that I can send it to engineers, leadership, and customers without reformatting.
- As a PM, I want to attach the source evidence behind each theme so that anyone reading the roadmap can trace a priority back to specific customer language.
Secondary user: engineer or designer reviewing the roadmap
- As an engineer, I want to see the reasoning behind each ranked priority so that I understand why we are building this item and not another one.
- As a designer, I want to add a newly discovered feedback theme to an existing roadmap without restructuring the whole document, so that the roadmap stays current without requiring PM intervention for every update.
Secondary user: customer stakeholder receiving a shared roadmap
- As a customer who gave feedback, I want to see how my input shaped the team’s priorities so that I know my voice was heard and I can stay engaged with the product.
Success Metrics
Section titled “Success Metrics”We will assess v1.0 success at 60 days post-launch against the following:
Activation
- The share of new signups who create at least one ranked roadmap within 7 days of signup. Baseline will be established from the first two cohort weeks; the target will be set once we have that baseline.
Retention
- Teams that created a roadmap in week 1 return to the product at least once in weeks 3 through 6.
Shareability
- The majority of teams that complete a ranked roadmap generate at least one shared link.
Satisfaction proxy
- In the first post-launch user survey, the ratio of respondents who say Tidemark replaced their previous feedback-synthesis process to those who say it did not exceeds 2 to 1.
Failure signals - these would trigger a priority reassessment:
- More than a third of users who start a roadmap abandon it before completing the ranking step.
- Inbound support volume about connecting to external tools exceeds a threshold suggesting that manual import is a real blocker, not merely an inconvenience.
Open Questions
Section titled “Open Questions”The following assumptions are load-bearing and have not been validated. Each is a risk that could require a pivot.
-
Manual import is acceptable at launch. The working hypothesis is that teams will tolerate pasting themes because the painful step is synthesis and prioritization, not collection. This has not been tested with high-volume teams that handle more than a few dozen feedback inputs per week.
-
The PM or founder is the right primary user. Discovery interviews skewed toward PMs and early-stage founders. We have not confirmed the value proposition holds for teams where a designer or an engineer owns the roadmap process.
-
Sharing outside the team is a genuine use case, not an edge case. Multiple discovery interviewees mentioned sending roadmaps to customers. We are building the shared-link feature on that signal, but we have not verified that outbound sharing is common enough at this stage to be a required capability versus a value-add.
-
“Ranked roadmap” maps to a shared mental model. Tidemark uses “ranked” to mean ordered by user-defined prioritization criteria. Several discovery participants used “ranked” to mean sequenced by delivery date. The distinction affects how the output is labeled and explained during onboarding. The terminology has not been tested with a naive user.
-
30 minutes is achievable with the current onboarding flow. The 30-minute activation goal is a hypothesis derived from the number of steps in the flow. No moderated usability test has been run end-to-end. If the first cohort data shows median time significantly above 30 minutes, onboarding is the first place to investigate.
Owner: Priya Osei | Last updated: June 26, 2026 | Status: launch-ready
Year-End Personal Reset - Requirements
Section titled “Year-End Personal Reset - Requirements”Problem Statement
Section titled “Problem Statement”Over the past fourteen months, I encountered two compounding losses that did not resolve on a clean timeline and did not offer the kind of closure that makes reflection feel satisfying. First, a project I will call Meridian - a data tool I had spent roughly two years building with a small team - failed to find sustainable traction by Q3 and was wound down in October. Second, a close professional friendship with my co-founder Ren shifted irrevocably in the aftermath, not from a single conflict but from the accumulated weight of decisions made under pressure. Both losses happened within six weeks of each other.
The problem is not that these things happened. The problem is that I do not yet have a working model for what to carry forward and what to put down. Without that model, I am at risk of either overcorrecting (treating the year as evidence that I should do everything differently) or undercorrecting (resuming previous patterns without examining which of them contributed to the failures). The frequency of both: ongoing. The impact: I am making decisions under incomplete accounting.
This document does not attempt to resolve the losses. It attempts to define what a successful reckoning looks like, what it explicitly does not include, and what questions remain genuinely open.
The goals here are behavioral and observable, not emotional. I am not trying to reach a feeling; I am trying to establish a set of durable commitments.
- G1: By the end of Q1, I can state clearly what I got wrong on Meridian - not a catalog of external obstacles, but the decisions I made and the judgment errors I repeated across the project’s life.
- G2: By mid-year, I have made one deliberate professional decision that reflects what I learned, rather than defaulting to the most familiar or safest path available.
- G3: I have had at least one direct conversation with Ren that I did not avoid out of discomfort. Not to repair everything. Not to adjudicate the wind-down. Just to not let avoidance become the permanent posture between us.
- G4: Writing is happening at a consistent rate by March - not to produce anything in particular, but because the impulse returned on its own. One session per week is the threshold.
Non-Goals
Section titled “Non-Goals”These are things I am explicitly not trying to accomplish with this reckoning. This section matters as much as the goals, because scope creep in a personal reckoning looks like substituting easier questions for harder ones.
- NG1: Reaching resolution. The year did not resolve. Writing about it will not resolve it either. The goal is not to arrive at a clean narrative; it is to be honest about a messy one. Closure is not on the roadmap.
- NG2: Reframing the losses as gifts. Meridian failing was not a gift in disguise. The shift with Ren was not a gift in disguise. Treating them that way would require distorting what actually happened, and the distortion would be detectable to anyone who was there.
- NG3: Rebuilding immediately. The instinct to start a new project is real and familiar and almost certainly premature. This reckoning does not include a launch plan. The absence of a launch plan is deliberate.
- NG4: Determining what Ren got wrong. Whatever happened between us involved two people making decisions under sustained pressure. My scope here is the decisions I made and the patterns I brought. The accounting of what should have gone differently on his end is not mine to write.
- NG5: Extracting a general theory of failure. What happened with Meridian is specific. Extracting abstract lessons about “startups” or “creative work” risks flattening the particulars that made this failure instructive. Generalizing too fast is how specific lessons get laundered into generic wisdom.
User Stories / Jobs-to-be-Done
Section titled “User Stories / Jobs-to-be-Done”These are written from where I actually am, not where I wish I were.
- As someone who built something that did not work, I want to name the three or four decisions that compounded into the failure, so that I can distinguish between bad luck and repeated pattern - and stop assigning the bad luck to myself and the repeated patterns to circumstance.
- As someone whose close working relationship did not survive the stress of a wind-down, I want to understand what I prioritized during that period and what I sacrificed without noticing, so that I do not carry the same blind spots into the next thing I build with someone.
- As someone who stopped writing for most of the year while the project consumed all available space, I want to return to writing for its own sake rather than as a symptom of having leftover capacity, so that it is not the first thing I abandon when the next high-stakes period arrives.
- As someone who handled the year’s hardest months with more isolation than necessary, I want to build the habit of asking for help one threshold earlier than feels comfortable, so that the next difficult stretch does not have to be carried entirely alone.
Success Metrics
Section titled “Success Metrics”These are indicators, not targets. I will use them to calibrate whether the reckoning is working, not to grade myself against them.
- Three months from now, I can describe what I got wrong on Meridian without resorting to “the market wasn’t ready” or equivalent external attribution as the primary explanation. If I cannot, the reckoning has not gotten deep enough.
- I have not started a new project primarily to avoid sitting with the previous one. The test is not whether I start something new; it is whether the new thing is chosen or escaped-into.
- The avoidance pattern with Ren has not calcified into permanent distance. Even one genuine exchange - not resolution, just contact - registers as movement.
- Writing is happening at some consistent rate by mid-Q1. The content does not matter. The consistency does.
Open Questions
Section titled “Open Questions”These are the assumptions I have not yet tested and the things I genuinely do not know. An honest reckoning names these rather than papering over them.
- OQ1: I believe the core problems with Meridian were in the product decisions I made in months four through eight, before we raised the second round. I have not yet examined this closely enough to know if that belief is accurate, or if I am assigning the failure to the period that feels most under my control - which would be a different and less useful story.
- OQ2: I do not know whether the shift with Ren is permanent or whether it is the kind of distance that can close given enough time and one honest conversation. I am inclined to believe it can close. I may be wrong, and being wrong about this would change what the reckoning asks of me.
- OQ3: I do not yet know whether the instinct to build again is a healthy return of drive or a response to discomfort with stillness. These feel different but look the same from the inside. This question probably cannot be answered until mid-year, and trying to answer it earlier will produce an unreliable answer.
- OQ4: I have not fully accounted for how much of the year’s difficulty was compounding. The relationship strain made the project harder. The project’s pressure accelerated the relationship strain. The two losses may not be as separate as I have been treating them, and if they are entangled, the lessons from each may be entangled in ways I have not yet untangled.
- OQ5: This document defines the reckoning. It does not define what comes after. I do not yet know what I want to build, and I am not ready to write that document. What I am ready to do is finish this one.
status: draft owner: personal next-review: Q1
Appears in diff-pairs
Section titled “Appears in diff-pairs”- prd vs adr (varies format)
- prd vs one-pager (varies format)