What you need to do
The practical activities and techniques you need to master – what to practice, what to get good at, and what to keep doing.
Goal setting
Defining what success looks like before deciding how to get there. Goal setting connects product work to business outcomes – every feature, experiment, and initiative should trace back to a goal. Start by identifying the outcome you’re driving toward, then break it down into measurable targets. Use frameworks like OKRs, North Star metrics, or SMART goals to structure your thinking. The discipline isn’t choosing a framework – it’s the practice of writing down what you’re trying to achieve and making it specific enough that you’ll know when you’ve succeeded.
Assumption mapping
Surface what you believe vs. what you know. Use a 2×2 matrix: Importance vs. Knowledge (known/unknown). Three assumption types: desirability (do users want this?), feasibility (can we build it?), viability (is it sustainable?). Focus testing on the “important + unknown” quadrant first. Run 1–2 experiments at a time on the riskiest assumptions. The goal is to identify blind spots before they become expensive mistakes.
PRD writing
Define what to build, for whom, and why – as a living document, not a one-time artifact. Key sections: problem statement, success metrics, personas, user scenarios, functional requirements, non-functional requirements (performance, security, scalability), features explicitly out of scope, and open questions. Share with design first, then engineering. Use Given-When-Then format for acceptance criteria. Update continuously as understanding evolves.
User story writing
Define the problem without prescribing the solution. A good statement covers who is affected, what is affecting them, why it matters, and where it happens. Use the template: “As a [user], I’m trying to [motivation], so I can [expected outcome], but [problem], which makes me feel [emotion].” The emotional dimension reveals severity and drives team empathy. If your problem statement reads like a feature request, start over.
Prioritization
Deciding what to build next based on evidence, not opinions. Prioritization takes your mapped assumptions, validated insights, and business goals and turns them into a sequenced plan. Use frameworks like RICE to make trade-offs explicit and comparable. The key discipline: prioritize by impact on your goals, not by effort required or stakeholder volume. If no critical assumptions remain untested, the idea is ready for implementation.
Frameworks to know
The mental models and structured approaches that guide how you think about this skill – not rules to follow, but lenses to see through.
North Star Framework (Amplitude / Sean Ellis)
Single metric capturing core customer value, supported by 3–5 input metrics. Three game types: Attention (time spent – Facebook, Netflix), Transaction (number of transactions – Amazon, Uber), Productivity (efficiency – Salesforce, Adobe). Revenue is usually a bad North Star because it lags actual product health.
OKRs (Andy Grove / John Doerr)
Objectives (qualitative, inspirational) + Key Results (quantitative, measurable). Four superpowers: focus, alignment, tracking, stretching. Invented for execution, not strategy – don’t shoehorn vision into OKR format. Two types at Google: committed (expected score 1.0) and aspirational (expected score 0.7).
SMART goals
A goal-setting framework that ensures goals are Specific (clearly defined outcome), Measurable (quantifiable indicator of success), Achievable (realistic given constraints), Relevant (aligned with broader objectives), and Time-bound (has a deadline). SMART goals work at every level – from quarterly team objectives to individual sprint commitments. The framework’s power is in the acronym’s constraints: vague goals like ‘improve the user experience’ become specific targets like ‘increase task completion rate from 60% to 80% by end of Q2.’ Apply SMART criteria to every goal before committing resources.
Good vs. bad
Common mistakes paired with what experienced practitioners do instead – and why the product builder approach changes the game.
Most teams treat problem framing as a checkbox – write a problem statement, maybe run a workshop, then rush to wireframes. That’s backwards. Problem framing is the moment where you decide whether to invest weeks of engineering into something that matters or something that doesn’t.
The biggest mistake I see: teams that skip root cause analysis. They observe a symptom – “users drop off at step 3” – and immediately design a fix for step 3. Five Whys would have told them the real problem is at step 1, where users make a wrong assumption about what the product does. Fixing step 3 is wasted work.
The second mistake: treating goals as decoration. OKRs written after the roadmap is decided. North Star metrics chosen because they sound good in a presentation. If your goals don’t change what you build, they’re theater.
AI changes the economics of problem framing. You can draft a PRD in minutes, generate assumption maps from interview transcripts, and have Claude review your spec for gaps. What used to take a week now takes an afternoon. But the judgment calls – which problem is worth solving, which assumption is riskiest, what “good enough” looks like – those are still human decisions. AI makes problem framing faster. It doesn’t make it optional.
The product builder advantage: when the same person who frames the problem also designs the solution and writes the code, there are zero handoffs between understanding and building. The problem statement lives in the builder’s head, not in a document that gets misinterpreted three times. That’s how you get from insight to shipped product in days, not months.
Go deeper
Books to deepen your understanding beyond what fits on this page.
The definitive OKR guide. How Google, Intel, and the Gates Foundation use Objectives and Key Results to focus, align, track, and stretch.
Why organizations ship features for their own sake and how to pivot toward outcomes and value. The case for connecting every requirement back to a real problem.
The classic on managerial output and leverage – how OKRs, one-on-ones, and meetings actually drive team performance. The book Silicon Valley managers keep returning to.
