Kevin Lee

A decision log is the lightweight record I use to preserve important product choices and the context behind them. I write down what we decided, who decided it, when it was decided, what evidence informed it, and what assumptions or consequences still matter. The goal is not to document every preference. The goal is to stop the team from repeatedly reopening a choice without remembering why it was made. I...

A one-pager is the short product brief I use when a team needs a shared starting point for a problem, opportunity, decision, or proposal. Its value is not that every subject can fit neatly on one page. Its value is that the constraint forces me to say what matters now, what I know, what I do not know, and what decision I am asking people to make. I use a...

RACI is a way I clarify roles around a task or decision: who is responsible for doing the work, who is accountable for the outcome, who should be consulted before it happens, and who should be informed afterward. I use it when ownership is unclear or when a cross-functional effort keeps producing duplicated work, missed approvals, or surprised stakeholders. RACI is not a replacement for judgment, trust, or communication. A...

A product requirements document (PRD) is the shared brief I use to explain a product problem, the people affected, the outcome I want, and the boundaries around a proposed solution. I do not treat it as a contract that predicts every implementation detail. I treat it as a decision and communication tool: enough context for design and engineering to make good choices without asking me to dictate every choice in...

Experiment velocity is the pace at which a product team turns a meaningful question into evidence and a decision. I do not define it as the number of tests launched. A team can run many experiments and learn very little if the questions are weak, the instrumentation is unreliable, or decisions are left waiting in a queue. I care about shortening the path from uncertainty to responsible action. I use...

A/B test sample size is the amount of information I plan to collect before deciding whether a controlled comparison can answer my product question. I treat it as a planning decision, not a number I search for after the test has started. A sample-size estimate depends on the outcome, the baseline behavior, the change I need to detect, the uncertainty I will tolerate, and the traffic available to the experiment....

Statistical significance is a way of describing how surprising observed data would be under a specified null model and analysis plan. I use it as one piece of evidence in a product decision, not as a synonym for importance, truth, or customer value. A statistically significant result can be too small to matter, while a useful effect can remain uncertain when the experiment is underpowered or noisy. This distinction matters...

A prototype is a representation of a product idea that lets me learn before I commit to building the real thing. It can be a sketch, a clickable flow, a role-play, a coded slice, or something else that makes a question observable. I do not judge a prototype by how polished it looks. I judge it by whether it helps me learn something important with less cost and risk than...

Usability testing is a structured way for me to observe people attempting tasks with a product, prototype, or service. I use it to learn where the experience becomes confusing, what people expect to happen, and whether the design supports the intended goal. I am not testing a person’s intelligence, and I am not asking a participant to approve my design. I am testing whether the design communicates enough for someone...

Survey design is the work of turning a product question into questions people can answer consistently. I use a survey when I need structured input across a defined group, a way to compare responses, or a follow-up to qualitative learning. A survey is not automatically representative, and a large response count cannot repair a confusing question or a poorly defined audience. I design for a decision, then state what the...

Qualitative research helps me understand how people describe a problem, work through a task, and make tradeoffs in context. I use it when I need depth: the language customers use, the workaround behind a request, or the reason an apparently simple workflow feels difficult. It does not tell me how common every observation is. It gives me material for forming and refining hypotheses, not permission to generalize beyond the evidence....

Product analytics instrumentation is the work of deciding what product behavior to record, how to record it, and how to keep that data useful over time. I treat it as part of product design rather than a tracking task I hand off at the end. When the events are tied to real decisions, analytics can help me see where people encounter friction, which workflows they use, and what I still...

Win/loss analysis is my structured review of why a prospective customer chose us, chose another option, delayed a decision, or stopped responding. I use it to understand the product, positioning, buying process, and competitive context from the outside. It is not a search for a person to blame. It is a way to test the assumptions behind our value proposition and find questions worth investigating. A sales outcome is informative,...

Customer shadowing is a research practice in which I observe a person doing real work in the context where the product is used. I pay attention to the task, environment, handoffs, tools, interruptions, and workarounds around the visible interface. A conversation can tell me what someone remembers or believes. Observation can show me what the workflow requires when the person is busy and the ideal path is not available. I...

Dogfooding means using the product I help build in a real work context. I value it because direct use can reveal confusing language, broken transitions, missing defaults, and operational friction that a plan or demo may hide. I do not treat dogfooding as proof that the product works for every customer. It is one source of evidence, and it becomes more useful when I define its limits. I use dogfooding...

Release notes are part of the product experience, not a ceremonial list I publish after the real work is done. When I write them, I am helping customers understand what changed, why it matters to them, and what they should do next. A good note can reduce surprise, invite useful feedback, and make a product decision easier to discover later. A vague note can create confusion even when the underlying...

Build versus buy is a product decision about how I will obtain a capability the product needs. “Build” may mean creating and operating the capability internally. “Buy” may mean adopting a vendor, service, component, or managed workflow. A hybrid option may combine an external foundation with internal experience, data, or controls. I do not treat the choice as a contest between engineering pride and procurement speed. I compare the options...

Technical debt is the future cost created when a product or system carries a shortcut, constraint, or accumulated complexity. I use the metaphor carefully. Some shortcuts are deliberate and sensible when they buy learning or speed. Others make future changes slower, riskier, or more expensive. The important product question is not whether the code is elegant; it is how the technical condition affects customers, the team, and the choices we...

A spike is a time-boxed investigation I use when uncertainty could materially affect a product decision. The question may involve an unfamiliar integration, a performance constraint, data quality, security, or an edge case that a normal story does not explain. A spike can help me learn enough to choose a path, but it is not automatically a feature and it is not a promise that the final implementation will be...

A design sprint gives me a short, structured way to investigate a product question before I commit a team to a longer build. I use the idea when the decision is important, the problem is still fuzzy, and a small group can learn more by working together than by scheduling another sequence of disconnected meetings. The sprint is not a shortcut around research or engineering. It is a way to...

A business model canvas helps me see how a product creates, delivers, and captures value. I use it when product decisions depend on more than the interface: distribution, partnerships, operations, pricing, support, data, and the costs of keeping the promise reliable. The canvas gives me a shared language for those connections. I do not use it as a claim that the business model is proven. It is a structured set...

A problem statement gives me a concise, shared description of the product problem I am trying to understand. I use one before discovery, prioritization, design, or delivery when a request is moving faster than the evidence. A good statement helps the team investigate the same problem without quietly committing to a solution. I do not expect a problem statement to be perfect on the first attempt. It is a working...

A lean canvas gives me a compact way to make a product or business idea inspectable. I use it when a team is moving from a broad opportunity toward a set of hypotheses about customers, problems, solutions, channels, revenue, costs, key metrics, and defensibility. It is useful because it puts the assumptions in one place, not because filling every box creates a business. I treat the canvas as a snapshot...

A value proposition canvas helps me connect what a customer is trying to accomplish with what a product offers. I use it when a team has a promising idea, a crowded list of requests, or a message that sounds attractive but is not yet grounded in a specific customer context. The canvas gives me a disciplined way to compare customer jobs, pains, and gains with the products and services intended...

Assumption mapping is a way I make the beliefs behind a product decision visible and decide which ones deserve attention first. I list what must be true for an idea to create value, then consider each assumption by its importance and how much evidence I have. The map helps me turn vague uncertainty into a set of questions and tests. I use it before a team commits to a solution,...

Buy a Feature is a collaborative product-research exercise I use to explore what people value when they have to make tradeoffs. I give participants a set of possible features or improvements and a limited amount of fictional currency. They can buy items alone or pool money with others, then explain why they made those choices. I treat the activity as a way to learn about priorities, language, and perceived value....

A weighted scoring model is a prioritization method I use when several product options need to be compared against the same criteria. I assign each criterion a weight, score every option against those criteria, and combine the results into a relative view. The model makes tradeoffs easier to inspect because I can see which assumptions and priorities drive the ranking. I do not treat the resulting order as an objective...

ICE scoring is a lightweight way I compare product opportunities using three dimensions: impact, confidence, and ease. I use it when a team needs a transparent first pass across several possible bets, but does not yet have the evidence or time for a heavier prioritization exercise. The score helps me make my reasoning visible. It does not tell me which work is valuable by itself. I treat ICE as a...

An outcome-based roadmap is the planning view I use to show the results a product team is trying to create, the customer problems behind them, and the bets we may make to learn or improve. It is different from a feature calendar. A feature roadmap says what the team expects to deliver; an outcome-based roadmap explains why the work matters and leaves room to change the solution when evidence changes....

Product sense is the judgment I use to understand a customer problem, see the product tradeoffs around it, and choose a useful next step when the evidence is incomplete. I do not treat it as intuition that is magically correct. For me, product sense is a set of habits I can practice: noticing the context, clarifying the job, comparing options, explaining tradeoffs, and learning from what happens next. It matters...

An opportunity assessment is the structured review I use to decide whether a customer problem is worth pursuing now. It helps me move from “someone asked for this” to a clearer view of the problem, the people affected, the evidence available, the strategic fit, and the cost of learning more. It is not a business case that proves an idea will work. It is a decision aid for choosing whether...

Impact mapping is a planning technique I use to connect a product goal to the people, behavior, and work that might help us reach it. Instead of starting with a list of features, I start by asking what outcome matters, whose behavior needs to change, and what we could do to support that change. The map gives the team a shared line of reasoning without pretending that the plan is...

A working backwards PR/FAQ is a product framing exercise in which I describe the customer value of a future offering before committing to its implementation. The PR is a short, customer-facing announcement written as if the product were ready. The FAQ answers the questions customers, operators, leaders, and builders would ask about the promise. I use the pair to test whether the idea is clear, valuable, and coherent before a...

A product triad is the close working partnership between product management, product design, and engineering around a product decision. I use the term to describe a way of working, not a required org chart or a claim that three people can represent every perspective. The triad brings customer value, usability, technical reality, and business context into the same conversation early enough to shape the work. I find the model useful...

Continuous discovery is the habit of learning from customers throughout product work, not a research phase that ends before delivery begins. I use it to keep product decisions connected to current behavior, changing context, and the outcomes people are trying to achieve. The practice does not require constant meetings or a large research department. It requires a regular path from a product question to customer evidence and back to a...

A discovery backlog is the visible list of questions, assumptions, and evidence-gathering tasks I use before and alongside delivery. It is not a second feature backlog, a research wish list, or a queue of interviews with no decision attached. I use it to make uncertainty discussable: what do we need to learn, why does it matter, how will we learn it, and what decision will change when we have evidence?...

Customer development is a disciplined way I use to learn whether a product idea addresses a real problem for a reachable customer and can support a workable business. It is not a script for asking people whether they like my idea. I use it to test assumptions about the customer, problem, solution, channel, economics, and behavior before I invest heavily in building or scaling. I treat the process as learning...

The HEART framework is a way I organize product experience measurement around happiness, engagement, adoption, retention, and task success. I use it to avoid reducing a complex customer experience to one convenient number. The framework gives me prompts for choosing a goal, signals that indicate progress, and measures that can reveal whether the experience is improving. I do not treat HEART as a required five-metric dashboard. Some products need all...

Pirate metrics, often written as AARRR, is a framework I use to discuss how people move from first finding a product to receiving ongoing value and contributing to sustainable revenue. The letters stand for acquisition, activation, retention, referral, and revenue. The framework is memorable, but the real work is defining the customer behavior and product value behind each stage. I do not treat AARRR as a universal funnel or a...

The MoSCoW method is a prioritization technique I use to make scope tradeoffs visible. I sort candidate requirements into must have, should have, could have, and will not have for this time or release. The labels do not produce a ranking by themselves. They give the team a shared language for discussing value, risk, dependency, and the consequences of leaving something out. I find MoSCoW most useful when a team...

Dual-track agile is an approach I use to run product discovery and delivery as connected, ongoing activities. In the discovery track, the team learns which customer problem is worth solving and what solution is likely to work. In the delivery track, the team builds, tests, releases, and operates solutions. The tracks move together rather than treating discovery as a one-time phase or a handoff to engineering. I do not think...

Story mapping is a way I organize product work around the customer journey rather than a flat list of features. I lay out the activities a customer performs, the tasks within those activities, and the possible solutions that help complete them. The map gives the team a shared view of the experience and makes it easier to choose a coherent first slice. I use a story map to support conversation,...

Van Westendorp pricing is a survey-based way I use to explore how customers perceive the price of a product or offer. It asks four questions about what feels cheap, expensive, too expensive, or suspiciously inexpensive. The responses can reveal a range of acceptable price perceptions, but they do not tell me the one correct price or guarantee that customers will buy. I treat the method as an input to pricing...

A premortem is a short exercise I use before a product plan, launch, or major decision is committed. I ask the team to imagine that the effort has already failed and then work backward to explain why. The point is not to predict the future or make the room cynical. It is to make plausible failure modes discussable while the team can still change the plan. I find a premortem...

TAM, SAM, and SOM are three ways to frame market size. Total addressable market, or TAM, is the broadest opportunity if the relevant problem could be served without today’s constraints. Serviceable available market, or SAM, narrows that opportunity to the customers and use cases a product can realistically target. Serviceable obtainable market, or SOM, is the portion I could plausibly reach and win over a defined period. I use the...

Product-led growth, or PLG, is a way of organizing growth around customers experiencing and sharing product value. The product does not replace marketing, sales, support, or strategy. It becomes an important part of how people discover a use case, reach a meaningful outcome, invite others, expand usage, and decide whether the product deserves continued investment. I treat PLG as an operating approach rather than a funnel trick. A free plan,...

Cohort analysis helps me compare groups of customers that share a starting point and then follow what happens to each group over time. Instead of looking only at one blended average, I can ask whether customers who started in different weeks, acquired through different channels, or adopted different experiences retain and reach value differently. The technique is simple to describe but easy to misuse. A cohort is not automatically a...

The Kano model helps me understand how different product capabilities affect customer satisfaction. Instead of treating every requested feature as a simple vote, I ask what happens when the capability is absent, adequate, or better than expected. That distinction changes prioritization: a basic need can create frustration when missing, a performance feature can improve satisfaction as it improves, and an attractive feature can delight some customers without being expected. I...

An opportunity solution tree is a visual way to connect a desired product outcome to the customer opportunities that may influence it, the solution ideas that could address those opportunities, and the experiments that help a team learn. I use it to keep discovery anchored in outcomes without pretending that one feature is the answer from the start. The tree is not a roadmap template or a list of every...

RICE scoring is a prioritization method that compares opportunities using reach, impact, confidence, and effort. I use it to make assumptions visible and create a consistent conversation—not to turn product strategy into a calculator. A score can organize a decision, but it cannot supply missing evidence or resolve a strategic choice by itself. The common formula is (reach × impact × confidence) ÷ effort. Teams may use different scales and...

OKRs—objectives and key results—help me connect product strategy to a small set of measurable outcomes. An objective describes the change we want to create. Key results describe evidence that would show whether the change happened. The framework is useful when it improves focus and learning; it is harmful when it becomes a quarterly list of tasks or a performance theater exercise. I use OKRs to clarify the problem the team...

A north star metric is a product-level measure of customer value that helps a team connect daily work to a meaningful outcome. I use it as a strategic alignment tool, not as a scoreboard that replaces judgment. The right metric gives the team a shared direction while leaving room for supporting metrics, qualitative evidence, and context. A north star metric is not necessarily revenue, active users, or a count that...

Product ops is the operating layer that helps a product organization turn scattered information and repeated work into reliable product decisions. It can include customer insight practices, product tooling, data definitions, planning routines, documentation, and cross-functional coordination. The exact scope varies by company. The purpose is consistent: help product teams spend more time on judgment and less time reconstructing context. I do not treat product ops as an administrative substitute...

Feature flags let a team separate deploying code from exposing a capability to users. For a product manager, that separation can make releases safer and learning faster. It can support a gradual rollout, an experiment, an internal preview, a customer migration, or a quick rollback when a change behaves badly. A flag is not a launch strategy by itself. It introduces a control surface that needs an owner, a purpose,...

A customer feedback loop is the repeatable path from what customers tell or show us to what the product team learns, decides, changes, and communicates back. I use the word loop deliberately. Collecting comments is not enough. If feedback never changes a decision or reaches the people who offered it, the organization is running a suggestion inbox rather than learning from customers. A good loop combines conversation, behavior, support signals,...

Product strategy frameworks help me make choices when a product has more possible directions than the team can pursue. A framework is not a strategy by itself. It is a lens for organizing evidence, exposing assumptions, and making tradeoffs visible. I use one when it improves a decision, not because a slide deck looks incomplete without one. The best framework depends on the question. A market and competitive lens can...

Roadmap prioritization examples Roadmap prioritization is the discipline of deciding which outcomes and bets deserve limited product capacity now, later, or not at all. The best examples are not magic scoring formulas. They show how a product manager combines customer evidence, strategic fit, expected impact, confidence, effort, risk, and sequencing to make a decision that the team can explain. I use a prioritization framework to make tradeoffs visible, but I...

Churn prevention for product managers Churn prevention is the product work of reducing avoidable customer loss by helping the right customers reach and keep receiving value. I treat it as a system, not a last-minute discount campaign. Churn can come from weak activation, unreliable workflows, missing capability, poor fit, pricing, a business change, or a competitor. Each cause needs a different response. This guide is distinct from churn-rate analysis for...

Product launch checklist for product managers A product launch is the coordinated release of a customer promise, not just the moment a feature reaches production. My launch checklist helps the team confirm that the product works, the right customers can understand and access it, support can respond, and we know how we will learn from the release. The checklist is a risk-control tool, not bureaucracy for its own sake. I...

Wireframing for product managers Wireframing is the practice of sketching a product’s structure, flow, and key interactions before investing in polished visual design or code. I use wireframes as conversation tools. They make an idea concrete enough for customers, designers, engineers, and stakeholders to react to while it is still cheap to change. A wireframe is not a miniature final design and it is not a substitute for research. Its...

Product lifecycle for product managers The product lifecycle is the changing set of problems a product faces from the first opportunity signal through retirement. I use lifecycle thinking to adjust the team’s questions, evidence, and investment level as the product moves from an uncertain idea to a mature offering. It is not a promise that every product follows neat stages in a straight line. It is a way to avoid...

Pricing strategy for product managers Pricing strategy is how I decide what to charge, what to package, and how price communicates value to a chosen customer. As a product manager I rarely set price alone, but I am accountable for connecting product value, willingness to pay, packaging boundaries, and the metrics that show whether price helps or hurts healthy growth. Price is a product decision because it shapes who shows...

Experiment design for product managers Experiment design is how I turn a product idea into a fair learning test. I use it whenever we are about to invest engineering time based on a belief that could be wrong. A well-designed experiment clarifies the hypothesis, the audience, the change, the primary metric, the guardrails, and what decision we will make from the result. I do not treat every change as an...

Product analytics for beginners Product analytics is how I learn what users actually do in the product so the team can improve outcomes, not just ship output. If you are new to it, the goal is not to memorize every chart type. The goal is to connect user behavior to decisions: what to build next, what to fix, and what to stop doing. I start beginners with a simple loop....

Jobs to be done for product managers Jobs to be done (JTBD) is a way I understand why customers “hire” a product or workaround to make progress in a specific situation. I use it when feature requests are noisy and personas alone are not explaining switching behavior. A job statement focuses on the progress people want, the context that triggers action, and the outcomes that count as success. JTBD does...

Product-market fit for product managers Product-market fit is the point where a defined set of customers consistently choose your product for an important job and get enough value to keep using it, pay for it, or both. I treat PMF as evidence, not a slogan. Teams that declare fit too early usually scale acquisition into a leaky product. Teams that never name fit criteria stay stuck in endless discovery theater....

Activation metric for product managers An activation metric marks the moment a new user or account first receives real value from the product. I use it to judge whether onboarding creates a successful start, not merely a completed signup. If people register but never activate, acquisition spend and roadmap effort leak away before the product has a chance to retain them. Activation is not the same as signup, email verification,...

Retention rate for product managers Retention rate tells me whether the people or accounts I care about continue to receive value over time. I treat it as a product learning metric, not only a finance score. If customers stay, something in the experience is working. If they leave, something in the promise, product, or surrounding journey is failing. Before I calculate anything, I define retention carefully. Who is in the...

Go-to-market strategy for product managers Go-to-market strategy is the plan for how a product, feature, or offer reaches and wins a chosen set of customers. As a product manager I do not own every channel, but I am responsible for making sure the product story, readiness, packaging, and success criteria fit the way we plan to sell, onboard, and expand. A launch without GTM clarity often creates a finished feature...

Product vision for product managers Product vision is the durable picture of the change I want the product to create for a defined set of customers. I use it to align teams on direction when near-term plans keep shifting. A useful vision is specific enough to guide tradeoffs and open enough to allow many paths to get there. I do not treat vision as a slogan contest. “Be the easiest...

User stories for product managers User stories help me describe a product change from the perspective of a person trying to accomplish something. I use them to keep delivery conversations anchored in who is affected, what they need, and why it matters. A good story is a promise of a conversation, not a contract written in stone before the team understands the work. I like the classic shape because it...

Product backlog for product managers A product backlog is the ordered list of work that might improve the product. I treat it as a living decision surface, not a dumping ground for every request. The backlog should make the next most valuable option easy to see, discuss, and refine. When it is healthy, stakeholders argue about outcomes and sequencing instead of hunting for lost tickets. I do not confuse the...

A/B testing for product managers | Product HQ A/B testing for product managers A/B testing is a controlled comparison in which different groups receive different versions of a product experience and I measure a predefined outcome. Product managers use it to learn whether a change caused a meaningful difference, not simply whether a new screen received positive reactions. A test can inform a decision, but it cannot rescue a vague...

Competitive analysis for product managers | Product HQ Competitive analysis for product managers Competitive analysis is how I understand the alternatives a customer can choose instead of, alongside, or before my product. That includes direct competitors, adjacent products, internal tools, manual work, and the choice to do nothing. I use the analysis to sharpen product strategy and customer understanding—not to create a checklist for copying another company. A competitor may...

Customer journey maps for product managers | Product HQ Customer journey maps for product managers A customer journey map is a shared view of how a particular customer or user moves through an experience over time. I use one to connect a person’s goal with the stages, touchpoints, emotions, obstacles, and outcomes that shape the experience. It is not a decorative timeline. A useful map helps me see where the...

Product discovery for product managers | Product HQ Product discovery for product managers Product discovery is how I reduce uncertainty before a team commits to building a solution. I use it to understand who has a problem, what they are trying to accomplish, what gets in the way, and which response is worth testing. Discovery is not a phase that ends when delivery begins. It is a continuous practice of...

Unit economics describe the revenue, variable cost, and contribution associated with one repeatable unit of a business. The unit might be a customer, account, order, subscription, transaction, or usage-based workload. For product managers, unit economics connect product choices to business health without reducing product strategy to a single finance formula. I use unit economics to ask better questions: Which customers create durable value? What does it cost to acquire and...

Stakeholder management is how I build the relationships, shared context, decision rights, and communication habits needed to move a product decision forward. It is not persuading everyone to agree with me. It is helping the right people understand the problem, contribute relevant knowledge, make or advise on decisions, and see what happens next. Product managers work across functions without always having formal authority. Engineering may understand feasibility and operational risk....

An MVP, or minimum viable product, is the smallest version of a product or experience that can create enough value for a defined user and generate reliable learning about the next decision. I emphasize both halves: viable for someone, and useful for learning. An MVP is not simply the cheapest build, the first release, or a product that is allowed to be careless. For a product manager, the MVP is...

SMART goals give product managers a way to turn a broad intention into a testable commitment. The acronym usually means specific, measurable, achievable, relevant, and time-bound. I use the method as a quality check for goals—not as a license to force every uncertain product bet into a confident-looking number. A useful product goal connects a customer or business outcome to a time horizon and a measurement plan. “Improve onboarding” is...

A prioritization framework is a repeatable way to compare product opportunities when you cannot do everything. I use one to make assumptions visible, not to pretend that a formula can choose strategy for me. The framework gives a team a shared starting point for a decision; product judgment, evidence, and capacity finish the job. This distinction matters because a framework is not the same thing as a prioritization matrix. A...

Customer loyalty metrics tell you whether people stay, expand, and advocate—or merely tolerate you until a switching moment appears. As a product manager, I care about loyalty metrics because they compress a hard truth: acquisition is expensive, and product quality shows up in who remains. Loyalty is earned in the product experience long before a survey asks someone to be a promoter. Your measurement system should reflect that—not just chase...

Psychographic segmentation is how I explain why two customers in the same industry and company size behave like different species. Firmographics tell you who might buy. Psychographics help you understand why they buy, stick, or churn—and what product experience will feel native to them. If your roadmap still targets “mid-market SaaS” as if that were one mind, you will keep shipping compromises that feel half-right to everyone and beloved by...

A prioritization matrix is a tool for making tradeoffs visible. I like matrices because they turn a loud backlog argument into a structured comparison—as long as you remember the scores are judgment aids, not scientific truth. If your team fights the same priority battle every Monday, you do not need more opinions. You need shared criteria, capacity math, and the courage to say no with receipts. What a prioritization matrix...

Capex vs opex is one of those finance distinctions that suddenly matters the moment your “simple” product decision hits budgeting, procurement, or a CFO review. I teach product managers to understand it so they stop being surprised when a technically elegant plan is dead on arrival for accounting reasons. You do not need to recite tax code. You need to know how cost shape, approval paths, and cash timing differ—and...

Net present value—NPV—sounds like something you only touch if you live in finance. I disagree. Product managers make multi-quarter bets with uneven payoffs all the time. NPV is simply a way to compare those bets when a dollar next year is not worth the same as a dollar today. You will not replace FP&A. You will become harder to dismiss in investment conversations because you can show timing, risk, and...

Interviews tell me what people remember; observation shows me what actually happens. I use customer shadowing for product managers when the workflow or environment is part of the problem. Market research is how product managers replace confident guessing with bounded learning. I care less about producing a thick deck and more about answering one decision: should we enter, invest, pivot, or walk away—and what evidence would change my mind? Good...

SWOT analysis gets a bad reputation because teams fill four boxes and then ignore them. I still use SWOT—carefully—because it forces a balanced conversation when a roadmap is drifting into pure feature cheerleading. For product managers, SWOT is a decision aid, not a deliverable for its own sake. The version I defend is short, evidenced, and converted into choices the same week. If a SWOT cannot change what you fund,...

Churn rate analysis is where product managers stop arguing about opinions and start arguing about survival. I treat churn as a diagnostic discipline: define the rate correctly, slice it honestly, find the drivers you can influence, and ship interventions you can measure. Teams that only glance at a single monthly churn percentage usually discover the real fire one quarter too late. Churn work is emotional for stakeholders because it touches...

I get asked “what does CRM mean?” more often than you’d expect from people who already ship product. The acronym is simple—customer relationship management—but for product managers the useful answer is not a vendor list. CRM is the system of record for how your company acquires, serves, and keeps customers. Your job is to treat it as a product signal surface, not a sales toy you ignore until QBR season....

A data product manager owns outcomes for data products, analytics surfaces, experimentation platforms, or features that live or die on data quality and trust. From what I’ve seen, a typical day still looks like product management—discovery, prioritization, shipping, communication—but with extra time on metrics definitions, pipeline health, stakeholder education, and partnering with analytics, DS, and eng. Exact calendars vary by whether you own an internal data platform, a customer-facing insights...

When I help people prep for a data product manager interview, I’m testing whether you can turn messy data into product decisions—and turn product decisions into trustworthy data products. Metrics sense, experimentation, stakeholder alignment, and honest talk about data quality matter more than sounding like a data scientist. I’ve seen candidates recite funnel jargon and still miss the plot on instrumentation. This guide is the frameworks I’d want you to...

A technical product manager resume should show you can translate between users and engineers, prioritize with technical constraints, and ship with operability in mind. When I scan these, I’m looking for systems judgment and collaboration evidence—not a fake CS degree or a dump of tech buzzwords. Here’s the structure, bullet frameworks, and generic examples I’d want you to adapt with your real experience. It complements our Technical Product Manager cluster...

A technical product manager spends the day owning outcomes for products that sit close to systems, APIs, platforms, or heavy eng collaboration. From what I’ve seen, the calendar still looks like product management—discovery, prioritization, shipping, communication—but with more time on technical discovery, incident judgment, and translating between users and engineers. Exact days vary by whether you own platform/infra, developer products, or a “more technical” customer surface. Use this composite to...

An AI product manager resume should show you can define valuable problems, decide when AI is the right tool, partner with technical teams, and ship responsibly. When I review these, I’m scanning for product judgment plus AI literacy—not a laundry list of model names. Here’s the structure, bullet frameworks, and generic examples I’d want you to adapt with your real experience. It complements our AI Product Manager cluster (how-to, skills,...

An AI product manager owns outcomes for products or features that rely on machine learning or generative AI. From what I’ve seen across startups and larger product orgs, a typical day still looks like product management—discovery, prioritization, shipping, communication—but with extra time on data quality, model evaluation, failure modes, and alignment with data science, ML eng, and risk/compliance partners. Exact calendars vary by company stage, whether you own a full...

When I help people prep for an AI product manager interview, I’m really testing one thing: can you ship AI-powered products responsibly? Clarify the user problem, decide when ML is the right tool, define success metrics, partner with data science and eng, and manage risk—without pretending you’re a research scientist. I’ve seen candidates freeze on evals and others drown in buzzwords. This guide is the frameworks I’d want you to...

AI product roles aren’t niche anymore. Job posts increasingly expect PMs to reason about model quality, data constraints, evaluation, ethics, and how AI features fit a broader product strategy. A good AI PM certification should teach that judgment—not just buzzwords. I’ve sat with enough candidates who “took an AI course” and still couldn’t explain an eval plan. So this comparison focuses on fit: learning format, topic coverage, portfolio potential, and...

“Technical Product Manager” means different things at different companies. Sometimes it’s a PM who owns infrastructure, APIs, or developer platforms. Sometimes it’s a PM who can go deep with engineers on architecture tradeoffs for a customer-facing product. In both cases, what I’ve seen employers care about is the same core: product judgment plus technical fluency—not a CS degree as a magic ticket. Here’s how I’d break down what hiring managers...

If you’re comparing affordable online paths into product management, two names come up a lot: Product HQ’s certification tracks and the IBM Product Manager Professional Certificate on Coursera. I’ve talked through this comparison with a lot of beginners. Both can work. They just optimize for different things. I’ll be upfront: I run Product HQ. I’ll also be fair about what IBM on Coursera does well. What each program is Coursera:...

People ask me all the time: Product HQ or Product School? I don’t think there’s a universal winner. There’s a better fit for your schedule, depth needs, and how you actually learn. I run Product HQ, so I’ll be transparent about that. I’ll also be fair—Product School is a real brand with a real format advantage for some learners. Here’s how I’d decide if I were picking for myself. Quick...

If you’re switching into product management, I wouldn’t start by collecting badges. I’d build a believable bridge: transferable experience → PM skills → proof → interviews. A certification can be one beam in that bridge—if you choose it on purpose. I’ve watched a lot of switchers buy the loudest brand, skip projects, then wonder why interviews still feel impossible. This is the checklist I’d use instead. Step 0: Confirm PM...

I’ve gotten this question more times than I can count while running Product HQ and teaching PMs: is a product management certification actually worth it? PM still has no universal license. Plenty of great PMs never bought a course. So if you’re staring at a checkout page wondering whether you’re about to waste money, you’re not being cynical—you’re being smart. My take: a cert can be worth it when it...