Junior Product Manager

Anchor on the user problem and business goal, not the stakeholder's seniority. Use data to make tradeoffs visible. Escalate only when alignment is impossible at your level — escalation without evidence is a trust risk.

Specific, testable conditions that define when a user story is 'done.' Written before development starts. Good ACs remove ambiguity: 'User can log in with Google OAuth and is redirected to the dashboard within 2 seconds.'

Discovery (finding the right problem), delivery (shipping solutions), and strategy (deciding what matters over time). Most junior roles weight delivery; senior roles weight discovery and strategy.

Not 'no because I disagree' but 'not now because it doesn't serve our current goal — here's what we're focused on instead.' Good PMs kill requests with evidence, not authority. A backlog exists to park, not refuse.

The 'why' and 'what' of a product — the problem to solve and the outcome to achieve. Not the 'how' (engineering) or 'when' (project management). A PM owns the roadmap and the decision to ship or not ship.

Every item you build means something else doesn't get built. The real cost of a feature isn't the engineering time — it's the value of the best alternative you didn't pursue.

Confidence that a real, recurring problem exists for enough users that solving it is worthwhile. It precedes product-market fit. Building without problem-solution fit is the most common cause of wasted engineering effort.

The willingness to cut good ideas to protect great ones. Most teams have more ideas than capacity. PMs who can't say no end up with bloated roadmaps, missed deadlines, and distracted teams. Focus compounds.

Gradual expansion of a feature's requirements mid-build, often driven by stakeholder requests. Prevented by writing clear acceptance criteria upfront, linking scope to the original user problem, and saying no with evidence.

The amount of work a team completes per sprint, measured in story points. It's a planning tool, not a productivity metric. PMs shouldn't optimise for velocity — it can be gamed. Focus on outcomes delivered, not points burned.

Daily Active Users ÷ Monthly Active Users. Measures engagement frequency — how 'sticky' a product is. A ratio of 0.5 means users engage ~15 days/month. High for daily-use products (>0.5), lower for weekly/monthly tools.

A shared team agreement on what conditions must be met before a story is considered complete. Usually includes: code reviewed, tested, deployed to staging, meets ACs, and documented. Prevents 'it's done in dev but not tested' confusion.

A time-boxed research effort (usually 1–2 sprints) to reduce uncertainty before committing to build. Used when the problem or solution is unclear. Output is a decision, not a deliverable.

The progress a user is trying to make in a specific situation. Framed as: 'When [situation], I want to [motivation], so I can [outcome].' Shifts focus from product features to human context.

Soft launch: release to a subset of users (beta group, single region) to gather feedback before full release. Hard launch: full public release, often with marketing. Soft launches reduce risk; hard launches maximise momentum.

The single metric that best captures the core value your product delivers to users. Aligns the team on what matters. Example: Spotify's NSM is 'time spent listening.' Not a revenue metric — a value metric.

Product Requirements Document. Typically: problem statement, user context, success metrics, scope (in/out), key user flows, open questions, and launch criteria. A PRD aligns teams before build — it's a living document, not a contract.

A sustainable advantage that makes it hard for competitors to replicate your product's value. Types: network effects, switching costs, proprietary data, brand, economies of scale. PMs should know which moat their product relies on.

A code toggle that enables/disables a feature for specific users without deploying new code. Used for: phased rollouts, A/B tests, beta access, and kill switches. Reduces launch risk by decoupling deployment from release.

Offering a free tier to drive adoption, with paid upgrades for advanced features. Works when: free tier delivers real value, upgrade triggers are clear, and the cost of serving free users is low. Fails when free users never convert.

A funnel maps user progression through key steps: Awareness → Acquisition → Activation → Retention → Referral → Revenue (AARRR). Drop-off at each stage is a signal. PMs identify where the biggest leaks are.

A plan for how you'll reach your target customer and deliver your value proposition. Covers: target segment, positioning, pricing, channel, and launch timing. PMs own the product side; marketing owns the message.

The smallest thing you can build to test a core assumption with real users. Often misused as an excuse to ship a half-baked product. A true MVP is a learning tool, not a product version — it answers a specific question.

For [target customer], [product] is the [category] that [key benefit] because [reason to believe]. Aligns messaging internally before it reaches customers. Distinguishes you from alternatives in your customer's mind.

Vision: the future state you're trying to create (inspirational, long-term). Strategy: how you'll get there — the choices about what to prioritise and why. Without strategy, a vision is just aspiration.

A fixed-length development cycle (usually 2 weeks). Key ceremonies: sprint planning, daily standup, sprint review, and retrospective. PMs are most involved in planning (scoping) and review (evaluating output against goals).

Activation is the moment a user first experiences core product value. Users who don't activate rarely return. Improving activation often has more impact than acquiring more users at the top of the funnel.

Responsible, Accountable, Consulted, Informed. A framework for clarifying decision-making roles. Prevents confusion about who makes decisions vs who provides input. PMs are often 'Accountable' for product decisions.

Churn = % of users who stop using the product in a given period. 'Good' depends on business model — SaaS B2B might tolerate 1–2% monthly; consumer apps often see 5–8%. High churn = retention problem, often traced to weak activation.

Grouping users by when they joined (or another shared attribute) and tracking their behaviour over time. Reveals whether product changes improved retention for newer cohorts vs older ones. Essential for understanding retention trends.

Revenue from existing customers at end of period ÷ revenue at start, including expansions and churn. NRR >100% means existing customers grow revenue even without new ones. The strongest signal of a healthy B2B product.

A go-to-market strategy where the product itself drives acquisition, activation, and expansion — rather than sales or marketing. Examples: Slack, Figma, Dropbox. The product is the sales motion.

When a product satisfies strong market demand. Signs: organic growth, users are 'very disappointed' if product disappeared (>40% threshold), low churn, high NPS. Sean Ellis survey is a common proxy test.

The practice of identifying people with influence over or interest in your product, understanding their goals, and maintaining alignment. PMs who ignore stakeholders lose roadmap control; those who over-accommodate lose focus.

Useful shorthand for ownership mindset, but misleading: PMs have no hiring/firing authority, no budget control, and must persuade rather than direct. Overusing this framing creates friction with peers.

Impact × Confidence × Ease. Simpler than RICE — omits Reach. Better for early-stage teams with limited data. RICE is better when you have audience size data and want to weight for scale.

Influence without authority. A PM cannot direct engineers — they must earn alignment through clear problem framing, strong evidence, and shared goals. Treating eng as 'resources to execute' is a fast path to losing trust.

Reach × Impact × Confidence ÷ Effort. A prioritisation framework that scores features numerically. Useful for making tradeoffs transparent, but only as good as the estimates feeding it.

Consulted: two-way communication — their input shapes the decision before it's made. Informed: one-way — they're told after the decision. Confusing these causes frustration (over-informing wastes time; under-consulting damages trust).

B2B: longer sales cycles, multiple stakeholders, contract-based, customisation pressure. B2C: rapid iteration, emotional drivers, scale, viral loops. B2B PMs often manage enterprise relationships; B2C PMs focus on engagement metrics.

Backlog: tactical list of tasks and stories ready for development. Roadmap: strategic view of themes, goals, and timelines over quarters. Roadmaps communicate direction to stakeholders; backlogs drive sprint-level execution.

Bug: behaviour that breaks a defined spec. Feature request: new capability not currently scoped. Tech debt: existing code that works but is hard to maintain or extend. Each requires a different prioritisation lens.

Leading: predicts future performance (e.g. trial signups). Lagging: confirms past performance (e.g. annual revenue). PMs should monitor both — leading indicators let you course-correct before lagging metrics confirm failure.

A market is all potential buyers of a category (e.g. project management software). A segment is a defined subset with shared characteristics and needs (e.g. remote-first teams <50 people). Good strategy starts with a clear target segment.

A want is the stated solution ('I want a faster horse'). A need is the underlying goal ('I need to get somewhere quickly'). Good discovery uncovers needs, not wants.

MVP (Minimum Viable Product): built to learn. MMP (Minimum Marketable Product): built to sell — the smallest thing customers would actually pay for or adopt. MVPs are internal experiments; MMPs are public launches.

Output is what you ship (a feature). Outcome is the change in user behaviour or metric that results. Good PMs measure outcomes, not outputs. Shipping ≠ succeeding.

Qualitative (interviews, observations) tells you *why* users behave a certain way. Quantitative (analytics, surveys) tells you *what* they do and *how often*. Both are needed — quant finds the problem, qual explains it.

'As a [user type], I want to [action], so that [benefit].' Keeps requirements grounded in user goals rather than feature descriptions. The 'so that' clause is the most important and most often omitted part.

Leading questions ('Do you find X frustrating?'), hypotheticals ('Would you use Y?'), and yes/no questions. Good questions are open-ended, past-tense, and about real behaviour: 'Tell me about the last time you…'

Scope of ambiguity. A junior PM executes well-defined problems. A senior PM defines which problems matter. The gap is judgment about prioritisation, not just execution quality.

Did we hit success metrics? What surprised us? What would we do differently? What follow-on work is needed? Held 2–4 weeks post-launch. Prevents teams from moving straight to the next feature without learning from the last one.