It helps to group PM work into three broad buckets. These are not sequential phases — you move between them constantly — but they represent fundamentally different modes of thinking.

“Discovery is used to describe the work we're doing to decide what to build. Everything in our backlog is a bet. Discovery is helping us make a better bet.”

— Teresa Torres, Continuous Discovery Habits

Most junior PMs over-invest in delivery because it is the most visible and immediately rewarded. It is easy to point to a shipped feature. It is harder to explain why you spent three weeks in customer interviews before writing a single requirement. But the best PMs know that the discovery and prioritization stages determine whether delivery even matters.

The single most dangerous habit in product management is jumping to solutions before you have earned the right to have opinions about them. Someone mentions a user complaint and the room immediately starts debating implementation approaches. The problem has not been clearly defined. The scope has not been explored. But the whiteboard is already full of wireframes.

Discovery is the discipline of slowing down that process in a way that speeds up everything downstream. When you do discovery well, you ship less and learn more. You spend less time building things nobody needed.

Continuous discovery, not a one-time event

Teresa Torres introduced the concept of continuous discovery — the idea that talking to customers should not be a quarterly exercise, but a weekly habit embedded into how your team operates. The goal is to maintain a living understanding of your users rather than a snapshot that ages quickly.

“You don't need to stop what you're doing and do a big research effort. You need a lightweight recurring system. Research is critical — but most teams can't afford to pause for it. You can afford a weekly habit.”

— Teresa Torres, Continuous Discovery Habits

The opportunity solution tree

Torres also developed the Opportunity Solution Tree framework — a visual map that connects your desired outcome at the top, to the opportunities (user needs, pain points, jobs-to-be-done) that could move that outcome, and then to the possible solutions for each opportunity. It forces clarity about what you are trying to achieve before you explore how to achieve it.

For a junior PM on a digital quoting flow, an opportunity solution tree might start with “increase online quoting completion rate” — then branch into: “users feel uncertain about what information is required,” “the form feels too long,” or “users lose progress when they navigate away.” Each is a distinct problem with different solutions. The tree keeps you from conflating them.

If discovery is about finding the right problems, prioritization is about choosing which right problem to work on first. It sounds simple. It is not.

“Prioritization is the number one key tool of a product manager. Given the same amount of skill, intelligence, and resources, a product manager with a great innate ability to prioritize is going to generate 5X the impact of someone without that skill.”

— Ian McAllister, former product lead at Amazon, Uber, and Airbnb

McAllister's definition of prioritization extends well beyond deciding which feature to build next. It includes: which themes belong on your roadmap; which projects within a theme should come first; how much of a project is worth building; which stakeholder requests deserve a response versus a polite no; and how you allocate your own time.

Prioritization frameworks worth knowing

These frameworks are tools, not answers. The real skill is knowing what information you need to use a framework honestly — and resisting the temptation to game the inputs so your preferred project wins. If you find yourself adjusting the numbers until the output matches your intuition, the framework is helping you post-rationalize, not think.

Prioritization as a communication act

Every prioritization decision needs to be explainable to engineers, designers, stakeholders, and leadership — often with different framings for each audience. A good prioritization process produces not just a ranked list, but a clear rationale for why certain things are in and others are out, grounded in data and user insight.

Gibson Biddle's GEM framework — Growth, Engagement, and Monetization — gives teams a shared language for evaluating competing priorities. When every project can be mapped to one of those three lenses, alignment becomes easier and debates become more productive.

Strategy is the word that makes junior PMs nervous. It sounds like something that happens in board meetings, not sprint reviews. But strategy, in practice, is simply the logical plan that connects your team's daily choices to the outcomes the business is trying to achieve. If you cannot articulate that connection, you are working without a compass.

Ravi Mehta developed the product strategy stackto make this concrete — separating mission (the aspirational “why”), strategy (the rigorous “how”), tactics (the specific bets), and metrics (the signals of progress). These are often conflated: teams will describe a tactic as if it were a strategy, or set a metric without a real strategy behind it.

“Difficulty prioritizing almost always traces back to not having a deep enough understanding of what the strategy is. The framework that should inform prioritization hasn't been clearly defined.”

— Ravi Mehta, Reforge product leadership programs

For a junior PM, you are rarely responsible for setting strategy at the company level. But you are responsible for understanding it, articulating it to your team, and ensuring that your own decisions are consistent with it. One of the fastest ways to build credibility early in your career is to be the person who can clearly explain why a roadmap item exists in terms of the strategy it serves.

Gibson Biddle's DHM model

One of the most elegant strategy frameworks from the Netflix era: great products Delight customers in Hard-to-copy, Margin-enhancing ways. The three parts work together. Delighting customers is necessary but not sufficient — if your delight is easy to replicate, competitors will copy it. If it is not margin-enhancing, you cannot sustain it. The best product decisions score well on all three dimensions.

A PM without a metric is guessing. Without a clear signal of success, you have no way to know whether your work is actually working. Metrics force precision, surface disagreement, create accountability, and connect your daily work to outcomes the business cares about.

The north star metric

The north star metric — a single number that best captures the value your product creates for users — has become foundational in modern product thinking. Itamar Gilad (Gmail, YouTube) makes an important distinction: a north star measures value delivered to the market, not value captured by the business. WhatsApp measured messages sent — not revenue. Spotify measures time spent listening. If you consistently deliver real user value, business value follows. Optimize for business metrics directly and you often erode user value in the process.

OKRs: a tool, not a religion

OKRs (Objectives and Key Results) are the most widely adopted goal-setting framework in product companies, and also among the most widely misused. At their best, OKRs create a shared understanding of what success looks like and align team decisions toward company-level outcomes. At their worst, they become a bureaucratic ritual disconnected from actual product decisions.

Matt LeMay offers a useful reframe: the goal is not to “do OKRs” — it is to align your work to business-critical outcomes. Your job is to ensure that what your team builds can be traced back to something the business genuinely needs to achieve. When that connection is murky, prioritization becomes political rather than principled.

Here is a fact that surprises many people new to product management: a PM has almost no formal authority. You cannot order an engineer to build something. You cannot instruct a data scientist to redefine their model. Almost everything you need to achieve requires the voluntary cooperation of people who do not report to you.

This is not a flaw in the role — it is the point. The skill of influencing without authority is what separates PMs who get things built from those who just attend a lot of meetings.

Why influence breaks down

Jessica Fain (Webflow, ex-Slack) identifies a common failure mode: PMs who center themselves rather than their stakeholders. Instead of understanding where an executive or engineer is coming from — their incentives, their constraints, what success looks like for them — a PM tries to push their own perspective. The result is resistance, even when the idea is good.

“If you don't have buy-in and the backing of your key stakeholders, of your executives, you can't build great products. Great ideas only become great products when the right people get behind them.”

— Jessica Fain, Webflow (ex-Slack)

The antidote is understanding. Before trying to persuade someone, invest time in understanding their perspective. What do they care about? What are they measured on? What decisions are they being asked to make this quarter? When you understand those things, you can frame your proposals in terms that resonate — and you will often discover that your interests are more aligned than the conflict made them appear.

Practical influence moves for junior PMs

At the beginning of your career, your influence currency is primarily knowledge— being the most informed person in the room about the customer, the data, and the problem space. Ian McAllister's early success at Amazon traced back to one thing: he was deeply focused on a specific metric of business success, and he consistently knew more about what was moving it than anyone else. That made his prioritization calls credible, and credibility is the foundation of influence.

Other practical levers: write very clearly (nothing builds credibility faster than a spec that is easy to understand), communicate decisions with explicit dates rather than vague timelines, and give stakeholders early visibility into your thinking — not as a final presentation, but as a draft that invites their input.

There is no single profile of a great product manager. But certain traits appear consistently in the most effective PMs regardless of background. Noah Weiss (Slack, Foursquare, Google) spent years studying what separated the PMs who consistently delivered from those who did not.

Weiss made one observation worth sitting with: being the most informed person in the room about your product, customers, and problem space is one of the most reliable paths to early influence. It does not require seniority or a long track record. It requires consistent investment in learning.

The beginner's mind

Marc Benioff describes the habit that has kept him effective across twenty-five years of building: cultivating what he calls a beginner's mind. In the beginner's mind, there are many possibilities; in the expert's mind, there are few. The more time you spend on a product, the more you risk becoming over-indexed on your own mental model — and less able to see it through fresh eyes.

The discipline of continuous customer conversations, beginner-level questions in user interviews, and staying genuinely curious about the problem space is what keeps that capacity alive.

There is a version of a junior PM career that moves slowly: you deliver features, attend standups, update roadmaps, and wait for opportunities. And there is a version that moves fast. The difference is not talent — it is the degree to which you are investing intentionally in the skills that compound over time.

Get more technical

Becoming more technical is one of the highest-leverage investments a junior PM can make. This does not mean learning to code — though that is never a bad investment. It means learning enough about how products are built that you can have substantive conversations with engineers, spot feasibility issues early, and earn credibility in technical rooms. Understand the basic architecture of your product, learn how APIs work, know what technical debt means and why engineers care about it.

Build an AI-powered thinking partner

Create a context-rich prompt that captures everything relevant about your product, your team, your market, and your stakeholders — and use that as a shared foundation for every AI-assisted thinking session. This is not about getting AI to do your job. It is about having a tireless thinking partner that knows your context. Use it to simulate stakeholder conversations, get feedback on your writing, and generate the counter-arguments you have not yet thought of.

Write to think

Almost every senior PM who has spoken on Lenny's Podcast mentions writing as a foundational skill — not because PMs produce lots of documents, but because writing forces you to think at a level of precision that verbal discussion rarely demands. You cannot write a clear one-pager about a problem you do not actually understand. The most useful habits: practice writing one-pagers (problem definitions, not solution proposals), and keep a brief weekly log of what you learned from customers, data, and experiments.

Find the metric and own it

Pick a metric that matters, become more informed about it than anyone else, and let it guide every prioritization decision you make. Not because metrics capture everything — they do not — but because having a clear fitness function for your team's work is the fastest path to demonstrating impact and earning the trust to do more.

Product management is a craft that develops over years, not months. But certain foundations, if laid early, make everything else easier.