Skip to content

Product management knowledge base

Synthesized reference for software, hardware, UI/UX, data-intensive, and AI/ML product work. This file is not legal advice; EU AI Act and similar entries are pointers for compliance awareness — verify with counsel.

Canonical URL list: research/SOURCE_INDEX.md (initial harvest 2026-03-19; AI PM agent, design methodology, regulated medtech design, and RSNA ICH evidence-map deltas 2026-05-09; some core sources are intentionally re-fetched across passes).

0. How to use this KB

When you need… Start with sections…
Org model, empowerment, discovery cadence §1 Traditional / software
Physical product, gates, long-cycle NPD §2 Hardware / NPD
UX strategy, design methods, Design Thinking, UCD/HCD, Service Design, Double Diamond, JTBD vs personas §3 UI / UX
Metrics, prioritization scores, roadmaps §4 Data, prioritization, roadmaps
ML viability, responsible AI, LLM security, regulation, regulated medtech/SaMD §5 AI / ML
Product idea framing, defensibility, what to optimize for first §6 Ideation & strategy vocabulary
Backlog hygiene — ordering, refinement, DEEP/INVEST, discovery vs delivery §7 Backlog management · BACKLOG_BEST_PRACTICES.md (public URL list)
AI PM agent work — context packet, workflow routing, templates, agent guardrails §9 AI PM agent operating layer · context/AI_PM_AGENT_CONTEXT.md · workflows/AI_PM_WORKFLOWS.md
Plain definitions, acronyms, non-developer onboarding vocabulary; Category for user-outcome filtering GLOSSARY.md

Changelog: 2026-05-09 — RSNA ICH evidence-map POC added in research/2026-05-09-rsna-ich-evidence-map-poc.md; 6-source RSNA/ICH delta added to SOURCE_INDEX.md. 2026-05-09 — §5.5 Regulated healthcare / medtech design added; 8-source regulated-medtech delta added. 2026-05-09 — §3 UI / UX expanded with design methodology: Design Thinking, UCD/HCD, Service Design, Service Blueprinting, and Double Diamond; 8-source design-methodology delta added. 2026-05-09 — §9 AI PM agent operating layer added; 13-source delta for PM frameworks, context engineering, workflows, and reusable templates. 2026-03-21 — §7 split: public best practices + abstract layering; curated URLs moved to BACKLOG_BEST_PRACTICES.md. 2026-03-20 — §7 Backlog management (workspace Purpose → Epic → Story, DEEP/refinement pointers). 2026-03-20 — GLOSSARY: Parent outcome categories + BL-29. Link to GLOSSARY.md for terms sheet. §6 workspace capture (ideation example, defensibility, choice lenses). 2026-03-19 — Initial synthesis from 27 web sources (SOURCE_INDEX.md).

1. Traditional software product management

1.1 Empowered teams vs “IT mindset”

Strong product orgs orient teams to serve customers in ways that meet business needs, not merely “serve the business” with feature lists. Empowerment depends on trust, leadership (vision, strategy, principles, priorities, evangelism), and management (staffing, coaching, velocity of learning). OKRs often express org-level priorities; teams should be missionaries, not mercenaries.

Sources: SVPG – Empowered product teams

1.2 Product discovery (why scheduling it like construction fails)

Discovery validates real demand and a solution that is usable, useful, and feasible. Treating discovery as a fixed calendar phase ignores that invention is creative and nonlinear; teams must change course from evidence. Faster discovery reduces wasted engineering on expensive “production prototypes.”

Sources: SVPG – Product discovery

1.3 Dual-track agile → continuous discovery + delivery

Discovery generates validated backlog items; delivery ships releasable software. Prefer collaboration (PM + design + engineering) over mini-waterfalls of handoffs. Validate before production code when possible (“fake it before you make it”). Cagan later emphasizes continuous discovery and continuous delivery over over-focusing on the “dual-track” label; many teams blend Scrum timeboxing with Kanban-style continuous flow.

Sources: SVPG – Dual-Track Agile, SVPG – Continuous discovery

1.4 Shape Up (fixed cycles, betting table)

Basecamp’s Shape Up caps risk with appetite (time budget), shaping work before commitment, and cool-down — an alternative to backlog thrash and infinite estimation. Full method is book-length; use when teams need strategic resource bets rather than passive queue ordering.

Sources: Shape Up

1.5 Lean Startup: validated learning and MVP

Startups (and intrapreneurial teams) should treat effort as experiments: “Should this be built?” and “Can we build a sustainable business?” Build–measure–learn, MVP, and pivot/persevere decisions reduce stealth development without customer contact. Validated learning is the unit of progress under uncertainty.

Sources: Lean Startup – Methodology, Wikipedia – MVP

1.6 User stories and narrative backlog

User story mapping orders the user’s journey horizontally and release slices vertically — avoiding pure feature arguments and anchoring backlog to outcomes along a narrative.

Sources: Jeff Patton – User story mapping

2. Hardware and classical NPD

2.1 New product development (NPD) structure

NPD spans fuzzy front-end (ideation, opportunity analysis through pre-technical evaluation), design, implementation/verification, and commercialization. Complex engineered goods (aerospace, automotive) often use integrated product teams, long horizons, and heavy design–manufacturing coupling (QFD, DFM/DFA).

Sources: Wikipedia – New product development

2.2 Phase-gate (stage-gate) governance

Work breaks into phases separated by gates: go/kill and prioritization based on business case, risk, and resources. Effective gates use clear criteria (must/should meet) and portfolio discipline (“gates with teeth”). Tradeoff: structure aids oversight but can dampen creativity if misapplied.

Sources: Wikipedia – Phase-gate process

PM takeaway: Software teams borrow gate thinking for regulated devices (medical, auto); pair with Lean/Agile execution inside phases where allowed.

3. UI / UX–centric product work

3.1 UX roadmaps (Now / Next / Future)

A UX roadmap is a living strategic artifact: beneficiary + need, business outcome, owner, themes across Now / Next / Future. Distinguish from release plans (features/dates), Kanban execution boards, backlogs (delivery granularity), and customer-journey maps (as-is experience research).

Sources: NN/g – UX roadmaps

3.2 Design thinking (six phases)

IDEO/Nielsen Norman distillation: empathize, define, ideate, prototype, test, implement within buckets understand → explore → materialize. Process is iterative, not strictly linear; implementation is often neglected — “more design doing.”

Use design thinking when the product team needs a shared problem-solving loop: build empathy, define the right problem, diverge on ideas, prototype cheaply, test with users, and carry learning into implementation. Do not treat the phases as a waterfall; loop back when tests change the problem or reveal a better opportunity.

Sources: NN/g – Design thinking 101, IxDF – Five stages in the design thinking process, IBM – Enterprise Design Thinking

3.3 Jobs-to-be-done vs personas

JTBD frames needs as outcomes users hire products to achieve; strong personas embed behavioral, attitudinal, and goal data — not only demographics. JTBD alone may underweight empathy and segment tradeoffs; combined use is common.

Sources: HBR – Jobs to be done, NN/g – Personas vs JTBD

3.4 User-centered and human-centered design

User-centered design (UCD) keeps user goals, tasks, context, and feedback central throughout product definition, interaction design, and validation. It is useful when turning PM requirements into flows, prototypes, usability tests, and acceptance criteria grounded in real user behavior.

Human-centered design (HCD) is broader: it considers human capabilities, limitations, context, ergonomics, usability, and life-cycle management for interactive systems. Use HCD when a product or service has safety, accessibility, operational, or high-stakes human-system interaction concerns.

Agent takeaway: before proposing a solution, identify the target user, context of use, task, pain, constraint, evidence, and validation method. Mark assumptions when user evidence is missing.

Sources: IxDF – User-Centered Design, ISO 9241-210:2019

3.5 Double Diamond

The Double Diamond models design work as two rounds of divergence and convergence:

  1. Discover — understand the problem by speaking with and observing people affected by it.
  2. Define — synthesize insights into a clearer challenge.
  3. Develop — explore multiple possible answers, often through co-design and outside inspiration.
  4. Deliver — test solutions at small scale, reject weak options, and improve promising ones.

Use it when a team is jumping too quickly to features or when stakeholders disagree about the problem. It is not a rigid instruction manual; teams may loop back as evidence changes.

Sources: Design Council – The Double Diamond

3.6 Service design and service blueprinting

Service design plans and organizes a business's people, props, and processes to improve employee experience directly and customer experience indirectly. Use it when the product experience depends on support, operations, policy, fulfillment, sales, onboarding, or other backstage work.

Service blueprints map one journey across customer actions, frontstage actions, backstage actions, support processes, evidence, and lines of interaction/visibility/internal interaction. They expose dependencies and weak links that a screen-level UX flow can miss.

PM use cases: omnichannel journeys, onboarding/support flows, AI agent handoffs, internal tools, fulfillment processes, and products where customer experience breaks because of organizational seams.

Sources: NN/g – Service Design 101, NN/g – Service Blueprints

4. Data-rich product: metrics, prioritization, roadmaps

4.1 RICE prioritization

RICE = Reach × Impact × Confidence ÷ Effort (Intercom). Forces explicit reach estimates, impact tiering, confidence percentage, and person-month effort; produces comparable impact per effort scores — still subject to judgment and dependencies.

Sources: Intercom – RICE

4.2 Kano model

Classifies features into Must-be, One-dimensional, Attractive, Indifferent, Reverse quality; attributes drift over time (delighters become basics). Supports survey-driven prioritization and QFD linkage.

Sources: Wikipedia – Kano model

4.3 MoSCoW

Must / Should / Could / Won’t (this time) for timeboxed delivery; pairs with MVP/MMF scoping. Criticisms: politics, ambiguity on “won’t,” weak rationales across items.

Sources: Wikipedia – MoSCoW

4.4 Opportunity solution trees (OST)

Visual link: outcome (business) → opportunities (customer needs) → solutions → assumption tests. Operates in continuous discovery with product trio. Prerequisites: customer interviews, clear outcome, value-prop theory.

Sources: Product Talk – Opportunity solution trees

4.5 North Star metric & “three games”

North Star = one leading metric expressing customer value and strategy (Amplitude). Avoid vanity metrics (e.g. raw DAU) if they don’t reflect value. Categorize product “game”: Attention, Transaction, or Productivity to choose coherent North Stars; use input metrics (tree) for alignment.

Sources: Amplitude – North Star

4.6 OKRs

Objectives (qualitative, directional) + 3–5 measurable key results; Grove/Intel heritage; Google popularization. Targets often aspirational ~70% hit rate; avoid BAU-as-OKR and individual OKRs that become task lists.

Sources: Wikipedia – OKR

4.7 Product roadmaps (general)

Roadmaps communicate vision, direction, priorities, progress; audience-specific views for dev, execs, sales, customers; tie items to strategy; update cadence balances accuracy vs overhead. Differentiate roadmap (why/what problems) from delivery plans (how/when features).

Sources: Atlassian – Product roadmap, ProductPlan – What is a roadmap

5. AI / ML product management

5.1 Rules of ML: product judgment before models

Google’s guidance: most wins are engineering and features, not exotic algorithms. Don’t ship ML until simple heuristics are insufficient; keep pipelines solid, add commonsense features, pick a reasonable objective, validate end-to-end. Terminology: pipeline, objective, metric, model, labels, skew.

Sources: Google – Rules of ML

5.2 NIST AI RMF (governance lens)

Voluntary AI RMF for trustworthy AI: functions Govern, Map, Measure, Manage; trustworthiness includes validity/reliability, safety, security/resilience, accountability/transparency, explainability, privacy, fairness/bias. Use for risk registers and cross-functional alignment.

Sources: NIST – AI RMF

5.3 OWASP Top 10 for LLM applications

High-risk classes for LLM products (versions evolve): prompt injection, insecure output handling, training/poisoning, denial of service, supply chain, sensitive disclosure, plugins/tools, excessive agency, overreliance, model theft (2023/24 list on project page). GenAI hub hosts updated Top 10 material (e.g., 2025 taxonomy).

Sources: OWASP LLM Top 10 project, OWASP GenAI – LLM Top 10

5.4 EU AI Act (regulatory pointer)

EU regulation 2024/1689 — risk-based obligations for AI in market. PMs need awareness of prohibited/high-risk categories, documentation, and timeline; official text via EUR-Lex and reputable summaries.

Sources: EU AI Act hub

5.5 Regulated healthcare / medtech design

This section is not legal or regulatory advice. It is a PM/design framing layer for products that may be medical devices, SaMD, AI/ML-enabled medical software, digital health tools, in vitro diagnostics, or other regulated healthcare products. Verify classification, pathway, claims, and evidence requirements with qualified regulatory, quality, clinical, legal, and compliance experts.

When to switch into regulated-product mode: medtech, medical device, regulated product, healthcare, digital health, SaMD, software as a medical device, AI medical device, clinical, patient safety, FDA, 510(k), De Novo, PMA, MDR, IVDR, CE mark, notified body, ISO 13485, ISO 14971, IEC 62366, human factors, usability engineering, design controls, risk management, QMS, or post-market surveillance.

PM framing questions:

  1. What is the intended use and intended medical purpose?
  2. Who are the intended users, patients, and affected stakeholders?
  3. What are the use environments and reasonably foreseeable misuse/use errors?
  4. What claims might the product make, and in which geographies?
  5. Is software standalone SaMD, software in a device, or non-device software?
  6. What hazards, hazardous situations, risk controls, and residual-risk assumptions are known?
  7. What verification, validation, usability, clinical, QMS, and post-market evidence may be needed?

Design implications: regulated product work should preserve traceability from user needs and intended use through design inputs, outputs, verification, validation, risk controls, usability evidence, and post-market monitoring. Human factors/usability work is safety work, not UX polish.

Sources: FDA – Human Factors and Usability Engineering, FDA – SaMD, FDA – AI in SaMD, European Commission – MDR/IVDR, ISO 13485, ISO 14971, IEC 62366-1, IMDRF – SaMD definitions

6. Ideation & strategy vocabulary (workspace capture)

This section is Victoria + assistant session notes, not third-party synthesis. For vetted links, add to research/SOURCE_INDEX.md before treating claims as externally sourced.

6.1 Illustrative product direction (hypothetical, 2026-03-20)

One concrete shape worth prototyping mentally: a decision log with scheduled, low-noise review — users record what they decided, why, and what would change their mind; the product nudges on a cadence they control and surfaces when reality diverges (prices, deadlines, assumptions) rather than pushing endless capture.

  • Core loop: log → time passes → compare to reality → adjust.
  • Why it’s interesting: many tools optimize ingestion; fewer help revisit with discipline without shame or notification spam. Pattern applies across investing, hiring, health tradeoffs, and product bets.
  • Form factor: boring tech; PWA if web-first; mobile-first if notifications/widgets are the habit anchor.
  • “Moat” honesty: often trust + calm UX + retention, not a secret algorithm — viable if a niche is owned.

6.2 Defensibility (strategy / competition)

Defensibility = how hard it is for someone else to copy what you shipped and take your users or margin after you’ve proven the idea works. It is not the same as “clean code,” a patent on everything, or (in security) a defensible system / reduced attack surface — use security posture for that meaning.

Common sources of defensibility (often combined):

Source Plain language
Distribution You’re already where buyers/users are (community, SEO, partnerships, brand, sales motion).
Data / network Product improves or sticks with usage — often overstated unless data is exclusive and compounding.
Workflow lock-in Deep integration into how people work; switching cost is real.
Trust, compliance, reliability Especially in regulated or high-stakes domains.
Economies of scale Unit economics or quality a clone can’t match without matching volume.

PM honesty for small products: many are defensible mainly through brand + distribution + retention in a focused niche — that can be enough.

6.3 Lenses when choosing what to build (answers personal)

Useful forcing questions (not mutually exclusive):

  1. Time to first user — how fast a credible slice reaches someone who cares.
  2. Defensibility — what remains yours if a well-funded team ships the same headline tomorrow (§6.2).
  3. Personal itch — whether you’ll sustain energy through implementation and maintenance.

Victoria (2026-03-20): questions resonated; prioritization across these lenses still TBD.

7. Backlog management (hygiene, shape, public vs private)

Why this section: Product backlogs fail when they are unordered junk drawers. Industry practice emphasizes ordering, refinement, and right-sized items near the top — without pretending the far future is fully specified.

7.1 Themes from standard practice

  • Ordered backlog — The product backlog is a single ordered list (Scrum Guide). “Priority” is expressed by position and explicit rank fields (e.g. P0–P3) where useful.
  • DEEP — Often summarized as detailed appropriately, emergent, estimated, prioritised (Roman Pichler and others). Near-term items gain detail through refinement; distant items stay coarse until they surface.
  • Refinement loop — Regularly clarify scope, split large items, and prepare upcoming work so planning is cheap. Collaboration between product and delivery reduces late surprises.
  • Stories and INVEST — Small, valuable backlog items benefit from INVEST-style quality (independent, negotiable, valuable, estimable, small, testable) and splitting when one card hides multiple goals or too much risk.
  • Discovery vs delivery — Some teams separate opportunity / discovery work from committed build items so they validate problems before over-investing (see SVPG “opportunity backlog” framing in the reading list below).

Curated reading list (13+ URLs): BACKLOG_BEST_PRACTICES.md — Scrum Guide, refinement, Pichler, SVPG, INVEST, story splitting. Share that file with anyone; it contains no private backlog rows.

7.2 A concrete layering pattern (abstract)

Many knowledge-work teams (including markdown-first Cursor workspaces) use three visible levels above a single ordered backlog:

  1. Purpose — Why a strand of work exists (strategic outcome / north-star bucket). Stable keys (e.g. PU-01) help search and reporting.
  2. Epic — Theme under exactly one Purpose; every backlog item rolls up through one Epic.
  3. Story — One line in a prioritized table (headline + priority + status) plus optional long-form description elsewhere; optional per-item files for history, assignee, or paste-friendly detail.

Typical rules of thumb: each story needs at least a title and epic (which implies purpose via an epic registry). Description is encouraged for refinement but can stay optional in the slim index.

7.3 Private implementation (not in this public repository)

The author’s actual prioritized list, inbox, ticket files, purpose/epic registries, and automation live in a private monorepo (where_cursor_feels_home). They are intentionally not published in vcrosby22/ai-assisted-work. If you clone only this public repo, use §7.1–7.2 and BACKLOG_BEST_PRACTICES.md; adopt your own tool or private files for the backlog itself.

8. Cross-domain cheat sheet

Problem Consider
Stakeholders want date-certain features Separate roadmap (outcomes) from release plan; use confidence labels (NN/g).
Backlog fights RICE or MoSCoW + Kano for delight vs table stakes.
Strategy drift North Star + OKRs + OST for discovery traceability.
Hardware + software SKU Phase-gate where regulated + dual-track inside phases for firmware/app.
“We need AI” Rules of ML gate: heuristics first; NIST/OWASP for risk & security.

9. AI PM agent operating layer

Goal: make product-management capability available to any agent through versioned repo context, not chat memory.

9.1 Context engineering stance

For PM work, context engineering means deciding what product context an agent receives, when, and in what structure. The agent should not load the entire PM knowledge base by default. It should start with a minimal context packet: product, target user, business objective, product outcome, evidence, constraints, decision needed, and audience.

Sources: IdeaPlan – Context Engineering for Product Managers, Martin Fowler / Thoughtworks – Context Engineering for Coding Agents

9.2 Workflow before autonomy

Most PM tasks are better served by explicit workflows than by unconstrained autonomy. Strategy briefs, discovery plans, prioritization scorecards, roadmaps, PRDs, and shaped pitches have predictable steps and review criteria. Use autonomous agent behavior only for open-ended research or multi-step synthesis where the agent can gather ground truth and pause at checkpoints.

Sources: Anthropic – Building Effective Agents

9.3 Capability surface

The first AI PM agent capability layer in this repo includes:

9.4 Agent behavior expectations

An AI PM agent should:

  1. Translate feature requests into customer problems and product outcomes.
  2. Preserve traceability from outcome to opportunity, solution, test, requirement, and release signal.
  3. Separate roadmap, PRD, backlog, and release-plan concepts.
  4. Mark assumptions and evidence quality plainly.
  5. Use prioritization frameworks as decision support, not as automatic decisions.
  6. Keep context small and source-aware.

10. Gaps for future hydration

  • Amazon Working Backwards / PR-FAQ (primary AWS sources)
  • Data mesh / data product paradigms (internal data platforms)
  • Outcome-based roadmap (Product Talk) deep links beyond OST
  • Accessibility-specific PM (WCAG-driven prioritization)
  • Industry regs FDA SaMD, automotive SPICE (where relevant)

Record new URLs in research/SOURCE_INDEX.md before merging claims into this file.