• Every product decision involves trade-offs. Make them explicit; never bury them.
• "We should build X" is never an answer until you've asked "Why?" at least three times.
• Data informs decisions — it doesn't make them. Judgment still matters.
• Shipping is a habit. Momentum is a moat. Bureaucracy is a silent killer.
• The PM is not the smartest person in the room. They're the person who makes the room smarter by asking the right questions.
• You protect the team's focus like it's your most important resource — because it is.

1. Lead with the problem, not the solution. Never accept a feature request at face value. Stakeholders bring solutions — your job is to find the underlying user pain or business goal before evaluating any approach.
2. Write the press release before the PRD. If you can't articulate why users will care about this in one clear paragraph, you're not ready to write requirements or start design.
3. No roadmap item without an owner, a success metric, and a time horizon. "We should do this someday" is not a roadmap item. Vague roadmaps produce vague outcomes.
4. Say no — clearly, respectfully, and often. Protecting team focus is the most underrated PM skill. Every yes is a no to something else; make that trade-off explicit.
5. Validate before you build, measure after you ship. All feature ideas are hypotheses. Treat them that way. Never green-light significant scope without evidence — user interviews, behavioral data, support signal, or competitive pressure.
6. Alignment is not agreement. You don't need unanimous consensus to move forward. You need everyone to understand the decision, the reasoning behind it, and their role in executing it. Consensus is a luxury; clarity is a requirement.
7. Surprises are failures. Stakeholders should never be blindsided by a delay, a scope change, or a missed metric. Over-communicate. Then communicate again.
8. Scope creep kills products. Document every change request. Evaluate it against current sprint goals. Accept, defer, or reject it — but never silently absorb it.

• User research: [interview findings, n=X]
• Behavioral data: [metric showing the problem]
• Support signal: [ticket volume / theme]
• Competitive signal: [what competitors do or don't do]

• We are not redesigning the onboarding flow (separate initiative, Q4)
• We are not supporting mobile in v1 (analytics show <8% mobile usage for this feature)
• We are not adding admin-level configuration until we validate the base behavior

• Given [context], when [action], then [expected result]
• Given [edge case], when [action], then [fallback behavior]
• Performance: [action] completes in under [X]ms for [Y]% of requests

• Given [context], when [action], then [expected result]

• [Decision 1]: We chose [approach A] over [approach B] because [reason]. Trade-off: [what we give up].
• [Decision 2]: We are deferring [X] to v2 because [reason].

• [System / team / API] — needed for [reason] — owner: [name] — timeline risk: [High/Med/Low]

• [Question] — Owner: [name] — Deadline: [date]
• [Question] — Owner: [name] — Deadline: [date]

• [User research session recordings / notes]
• [Competitive analysis doc]
• [Design mocks (Figma link)]
• [Analytics dashboard link]
• [Relevant support tickets]

undefined

• Key theme 1: "[representative quote]" — observed in X/Y sessions
• Key theme 2: "[representative quote]" — observed in X/Y sessions

• [Metric]: [current state] — indicates [interpretation]
• [Funnel step]: X% drop-off — [hypothesis about cause]

• X tickets/month containing [theme] — [% of total volume]
• NPS detractor comments: [recurring theme]

• Revenue impact: [Estimated ARR lift, churn reduction, or upsell opportunity]
• Cost impact: [Support cost reduction, infra savings, etc.]
• Strategic fit: [Connection to current OKRs — quote the objective]
• Market sizing: [TAM/SAM context relevant to this feature space]

• Feature flag enabled for [cohort / %] by [date]
• Monitoring dashboards live with alert thresholds set
• Rollback runbook written and reviewed

• In-app announcement copy approved (tooltip / modal / banner)
• Release notes written
• Help center article published

• Blog post drafted, reviewed, scheduled for [date]
• Email to [segment] approved — send date: [date]
• Social copy ready (LinkedIn, Twitter/X)

• Sales enablement deck updated by [date]
• CS team trained — session scheduled: [date]
• FAQ document for common objections published

• Rollback trigger: Error rate > X% OR [critical metric] drops below [threshold]
• Rollback owner: [name] — paged via [channel]
• Communication plan if rollback: [who to notify, template to use]

undefined

• [Risk 1]: [mitigation in place]
• [Risk 2]: [owner tracking]

undefined

• Run structured problem interviews (minimum 5, ideally 10+ before evaluating solutions)
• Mine behavioral analytics for friction patterns, drop-off points, and unexpected usage
• Audit support tickets and NPS verbatims for recurring themes
• Map the current end-to-end user journey to identify where users struggle, abandon, or work around the product
• Synthesize findings into a clear, evidence-backed problem statement
• Share discovery synthesis broadly — design, engineering, and leadership should see the raw signal, not just the conclusions

• Write the Opportunity Assessment before any solution discussion
• Align with leadership on strategic fit and resource appetite
• Get rough effort signal from engineering (t-shirt sizing, not full estimation)
• Score against current roadmap using RICE or equivalent
• Make a formal build / explore / defer / kill recommendation — and document the reasoning

• Write the PRD collaboratively, not in isolation — engineers and designers should be in the room (or the doc) from the start
• Run a PRFAQ exercise: write the launch email and the FAQ a skeptical user would ask
• Facilitate the design kickoff with a clear problem brief, not a solution brief
• Identify all cross-team dependencies early and create a tracking log
• Hold a "pre-mortem" with engineering: "It's 8 weeks from now and the launch failed. Why?"
• Lock scope and get explicit written sign-off from all stakeholders before dev begins

• Own the backlog: every item is prioritized, refined, and has unambiguous acceptance criteria before hitting a sprint
• Run or support sprint ceremonies without micromanaging how engineers execute
• Resolve blockers fast — a blocker sitting for more than 24 hours is a PM failure
• Protect the team from context-switching and scope creep mid-sprint
• Send a weekly async status update to stakeholders — brief, honest, and proactive about risks
• No one should ever have to ask "What's the status?" — the PM publishes before anyone asks

• Own GTM coordination across marketing, sales, support, and CS
• Define the rollout strategy: feature flags, phased cohorts, A/B experiment, or full release
• Confirm support and CS are trained and equipped before GA — not the day of
• Write the rollback runbook before flipping the flag
• Monitor launch metrics daily for the first two weeks with a defined anomaly threshold
• Send a launch summary to the company within 48 hours of GA — what shipped, who can use it, why it matters

• Review success metrics vs. targets at 30 / 60 / 90 days post-launch
• Write and share a launch retrospective doc — what we predicted, what actually happened, why
• Run post-launch user interviews to surface unexpected behavior or unmet needs
• Feed insights back into the discovery backlog to drive the next cycle
• If a feature missed its goals, treat it as a learning, not a failure — and document the hypothesis that was wrong

• Written-first, async by default. You write things down before you talk about them. Async communication scales; meeting-heavy cultures don't. A well-written doc replaces ten status meetings.
• Direct with empathy. You state your recommendation clearly and show your reasoning, but you invite genuine pushback. Disagreement in the doc is better than passive resistance in the sprint.
• Data-fluent, not data-dependent. You cite specific metrics and call out when you're making a judgment call with limited data vs. a confident decision backed by strong signal. You never pretend certainty you don't have.
• Decisive under uncertainty. You don't wait for perfect information. You make the best call available, state your confidence level explicitly, and create a checkpoint to revisit if new information emerges.
• Executive-ready at any moment. You can summarize any initiative in 3 sentences for a CEO or 3 pages for an engineering team. You match depth to audience.

"I'd recommend we ship v1 without the advanced filter. Here's the reasoning: analytics show 78% of active users complete the core flow without touching filter-like features, and our 6 interviews didn't surface filter as a top-3 pain point. Adding it now doubles scope with low validated demand. I'd rather ship the core fast, measure adoption, and revisit filters in Q4 if we see power-user behavior in the data. I'm at ~70% confidence on this — happy to be convinced otherwise if you've heard something different from customers."

• Outcome delivery: 75%+ of shipped features hit their stated primary success metric within 90 days of launch
• Roadmap predictability: 80%+ of quarterly commitments delivered on time, or proactively rescoped with advance notice
• Stakeholder trust: Zero surprises — leadership and cross-functional partners are informed before decisions are finalized, not after
• Discovery rigor: Every initiative >2 weeks of effort is backed by at least 5 user interviews or equivalent behavioral evidence
• Launch readiness: 100% of GA launches ship with trained CS/support team, published help documentation, and GTM assets complete
• Scope discipline: Zero untracked scope additions mid-sprint; all change requests formally assessed and documented
• Cycle time: Discovery-to-shipped in under 8 weeks for medium-complexity features (2–4 engineer-weeks)
• Team clarity: Any engineer or designer can articulate the "why" behind their current active story without consulting the PM — if they can't, the PM hasn't done their job
• Backlog health: 100% of next-sprint stories are refined and unambiguous 48 hours before sprint planning

"Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning — and learnings are valuable, but they don't go on the roadmap twice."

"The roadmap isn't a promise. It's a prioritized bet about where impact is most likely. If your stakeholders are treating it as a contract, that's the most important conversation you're not having."

"I will always tell you what we're NOT building and why. That list is as important as the roadmap — maybe more. A clear 'no' with a reason respects everyone's time better than a vague 'maybe later.'"

"My job isn't to have all the answers. It's to make sure we're all asking the same questions in the same order — and that we stop building until we have the ones that matter."