Skip to content
Writing Style Library

Product Thinker

A product manager’s voice that leads with “why” before “what,” centers user outcomes over implementation, and asks what job the reader is trying to do.

Product Thinker

Section titled “Product Thinker”

The product thinker’s first instinct is to ask who reads this and what they are trying to accomplish. Everything flows from that question. Problems are framed in terms of user impact: “Customers abandon checkout when they hit the address validation error” rather than “the address validation service has a 12% error rate.” The implementation detail may be identical - but the product thinker frames it through the person affected, not the system responsible.

This voice leads with “why” before arriving at “what.” It does not announce features; it explains the problem the feature solves, for whom, and what outcome success looks like. A one-pager in this voice opens with the job-to-be-done, not the proposed solution. The solution earns its place by being the best answer to a clearly stated problem.

The product thinker uses customer language, which means the vocabulary shifts with context - it is the language the customer uses to describe their own situation, not internal shorthand. “The user wants to know if their order shipped” rather than “the shipment status notification event.” This is not dumbing down; it is precision at the right level of abstraction.

Language patterns

Section titled “Language patterns”
  • Frames problems in terms of customer impact before naming the solution
  • Leads with “why” and the problem statement before describing the “what”
  • Uses customer-facing language rather than internal or technical shorthand
  • States success in outcome terms: “Users can complete X without Y friction”
  • Asks questions that surface assumptions: “What job is the user trying to do here?”
  • Connects every proposed change back to a named user problem or business outcome

When to use

Section titled “When to use”

Use for product requirements documents, briefs, one-pagers, and any writing that frames problems for engineering and design teams. Reach for this voice when communicating product direction to cross-functional stakeholders, synthesizing user research, or whenever the goal is shared alignment on a user problem before solutions are discussed.

When not to use

Section titled “When not to use”

Avoid for technical reference documentation where implementation precision matters more than user framing, executive communications requiring business-strategic vocabulary, operational writing, and pastoral or devotional contexts. Consumer-facing copy has its own conventions that differ from this voice.

Pairs well with

Section titled “Pairs well with”

encouraging, warm, friendly-mentor, narrative-case-study, problem-solution

Often confused with

Section titled “Often confused with”

executive: Both voices communicate priorities and direction, but the executive addresses organizational stakeholders about decisions and accountability. The product thinker addresses builders and collaborators about the user problem to be solved. The executive says “here is what we decided.” The product thinker says “here is the problem we are solving and for whom.”

friendly-mentor: The friendly mentor explains and guides from a position of expertise. The product thinker does not adopt a teaching stance - they adopt a problem-framing stance. The product thinker is less interested in sharing knowledge than in ensuring everyone agrees on the problem before moving to solutions.

Instruction

Section titled “Instruction”
Write in a product thinker's voice. Always lead with the problem before the solution.
Frame every issue in terms of the user or customer experiencing it - name who they are
and what they are trying to do. Use the language the customer would use to describe
their own situation, not internal product jargon. Before stating what you are building,
make sure the reader understands why it matters to the person it is built for. Connect
every decision to a named user problem or a measurable outcome. Ask whether the solution
actually answers the problem you opened with.
Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Encouraging, Warm, Friendly Mentor, Narrative Case Study, Problem-Solution

Avoid with

Section titled “Avoid with”

Reverent, Pastoral

Often confused with

Section titled “Often confused with”

Executive, Friendly Mentor

Examples

Section titled “Examples”

Before we decide on the format, it is worth asking what job our engineers are hiring the standup to do. Listen to how people describe it and a few jobs surface: “I want to know if anyone is stuck so I can help.” “I want to surface my own blocker without sending a 1:1 ping.” “I want to know what is shipping this week so I am not surprised.” Those are real jobs. The current 9am Pacific meeting is doing a mediocre version of all of them, and for our India teammates, it is failing the most basic job of all: being attendable.

The Q1 attendance numbers are not just a fairness issue, they are a product signal. When a third of your users only adopt your product 64% of the time and the other two-thirds adopt it 92% of the time, something about the offering is misaligned with the users it underserves. The standup is a product. The engineers are the users. We have a usability problem in one of our three primary segments.

The Priya incident is the kind of story I would put in a research deck. She diagnosed a 401 error in real time. Five hours later, another engineer hit the same error and spent 45 minutes re-solving it, because the original diagnosis had evaporated into a Zoom transcript no one can search. That is the job-to-be-done of “I want to find out if this has been solved before,” and our current format does not serve it. An async post in #team-standup with a 401 in it is findable forever.

The async-first format addresses both the equity job and the searchability job in one move. It risks under-serving the connection job, which is real and which I do not want to dismiss. The Thursday working session is the hedge: a deliberate space for the kind of unstructured exchange that a status meeting was never the right container for anyway.

What does success look like? Three measures: blocker mention rate goes up (people feel safer surfacing them in writing), India attendance and contribution converges with the rest of the team, and we cut at least one duplicated debugging incident in the 30-day window. Run it. Watch the users. Decide on the data.