JOIN PHQ

On Product HQ, I publish a lot more than “What does a product manager do?” career pages.

I also write tutorials, explainers, frameworks, and career prep guides that help you do the work, talk about the work, and get hired to do the work. This methodology page explains how I research, write, and maintain those educational articles so you can trust what you’re reading and see the standards behind it.

What’s included on this page:

What these educational articles are for

I write educational content for people who need practical answers, not vague definitions.

That includes product people who:

  • Explore a role and try to understand what product management looks like in real life
  • Transition into product management and build a plan
  • Level up and try to improve craft, judgment, and product outcomes
  • Hire and try to define the role, scope, and expectations

Across all these articles, I’m trying to reduce confusion and help you take the next step with more confidence.

How I research each topic

Even though the topics vary, I use a consistent research approach so articles stay comparable across the site.

Define the scope first

I start by defining what the article will and will not cover. This matters because many topics in product management can sprawl—discovery, strategy, prioritization, delivery, and career advice often bleed into each other.

  • Audience: Who this is for and what problem it solves
  • Boundaries: What is in scope and what belongs in a separate guide
  • Context: Where the concept applies (startup vs. enterprise, B2B vs. consumer, platform vs. feature team) and where it does not
  • Vocabulary: What terms need definitions to avoid misunderstandings

Use primary sources when possible

When the topic involves tools, frameworks, or workflows, I prioritize sources that are closest to the truth.

  • Product documentation: Official docs, release notes, plan limits, and support pages for PM tools and platforms
  • Standards and frameworks: When a concept has a formal reference point (for example, discovery methods, prioritization models, or research practices)
  • First-hand workflow testing: When the best way to understand is to run the process—write the brief, run the interview plan, or stress-test a prioritization approach

Add market reality

For career-focused articles, I look for what employers and teams expect right now.

  • Job postings: Patterns in responsibilities, required skills, and common tools
  • Title variance: How the same work shows up under different role names (APM, PM, TPM, GPM, and so on)
  • Seniority signals: How expectations change as scope increases

Add practitioner reality

A lot of educational content fails because it stops at theory. I try to include what people run into when they do the work.

  • Friction: What tends to trip people up (stakeholder alignment, ambiguous goals, weak discovery)
  • Tradeoffs: What you gain and what you give up with a choice
  • Practical examples: What “good” looks like in a real product workflow

When I share perspective, I frame it as experience and patterns, not universal law. Context matters in product work, and I say so when advice depends on it.

How I validate accuracy

Educational content is tricky because details change and contexts vary. To keep things grounded, I use a few guardrails.

  • Pattern-based claims: Prefer repeated evidence over single anecdotes
  • Conservative language: Use “often” and “typically” when variability is real
  • Clear scope: Separate “common” from “situational” from “edge case”
  • Fact-checking: Verify claims that can be verified (especially tooling, definitions, and process steps)

If something is uncertain, I’d rather tell you it varies than pretend it is fixed.

How I write for clarity and usefulness

I write these articles to be skimmable first and detailed second. Most readers land on a page with one question in mind.

So I focus on:

  • Definitions that reduce confusion, not inflate it
  • Sections that match how people think (What it is, Why it matters, How to do it)
  • Examples and checklists that help
  • Practical next steps (what to learn, what to practice, what to avoid)

If a topic needs more depth, I’d rather create a second article than cram everything into one page.

How I keep articles updated

Educational content goes stale when tooling, hiring expectations, and common workflows shift. I update articles when:

  • Tools: A platform changes plans, features, or positioning in a way that affects recommendations
  • Workflows: Common approaches shift (for example, how teams run discovery, roadmapping, or AI-assisted product work)
  • Career signals: Job postings show a meaningful change in expectations
  • Clarity issues: A section becomes misleading based on how product teams work now

My goal is consistency across the library so you can move between related topics without having to relearn the format each time.

Editorial standards and corrections

I treat Product HQ educational content like documentation.

  • Clarity: Define terms and avoid jargon when simpler language works
  • Accuracy: Fact-check claims that can be verified
  • Utility: Prioritize actions and decisions over theory
  • Transparency: Separate facts, trends, and opinions

These habits sit alongside our broader site promises on the editorial standards page. For more on who we are and how Product HQ is built, see About us.

If you spot an issue, I want to fix it. Corrections also help me improve the process so that the same issue is less likely to occur again.