Nov 16, 2020
Product managers decide what to build next and they're accountable when the bet is wrong.
The role spans vision, strategy, user experience, execution, and outcomes. A PM defines where the product is going, figures out what needs to exist to get there, and then pushes alongside designers, engineers, and a dozen stakeholders to make it happen. They don't build things themselves. They direct the people who do.
The conductor analogy works here. Conductors might know a few instruments, but they don't play them all at once. What they do is shape a performance out of people who are each more technically skilled than the conductor will ever be. That's the job.
PMs sit at the intersection of users, technology, and business. You have to understand all three not master all three but well enough to make trade-offs no single specialist could make alone.
And critically: PMs make the prioritisation calls the organisation trusts. That means saying no more than yes. Explaining why a genuinely good idea is getting deprioritised. Being wrong sometimes and shipping anyway.
The role touches everything - customer support, finance, legal, marketing. If a product change affects another team, a PM's job is to understand how, facilitate the transition, and make sure no one gets surprised by it.
See also: Why PMs Aren't Driving Strategy (And Why Workshops Won't Fix It)
The job asks for a specific combination that doesn't come naturally from any single background.
You need enough analytical rigour to make decisions from data without waiting for certainty that's never coming. Enough customer empathy to stay genuinely curious about why people behave the way they do, not just whether your metrics went up. Enough communication skill to bring engineers, designers, and executives to the same understanding of a problem - without it feeling like a presentation.
And then the one that's hardest to teach: the willingness to make a call, own it, and change direction cleanly when you're wrong. A lot of smart people stall at this part.
Experience matters less than most job descriptions suggest. Mindset and judgment matter more.
Less about a specific process, more about a few habits of thinking good PMs keep returning to.
Start with the user's problem, not the solution. A feature request is almost never the answer, it's a signal. Your job is to find what's underneath it.
Think in bets, not certainties. You're making prioritisation calls with incomplete information, constantly. Good PMs hold a position firmly enough to ship something, while staying genuinely open to being wrong.
Obsess over outcomes, not output. Shipping a feature isn't success. Users changing their behaviour in the way you predicted - that's success.
Communicate like it's your main job, because it is. Your role is to make sure everyone building your product has the same mental model of what they're building and why. If they don't, that's on you.
Say no more than yes. Every yes is a no to something else. The PMs who do this well protect their team's focus without killing the relationship with the person they said no to.
There's no clean answer, it shifts depending on where the product is in its lifecycle and what's currently on fire.
But in most weeks, you'll find: customer calls or review of user feedback, planning conversations with design and engineering, stakeholder check-ins, and a chunk of async writing, briefs, strategy docs, decision logs, and the occasional ticket that would take ten minutes to write yourself but two hours to explain why someone else should write it.
Discovery work (figuring out what to build) and delivery work (helping the team ship it) run in parallel, not in sequence. You're always doing some of both, and the balance shifts week to week.
The variation is what makes it interesting. The variation is also what makes it hard to explain to people who don't do it.
Yes. But it's rarely grind-stressful. It's more ambiguity-stressful.
You'll make calls you can't fully justify. Stakeholders will push competing priorities from every direction. You'll launch things that don't land the way you expected. That's not a sign you're doing it wrong...that's the job.
What keeps it sustainable: shipping. Seeing users actually use something you helped bring into the world is one of the better feelings you can have in a knowledge job. That part doesn't get old.
If you're in a rough patch right now:
The confusion is understandable. The titles are similar. The jobs aren't.
A product manager owns the outcome. They decide what to build and why, based on user needs and business strategy. The question they keep returning to: are we building the right thing?
A project manager owns the delivery. They plan the work, track the timeline, manage dependencies, and make sure things get done on time and within budget. Their question: are we delivering what we committed to?
Most product managers are decent project managers. They have to be, execution is part of the job. But project management skill alone doesn't make someone a PM. Product thinking does.
The simplest way to put it: a project manager can deliver the wrong product on time, on budget, and have done their job perfectly. A product manager cannot.
Here's how the roles differ in practice:
Product Manager is a job. Product Owner is a role inside an agile team. They're not the same thing, even when one person holds both.
A PM owns the full lifecycle: market understanding, strategy, prioritisation, cross-functional alignment, and the product's overall success. Broad mandate, lots of ambiguity.
A Product Owner is responsible for a narrower scope, managing the backlog, writing user stories, working day-to-day with the engineering team so delivery keeps moving. In smaller orgs, one person does both. In larger ones, they're different people with different calendars.
If you're looking for jobs, go for the Product Manager title. It signals broader ownership and is a better long-term anchor for your career.
Scope and altitude.
A product manager typically owns a product or a significant area of a product. They're close to the user, the roadmap, and the team's day-to-day work.
A Head of Product or CPO is accountable for the product organisation as a whole: hiring and developing PMs, setting the product strategy across the full portfolio, working with the exec team on company direction, and making sure product thinking is actually influencing the business...not just the backlog.
The shift from PM to Head of Product is one of the bigger career transitions in the field. You stop being the one with the best product opinion in the room and start being the one who builds an organisation that consistently produces good ones.
The most reliable path is an internal transition and most people skip it because it feels too slow.
You don't start by applying to PM jobs. You start by acting like a PM where you already work. That looks like volunteering for problems no one owns, documenting user feedback and sharing it with stakeholders unprompted, proposing solutions instead of just flagging issues.
A few things worth doing now, regardless of where you are:
The credential path exists too: bootcamps, certifications but they're rarely the differentiator employers actually care about. Evidence of thinking like a PM is.
How to get into product management with no experience →
Coming from a completely different industry or background: Breaking into Product Management →
No.
You need to understand how software is built, conceptually, well enough to have useful conversations with engineers and avoid making requests that cost a week for everyone involved. That's a different bar from writing code.
What matters more is curiosity about technology. You should know roughly how APIs work. You should understand why technical debt is expensive. You should be able to read a system diagram without freezing.
Engineers will respect you for knowing your lane and giving them space to do theirs. They'll lose patience fast if you start prescribing technical solutions you haven't thought through, or worse, underestimating what something actually takes to build.
A short list that actually holds up:
Read them in that order if you're starting out. Come back to Rumelt after you've had to write a strategy document and wondered if what you wrote was actually a strategy.
Ask them if they are a Project Manager.
Seriously, don't.
A product strategy is a plan that explains how your product will achieve a specific outcome, given the real constraints of your market.
It's not a roadmap. It's not a list of features with quarterly delivery dates. It's a set of choices...what you'll do, what you won't, and why those choices work together as a coherent whole.
Richard Rumelt's framing is the most useful one: good strategy has three parts. A diagnosis - what's actually going on. A guiding policy - how you'll respond to that reality. And coherent actions - the specific moves that follow from the policy.
If your team can't explain the strategy without a slide deck, it probably isn't one yet.
Product Strategy: Frameworks, Examples and How to Build One →
If you want a template to work from: Product Strategy Canvas Notion Template →
A roadmap is a sequence of things you plan to build. A strategy is the reason that sequence makes sense.
Most teams have a roadmap. Fewer have a strategy. The gap shows up when someone asks "why are we building this next?" and the honest answer is "because a stakeholder asked for it" or "because the competitor just shipped something similar."
A roadmap without a strategy is an expensive to-do list. It'll keep the team busy. It won't necessarily move the product in the direction that matters.
What makes a real product strategy →
Rarely with complete information.
The job is to make the best call you can with what's available and move. Analysis paralysis is expensive in ways that don't show up on a sprint board: decisions get delayed, teams wait, opportunities close while the meeting is still going.
A few patterns that actually help:
Full decision-making framework →
AI has shifted the bottleneck in product development. Execution used to be the constraint: ideas were cheap, building was expensive. AI flips that. Capacity is no longer the hard part. Having something actually worth building is.
That's the problem with treating AI as a strategy. AI can analyse faster, generate more options, surface patterns in data you'd have missed. What it can't do is tell you which market opportunity is worth pursuing, or why your company is better positioned than anyone else to pursue it. That's a judgment call. It requires the kind of synthesis that doesn't come from a prompt.
The teams getting the most from AI right now aren't the ones using it to generate strategy. They're using it to execute on a strategy that was already clear and moving faster because of it.
Why AI won't save a bad product strategy →
It's what happens when a product manager becomes a backlog administrator.
Jira Syndrome sets in gradually. The PM gets good at running sprints, keeping stakeholders updated, making sure tickets are written clearly and nothing falls through the cracks. The team is productive. Delivery is smooth. And somewhere along the way, the strategic thinking quietly stops because nobody asked for it and the calendar never made space for it.
The backlog gets cleaner. The product gets less interesting.
It's not laziness. It's what happens when every incentive and every ritual in the organisation points toward delivery and nothing points toward the harder question of whether you're building the right thing.
Discovery is figuring out what to build. Delivery is building it.
Most teams spend the majority of their time in delivery: sprinting, shipping, retros, and repeat. Discovery is what happens before that: talking to users, testing assumptions, figuring out whether the thing you're about to build will actually solve the problem you think it does.
The common mistake is treating them as sequential. Discovery happens first, then delivery starts. In practice, the best teams run both continuously. You're always delivering something and always learning about what to build next.
If your team is only doing delivery, you're probably building faster than you're learning.
Prioritisation is one of the most context-dependent things in the job, which is why there are so many frameworks for it: RICE, ICE, MoSCoW, Opportunity Scoring and none of them is obviously the right one in every situation.
The underlying logic is consistent: you're trying to rank work by the ratio of impact to effort, filtered by strategic fit.
A few things that help in practice:
Not by whether it shipped.
The metric depends on the type of product and the stage you're at, but the underlying question is always the same: did users change their behaviour in the way you predicted, and did that move a business outcome you care about?
In early stages, you're often looking at leading indicators: activation rates, retention at day 7 and day 30, qualitative signals from user interviews. Later you're tracking revenue impact, NPS, churn, lifetime value.
The trap is measuring what's easy to measure rather than what matters. Features shipped is easy. Sessions per user is easy. Whether the product is actually solving the problem it was built to solve is harder, and requires getting out of the dashboard.
PLG is a go-to-market strategy where the product itself drives acquisition, expansion, and retention - rather than a sales team.
Users experience the product before they commit to paying for it. The product has to be good enough, and low-friction enough, that people sign up, find value quickly, and bring others in over time. Slack, Figma, Notion, and Dropbox are the canonical examples.
The product manager's job in a PLG model shifts in one important way: the product team owns the growth metrics, not just the feature metrics. Time-to-value, activation rate, and viral coefficient become part of your remit.
It's not the right model for every product. Complex B2B tools, regulated industries, and anything that requires significant configuration usually still need humans in the sales loop.
There's no direct authority over the team. You lead through credibility, communication, and relationships.
That means building trust over time by following through, being right often enough that people value your judgment, and making sure stakeholders feel informed rather than surprised. Engineers who know you understand the technical trade-offs will push harder for you. Designers who trust you'll protect their vision in stakeholder reviews will give you their best work.
The mechanics vary: presenting data that supports a decision you believe in, running workshops to align on direction, having hard conversations with executives pushing for different outcomes. None of it is optional.
The more senior you get, the more of your time goes to influence and the less to direct execution. That's the progression.
SCQA stands for Situation, Complication, Question, Answer. It's a communication framework, originally from Barbara Minto's Pyramid Principle, that makes arguments easy to follow by structuring them around how problems naturally unfold.
Most people write communications in the wrong order. They dump context, meander through options, and bury the recommendation at the end. SCQA flips that. You ground the reader in the current situation, name the complication that creates a problem, surface the question the complication raises, then answer it directly at the top.
It's the difference between a document that gets read and one that gets skimmed for the bullet with the action item.
SCQA explained with examples →
Fintech is a specific problem space: regulated, trust-sensitive, and often two-sided in ways that make early traction genuinely difficult.
From direct experience running product at a fintech startup in a two-sided marketplace: the problems that actually slow you down aren't usually the ones on your original risk register.
The three that bite hardest:
Problems faced by fintech startups in a two-sided marketplace →
A two-sided marketplace connects two distinct user groups who each need the other to exist. Airbnb needs hosts and guests. Uber needs drivers and riders. A payments product needs merchants and consumers.
The hard part is the cold start problem: neither side shows up without the other already being there. You need supply before you can attract demand, but supply won't commit without demand in sight.
The typical approach is to seed one side manually, often B2B clients or supply-side partners, before opening to the other. Growth is slow until you hit a density threshold in a given market, then it can compound quickly.
From direct experience in fintech: the supply side tends to be the harder and more expensive side to acquire, and it's usually where you should start, even if the consumer experience is what excites you.
Problems faced by fintech startups in a two-sided marketplace →
The instinct is to cast wide. The move that actually works is narrow and deep in the specific places your users already gather.
If people don't yet know they have the problem you solve, your first job isn't to sell. It's to name the problem clearly enough that people recognise it in themselves. That usually happens through content, community, and specific distribution channels that reach your exact user rather than everyone adjacent to them.
Raising problem awareness for a niche product - practical breakdown →
Planning your product strategy is harder than most frameworks admit because the hard part isn't the template, it's knowing what choices you're actually making.
That said, a good template forces the right questions. The Product Strategy Canvas Notion Template is designed to help you map your strategy in a way that's concrete enough to act on, and simple enough that your team can actually explain it to someone in the lift.
It draws from Melissa Perri's thinking on good product strategy. Worth spending an hour with before your next planning cycle.
Keep reading
You paid for research. Someone else got the instincts. You open your email and see the PDF from the agency. It has clean design. Graphs in pastel colours. 47 sl...
I've run a lot of PM and product design interviews. Most optimise for hypotheticals: “What would you build?” or “How would you approach X?” They test theory in...
When you're part of a good 1:1 product management community, it keeps you away from quietly losing your marbles. One of the most common topics that surfaces is...
Best posts on product, strategy and AI. One email a month.
