Junior to Mid Product Manager

Treat it as a signal, not a directive. Aggregate requests to find patterns (is this one customer or many?), test against your strategy, and evaluate ROI. A single enterprise deal rarely justifies reshaping a roadmap unless it's a strategic anchor account.

Use structured assumptions: estimate reach, impact, and confidence based on analogous data, industry benchmarks, or expert input. Document your assumptions explicitly. Make the lowest-confidence assumption your first experiment. Never pretend certainty you don't have.

On: metric outcomes (did the product improve the number it was supposed to?), cross-functional collaboration quality, quality of discovery (are we solving the right problems?), and stakeholder trust. Not on features shipped or sprints completed.

Separate the what from the how. PMs own what to build and why; tech leads own how. If disagreement is about scope or priority, PM leads. If it's about implementation approach, defer to the tech lead unless there's a user or business impact at stake.

Don't defend the roadmap — defend the reasoning. Explain the problem you're solving, the metric you're targeting, and the opportunity cost of the alternative. Invite them to challenge the logic, not the list. Seniority ≠ better prioritisation judgment.

Lead with outcomes, not features. Open with: here's the goal, here's where we are, here's what we're prioritising next and why. Bring data. Anticipate objections. Close with a specific ask. Avoid presenting a list and asking 'any questions?'

Setting clear goals others buy into, resolving cross-team blockers before they escalate, and building a reputation for follow-through. Mid-level PMs earn influence through consistency — not title or seniority.

Junior PMs own delivery of features. Mid-level PMs own the metric the feature was meant to move. If you shipped on time but the metric didn't move, a mid-level PM investigates why and drives the follow-on work.

Junior PMs report status when asked. Mid-level PMs anticipate what stakeholders need to know and communicate it before they ask — especially bad news. Stakeholders shouldn't learn about delays or pivots from anyone other than the PM.

The quality of your core outputs: sharp problem framing, well-structured PRDs, clear success metrics, and good judgment under uncertainty. Craft is visible in the details — precise language, fewer assumptions, stronger tradeoff reasoning. It's how mid-level PMs signal readiness for senior roles.

Listing every assumption your solution depends on, then ranking by importance and certainty. Highest importance + lowest certainty = test first. Used before building to identify which bets are most likely to invalidate the whole approach.

Deliberately varying the scope of investments: small bets (low effort, validate fast), medium bets (2–4 weeks, more confidence), big bets (quarters, high conviction). Mid-level PMs manage a portfolio of bet sizes — not a queue of equally-sized features.

The value lost by not delivering something sooner. Reframes prioritisation from 'what's most valuable' to 'what's most valuable *right now*.' A feature worth $100k/month delayed by 3 months costs $300k — that's the real cost of deprioritisation.

Proactively keeping your manager informed, surfacing problems before they escalate, and giving your manager what they need to advocate for your team. Mid-level PMs who don't manage up find their roadmap decisions overridden because leadership lacks context.

Whether your chosen metric can actually detect the change you're trying to make. A metric that moves slowly or has high variance requires huge sample sizes to reach significance. Choosing the right metric for an experiment is as important as designing the experiment.

Using storytelling — user context, data, and consequence — to move people toward a decision. Mid-level PMs are expected to frame problems in a way that makes the right action obvious, not just present options and wait for a verdict.

Promises made to stakeholders — explicitly or implicitly — that haven't been delivered. Accumulates when PMs say 'yes, eventually' without anchoring to a condition or goal. Clears it by setting explicit expectations and revisiting commitments quarterly.

Accumulated shortcuts in code that make future changes slower and riskier. PMs should budget 15–20% of sprint capacity for debt reduction, treat it as an investment in delivery speed, and understand which debt is blocking roadmap goals.

A set of rules for asking questions that even a biased respondent (like your mum) can't just validate to be nice. Core rule: ask about their life, not your idea. 'Do you think you'd use this?' is a bad question. 'Tell me how you handle X today' is a good one.

The time between a user signing up and experiencing the core value of the product. Shortening TTV improves activation rates. A long TTV means users churn before they understand why they should stay. Mid-level PMs treat TTV as a design constraint.

A 2x2 grid that scores ideas on value (high/low) and effort (high/low). Quick items are 'quick wins'; high value + high effort are 'big bets'. Falls short when: value is poorly estimated, effort ignores maintenance cost, or strategic context is ignored.

Start with the desired customer outcome and press release, then figure out what you need to build to make it true. Popularised by Amazon. Forces you to articulate value before scoping solution. Prevents building in search of a problem.

The total revenue a customer generates over their relationship with the product. Used to justify acquisition cost, prioritise customer segments, and evaluate retention investments. LTV:CAC ratio >3:1 is often cited as a healthy benchmark for SaaS.

A short written document (1–2 pages) that states: the decision needed, context, options considered, recommendation, and tradeoffs. Used for high-stakes or cross-functional decisions. Creates accountability and a paper trail. Mid-level PMs write them; juniors often wait to be asked.

A thematic roadmap that groups work by confidence level rather than dates. Better when: timelines are uncertain, strategy is still forming, or stakeholders keep re-prioritising. Reduces false precision; keeps focus on outcomes over deadlines.

Thinking of your roadmap as a set of investments with different risk/return profiles — not a list of tasks. Balance exploratory bets (learning) with execution (proven value). Mid-level PMs are expected to manage this balance, not just execute one type.

Users who get disproportionate value from a product — high engagement, low churn, high referral. They show you what's possible. But over-indexing on power users leads to features that don't generalise. Balance: learn from power users, but design for the majority.

Type I (false positive): concluding a change works when it doesn't. Type II (false negative): concluding a change doesn't work when it does. PMs should understand the cost of each in context — shipping a broken feature vs missing a real improvement.

The system that moves data from product events into analytics tools. If the pipeline is broken or incomplete, your metrics are wrong. PMs should validate that key user actions are tracked before relying on dashboards to make decisions.

A metric you monitor to ensure an experiment doesn't cause unintended harm — even if the primary metric improves. Example: testing a new onboarding flow might improve activation (primary) but increase support tickets (guardrail). Always define guardrails before starting.

A short, opinionated statement that guides tradeoffs when data or consensus is absent. Example: 'We optimise for the expert user, not the occasional visitor.' Good principles make recurring decisions faster and more consistent.

A regular (often monthly or quarterly) sync where product direction, metrics, and decisions are reviewed by senior leadership. Mid-level PMs should bring: current metric performance vs target, key decisions made and why, risks on the horizon, and what they need.

A written articulation of: the problem space you're focused on, why now, who you're serving, what you're not doing, and how success is measured over 12–18 months. At mid-level, PMs are expected to write and defend this — not receive it from above.

A chart of the % of users still active N days/weeks after signup. A curve that flattens above 0% indicates a retained user base. A curve that trends toward 0% means the product has no long-term value for most users. Shape matters more than any single data point.

A decision to invest in an uncertain direction based on a thesis, not proof. You defend it with: a clear problem statement, evidence of user pain, market sizing, and what you'll learn first. The goal is making the uncertainty explicit, not eliminating it.

A commitment to performance standards — uptime, response time, error rates. Matters when: building enterprise features, integrating with third parties, or launching to regulated industries. PMs need to know what SLAs the product promises and whether engineering can meet them.

A visual framework by Teresa Torres linking: desired outcome → opportunities (user needs/pain points) → solutions → experiments. Prevents jumping from problem to solution. Forces PMs to explore multiple opportunities before committing to a direction.

Continuous discovery: regular, lightweight user touchpoints (weekly interviews, session recordings, feedback loops) embedded in normal workflow. Project-based: big research efforts done once per quarter or before a launch. Mid-level PMs build continuous habits, not one-off campaigns.

Revenue growth from existing customers — through upsells, cross-sells, or seat expansion. Cheaper to earn than new customer revenue. NRR >100% means existing customers fund growth without new acquisition. A product that earns expansion revenue has compounding economics.

The likelihood that observed results aren't due to random chance. Usually set at p<0.05 (95% confidence). Running too short or ending early when you see a positive result is 'peeking' — it inflates false positive rates and leads to bad decisions.

Escalating decisions to your manager that you should be making yourself. Signs: asking for approval on low-stakes calls, framing problems without a recommended solution, cc'ing managers on every stakeholder thread. Fix: bring a recommendation, not just a problem.

The specific action or experience that correlates with long-term retention. Found by comparing behaviours of retained vs churned users in cohort data. Example: Twitter's aha moment was following 30 people. Design onboarding to reach it faster.

Frame the problem and define success criteria at the start. Stay available for questions during ideation but avoid anchoring the team's thinking. At the end, evaluate outputs against the original problem — not against personal preference.

Situation (what's true), Complication (what's changed or problematic), Question (what needs to be resolved), Answer (your recommendation). Structures communication so executives can absorb the 'so what' quickly without reading every detail.

From 'how do I execute this well?' to 'am I working on the right thing?' Junior PMs optimise within the problem. Mid-level PMs question whether the problem is worth solving at all — and push back when it isn't.

A roadmap is a strategic communication tool — it shows direction and priorities. A plan is a tactical execution tool — it shows tasks, owners, and dates. Roadmaps belong in stakeholder conversations; plans belong in sprint planning.

Feature roadmap: 'We'll build X, Y, Z.' Theme roadmap: 'We'll focus on reducing onboarding friction.' Themes survive pivots; features don't. Mid-level PMs learn to communicate in themes to stakeholders and translate to features for engineers.

Correlation: two metrics move together. Causation: one directly causes the other. Common trap: users who use feature X have higher retention — but maybe high-retention users are simply more likely to discover X. Experiments establish causation; analytics surface correlation.

Persuasion: getting someone to agree with you in a specific moment. Influence: building credibility over time so your judgment is trusted before you speak. Mid-level PMs need both — but influence is the durable one.

Usability testing: can users complete a task with an existing interface? Finds friction in execution. Concept testing: do users want or understand a proposed solution? Validates desirability before building. Mid-level PMs use both — at the right stage.

An API lets two systems exchange data. PMs need to understand: what data is available, what triggers actions, and what limitations exist (rate limits, latency). Enough to spec integrations, evaluate feasibility, and avoid promising what's technically impossible.