Files

T

root c65fce24e4 技能备份 - 2026-04-15 (40个技能)

2026-04-15 18:53:15 +08:00

12 KiB

Raw Blame History

PM Artifacts & Delivery

Compressed reference for the full PM artifact lifecycle: from proto-personas and problem framing through PRDs, user stories, epics, story maps, and end-of-life communications.

PRD Development

10-section document, built over 2-4 days.

Template structure (10 sections):

Executive Summary -- "We're building [solution] for [persona] to solve [problem], resulting in [impact]."
Problem Statement -- Who, what, why, evidence (quotes, analytics, tickets)
Target Users & Personas -- Primary + secondary proto-personas
Strategic Context -- OKRs, TAM/SAM/SOM, competitive landscape, "why now?"
Solution Overview -- High-level description + user flows (not pixel specs)
Success Metrics -- Primary metric (optimize), secondary (monitor), guardrail (don't regress)
User Stories & Requirements -- Epic hypothesis + broken-down stories with acceptance criteria
Out of Scope -- Explicit exclusions with rationale
Dependencies & Risks -- Technical, external, team; risks + mitigations
Open Questions -- Unresolved decisions needing discovery

Metrics structure: Always define current baseline, target, and measurement timeline. Format: "Metric: Current X -> Target Y, measure Z days post-launch."

Phase sequence:

Day 1: Exec summary (30m) + Problem (60m) + Personas (30m) + Strategy (45m)
Day 2: Solution (60m) + Metrics (30m) + Stories (90-120m)
Day 3: Scope/Dependencies (30m) + Review (60m)

User Stories

Format (Mike Cohn + Gherkin):

As a [specific persona], I want to [action], so that [outcome/motivation].

Scenario: [description]
Given: [preconditions -- multiple Givens OK]
When: [single trigger event -- aligns with "I want to"]
Then: [single outcome -- aligns with "so that"]

Quality gates:

"As a" uses specific persona, not generic "user"
"So that" states motivation, not restatement of action
One When, one Then per story. Multiple = split signal.
Acceptance criteria are testable by QA -- no "better experience" or "faster"
Summary is value-centric: "Enable Google login for trial users" not "Add login button"

Splitting Stories

8 patterns applied in order (Richard Lawrence / Humanizing Work). Stop at first match:

#	Pattern	Signal	Split strategy
1	Workflow steps	Multi-step sequence	Thin end-to-end slices (full workflow, increasing sophistication)
2	Business rules	Different rules per scenario	One story per rule variation
3	Data variations	Different data types/formats	One story per data type, simplest first
4	AC complexity	Multiple When/Then	One story per When/Then pair
5	Major effort	Hard first build, easy additions	"Implement one + add remaining"
6	External deps	Multiple APIs/third parties	One story per dependency boundary
7	DevOps steps	Infrastructure/deployment work	Split by operational complexity
8	Tiny Acts of Discovery	High uncertainty, none above apply	Time-boxed experiments, not stories

Validation after split: Each piece must (a) deliver user value independently, (b) be testable independently, (c) fit in a sprint (1-5 days), (d) all pieces combined equal the original.

Critical rule: Always split vertically (front-end + back-end = user value). Never horizontally ("Build API" / "Build UI").

Story Mapping

Jeff Patton framework -- 2D map:

Horizontal (left-right): Activities in narrative/workflow order = backbone
Vertical (top-down): Priority within each activity

Hierarchy: Segment -> Persona -> Narrative (goal) -> Activities (3-5) -> Steps (3-5 per activity) -> Tasks (5-7 per step)

Building the map:

Define segment + persona + narrative (one-sentence JTBD goal)
Identify 3-5 backbone activities in sequential workflow order
Break each activity into steps (user actions, observable, logical sequence)
Break steps into tasks (granular, prioritizable)
Prioritize vertically: top = MVP, middle = R2, bottom = future
Draw horizontal release lines

Walking skeleton: Top-priority task from EVERY activity = minimal end-to-end functionality. Build across all activities incrementally, not one activity fully before starting the next.

Release slicing:

R1 (Walking skeleton): Simplest version across all activities
R2 (Enhanced): Second-priority tasks improving core workflow
R3 (Polish): Nice-to-haves, edge cases, optimizations

Epics

Epic Hypothesis

Template (Tim Herbig / Lean UX):

If we [specific action/solution]
for [specific persona]
Then we will [measurable outcome]

Tiny Acts of Discovery: 2-3 lightweight experiments before full build.

Types: prototype + user test, concierge test, landing page test, Wizard of Oz, A/B test
Constraint: days/weeks not months; cheap; falsifiable

Validation measures:

We know our hypothesis is valid if within [2-4 weeks]
we observe:
- [Quantitative: "20% increase in activation rate"]
- [Qualitative: "8/10 users say it saved time"]

Decision gate: Validated -> write user stories. Invalidated -> kill or pivot. Inconclusive -> more experiments.

Epic Breakdown (9 Patterns)

Pre-split: INVEST check (Independent, Negotiable, Valuable, Estimable, Small, Testable). If not Valuable, STOP -- combine with other work, don't split.

9 patterns applied sequentially (superset of story splitting):

Workflow steps -- thin end-to-end, NOT step-by-step
Operations (CRUD) -- "manage" = Create + Read + Update + Delete
Business rule variations -- each rule = separate story
Data variations -- add data types just-in-time
Data entry methods -- basic input first, fancy UI later
Major effort -- implement one + add remaining
Simple/Complex -- simplest core first, variations later
Defer performance -- "make it work" then "make it fast"
Break out a spike -- time-box investigation when uncertainty blocks splitting

Meta-pattern across all: Identify core complexity -> list variations -> reduce to one complete slice -> make other variations separate stories.

Evaluate splits: (a) Does it reveal low-value work you can kill? (b) Are resulting stories roughly equal-sized?

Cynefin adjustment: Low uncertainty = find all stories, prioritize by value. High uncertainty = identify 1-2 learning stories only. Chaos = defer splitting, stabilize first.

Proto-Personas

Hypothesis-driven persona, not validated research. Created in hours from available data.

Template sections:

Name -- alliterative, memorable ("Manager Mike")
Bio & Demographics -- behavioral, not just age/location. Include career, online presence, tech habits.
Quotes -- real or representative; revealing mindset, not facts
Pains -- specific and product-relevant ("3 hrs/week copying data between tools")
What they're trying to accomplish -- observable behaviors and outcomes
Goals -- short-term + long-term, personal + professional
Attitudes & Influences -- decision authority, influencers, beliefs affecting adoption

Mark uncertainty: Tag unvalidated items with [ASSUMPTION--VALIDATE]. Plan research to fill gaps. Limit to 1-2 personas initially.

Press Release / PRFAQ

Amazon Working Backwards format. Written BEFORE building. Planning tool, not launch copy.

Structure:

Headline -- benefit-focused, specific ("Cut Invoice Processing by 60%")
Dateline -- city, date
Introduction -- what launched, for whom, key benefit (2-3 sentences)
Problem paragraph -- specific customer problem with data
Solution paragraph -- outcome-focused, not feature list
Executive quote -- customer-empathetic, visionary (not "excited to innovate")
Supporting details -- additional benefits with data
Boilerplate -- company background
CTA + media contact

Litmus tests: Would a customer care? Is the problem clear? Are benefits measurable? Is it jargon-free? Does it survive "so what?"

Storyboards

6-frame narrative arc for pitching, alignment, and emotional validation.

Frame	Name	Content
1	Main character	Persona + context (specific, not "busy professional")
2	Problem emerges	Challenge + how it affects life
3	"Oh crap" moment	Escalation creating urgency
4	Solution appears	Realistic discovery of product
5	"Aha" moment	Breakthrough experience (outcome, not feature demo)
6	Life after	Improved state with specifics

Visual style default: Fat-marker sharpie sketches, minimal, monochrome. Low-fidelity is fine.

7 input questions: Who is the character? What problem? What's the escalation? How is solution introduced? What's the breakthrough? What's life after? Visual style preferences?

Recommendation Canvas

11-section strategic proposal for AI/high-uncertainty product decisions. Executive-friendly.

Business Outcome -- [Direction] [Metric] [Outcome] [Context] [Criteria]
Product Outcome -- same format, customer perspective
Problem Statement -- persona-centric narrative
Solution Hypothesis -- If/Then + Tiny Acts of Discovery + Proof-of-Life measures
Positioning Statement -- For/That need/Is a/That + Unlike/Provides differentiation
Assumptions & Unknowns -- explicit, testable
PESTEL Risks (Investigate) -- Political, Economic, Social, Tech, Environmental, Legal (specific, not generic)
PESTEL Risks (Monitor) -- lower priority watch list
Value Justification -- data-backed case for C-level ("addresses #1 pain point, $500k ARR impact")
Success Metrics -- SMART format
What's Next -- ordered action steps

End-of-Life Communication

9-section empathy-first EOL message. Never send without a complete transition plan.