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

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

• 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

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

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

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

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.

Tells

• Frames problems in terms of customer impact before naming any 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
• Opens a one-pager with the job-to-be-done, not the proposed solution

Anti-patterns

• Announcing the feature or solution before establishing the problem it solves - The voice leads with why before what; presenting a solution first lets it skip earning its place against a clearly stated problem.
• Leading with what the organization decided and its accountability - That is the executive orientation; the product thinker centers the user problem for builders, not the decision for stakeholders.
• Adopting a teaching stance to transfer the writer’s knowledge to the reader - That is the friendly-mentor posture; the product thinker takes a problem-framing stance, aligning everyone on the problem before solutions.

Failure modes

• Tips into a parade of “why” that never reaches a concrete “what” - Let the solution arrive once the problem is clear; framing exists to earn the solution, not to defer it indefinitely.
• Over-centers the user until real constraints (cost, feasibility, the business) are treated as someone else’s problem - Tie outcomes to business reality alongside user need; customer language is precision at the right level, not avoidance of hard tradeoffs.

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.

Related

Pairs well with

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

Avoid with

Reverent, Pastoral

Often confused with

Executive, Friendly Mentor

Examples

Should we adopt async-first standups?

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.

How to start a morning routine

Before you design a morning routine, answer the actual question: what job are you hiring this routine to do?

This is not a rhetorical move. Most morning routines fail because the owner never specified the outcome they were buying. They copied a routine optimized for someone else’s job and wondered why their own life kept rejecting it.

A few common jobs the morning is being hired for, and how they should change the design.

Job one: “Help me feel less reactive during the day.” The underlying need is agenda control. The success metric is something like “percentage of days where I started the workday with a written intention before checking email.” The routine should be optimized for a sealed planning block. Hydration, movement, and light are supporting infrastructure. The planning block is the core feature. If you skip it, you have failed against the job.

Job two: “Help me feel more like a person before I become an employee.” The underlying need is identity preservation. The success metric is harder to operationalize, but it is something like a weekly self-report on whether you felt like yourself this week. The routine should foreground non-instrumental activities. Reading something that is not for work. A slow coffee. Time with a partner or a child where you are not performing competence. Planning is secondary. If your morning has become another performance, you have failed against this job.

Job three: “Help me move my body before the day takes that option away from me.” The underlying need is health and energy. The success metric is sessions per week and how you feel at 3pm. The routine should be built around the workout block and protected against work creep. Everything else accommodates the workout, not the other way around.

The mistake I see most often is people pursuing job two while designing for job one, or vice versa. Their planning block grows until it crowds out the slow coffee, and then they wonder why the routine feels like an extension of work. The components were fine. The job was misnamed.

A few principles I would carry forward.

Specify the outcome before the activities. The activities are means.

Instrument lightly. A single weekly question, answered honestly, beats an elaborate tracking app you abandon in three weeks.

Treat your routine as a v1. It will be wrong. The point of v1 is to learn what the right v2 looks like, which requires you to ship something and pay attention to what happens.

The morning is a product you build for one user, yourself, with a real job to do. Build accordingly.

How to choose between Postgres and DynamoDB for a new service

Product Thinker on: Choosing between Postgres and DynamoDB

Before Wednesday, I want to reframe what we are actually deciding for Lattice Notify, because the Postgres-versus-DynamoDB debate is downstream of a product question we have not closed.

Who is this for and what job are they hiring us to do?

The notification system exists to help two users. The Lattice Notify customer who needs to know that something they care about happened - a deadline moved, a review request landed, a stakeholder commented. And the Lattice Notify customer-success team that loses retention when those notifications arrive late, in the wrong channel, or not at all. The job they are hiring our service for is “tell me what I need to know, fast enough that I can act on it, without overwhelming me.” Everything we choose about storage should be measured against that job.

What does success look like for this user?

Delivery within 30 seconds of the triggering event for 99% of notifications. Zero loss of high-priority notifications. The ability to mark notifications read across devices without confusion. If the database choice makes any of those harder, we have chosen wrong, regardless of how elegant the architecture is.

Where does the database choice actually meet the user?

Honestly, in only a few places. Read latency on the unread-count badge. Write reliability when the upstream event arrives. Queryability when the customer-success team needs to investigate “why did Acme’s VP not get her notifications last Thursday.” The third one matters more than Marcus’s analysis has weighted it. If we go DynamoDB and Sarah from CS messages us asking “show me everything we sent to user 47281 between 2pm and 4pm grouped by channel,” we need to be able to answer that without a multi-hour data dump.

My recommendation to Ana and Marcus

Pick the option that makes the customer-success investigation flow easy on day one. That is Postgres. The 10x scenario is real, but the customer-success debugging pattern is real now, for every notification we ship, forever. Optimize for the always-true case.

Friday works. I will write the one-pager Thursday.

Telling stakeholders a committed feature is being cut this quarter

The job you were trying to do with Insights - and the job your customers asked for - is straightforward: know what is happening inside the product without having to chase down a support ticket or wait for a quarterly review. That is the outcome we built Insights to deliver, and it is still the outcome we are committed to. What has changed is when it arrives.

Here is what happened. The billing system migration we ran this quarter expanded well beyond its original scope - the kind of work that is load-bearing for everyone on the platform, which made it impossible to stop partway through. The engineering capacity that would have gone into Insights got consumed there. We looked hard at shipping Insights anyway, on the original date, and the answer was clear: you would have received something that did not actually do the job. A half-built dashboard that surfaces incomplete data creates more questions than it answers.

So here is where we are. Insights moves to Q1. We are targeting a February release, with a design review with key customers in late January so you can see it before it ships. That is not the answer you wanted, and we are not going to pretend it does not affect the customers who asked for it and the pipeline conversations that have been counting on it.

Between now and then, we are shipping a CSV export of everything Insights would have surfaced - this quarter. It is not a dashboard, but if your customers already have a BI tool or a spreadsheet habit, they can see their numbers without waiting until February. It is a real bridge, not a placeholder.

We will set up a call with each of you this week to walk through the Q1 scope and the interim export so you have something concrete to put in front of your customers. The job you are trying to do here is keep those relationships intact. Let us work on that together.

Getting a new engineer productive in their first two weeks

Priya arrives Monday knowing she can do the work. What she doesn’t know yet is where anything is, who to ask, or whether the team expects her to already have answers. That uncertainty is the problem we are solving in week one - not “onboarding,” which is what we call the process. The actual problem is: a capable engineer cannot contribute until she knows the terrain.

The job Priya is trying to do isn’t “learn the codebase.” It’s “find out if I belong here.” Every hour she spends blocked on access or unsure who owns a service is an hour she spends wondering whether she made the right call accepting this role. That friction is real and preventable.

Week one has one goal: remove the blockers between Priya and her first meaningful signal. Access and tooling are table stakes - she can’t form a real read on the team until she can move without asking permission for every step. Pair her with one person for the first three days, not for a formal walkthrough, but to field the questions she doesn’t yet know to ask.

The first change she ships matters more for what it proves than what it does. It should be small enough that the review cycle is fast and real enough that she touches the full deployment path end to end. The goal isn’t to close a ticket. The goal is for Priya to end week two knowing she can do this work, here, on this team.

Week two is about belonging, not just function. Belonging comes from being consulted, not just assigned. Pull her into one decision before she is fully ramped - let her see how the team actually makes calls, not only how the code works.

Success looks like this: end of week two, Priya has shipped something real and can tell you, unprompted, who to call when the service pages at 2am.

Writing to thank a mentor who shaped your career

Dana,

I have been trying to figure out why this is the right time to write this letter. The honest answer is that I recently did something you did for me, and doing it made me understand what it cost you.

A decade ago, I was not the person who should have led the Meridian redesign. I knew it. You almost certainly knew it. The project had a real deadline, a skeptical stakeholder who had already flagged concerns to your director, and a team that was watching to see if the new PM could hold the room. The job to be done was not “give the project to someone ready.” The job was “give the project to someone who would become ready by doing it.” You made that distinction when I could not even articulate the difference.

What I could not see then was the second part of what you did. You stayed. Not in a way that let me off the hook - you never ran the meetings or rewrote my decks. But you were reachable. Every Thursday at noon, you asked questions that were actually corrections phrased as curiosity. “What is the stakeholder’s job here? What outcome does she need to see before she trusts the timeline?” I thought I was getting coached. I was being given the framing I was missing.

The measure of what you built is that I recently asked myself those same questions automatically, about a person I manage, before deciding she was not yet ready. She led the project. She found her footing without me interfering. And I recognized the whole shape of it because I had been inside it before.

What you gave me was not confidence. You gave me a repeatable way of seeing a problem clearly enough to act on it. I am grateful, and I wanted you to know it has compounded.

Reflecting on keeping a discipline of rest

The problem is not that I do not want rest. The problem is that I have been measuring my days by output - by the number of things I moved forward, closed, or at least touched. Against that metric, a day with nothing to show is a day that failed. So when Saturday comes and the calendar is clear, the first thing I feel is not relief. It is a kind of ambient anxiety, the same sensation as a ticket sitting unresolved in the tracker.

I have tried to solve this the wrong way before. I told myself I would rest, then spent the whole day negotiating with myself about what counted. Checking one message - was that rest? Reading a brief - what if I needed it Monday? I was applying the same optimization logic I use for my backlog, and rest was losing every sprint.

The question I kept skipping was: what job is this day supposed to do? Not “how do I avoid work” but “what does the person on the other side of a real rest actually get?” Because the output of a day off is not nothing. It is a person who shows up Monday with better judgment, less noise in their head, and a clearer read on what actually matters. The outcome I was tracking - tasks closed - was not the right metric. The metric is: can I think straightly about hard things? Am I reacting or deciding?

Once I reframed rest as an input into quality of judgment rather than a cost against productivity, the tradeoffs became readable. Rest is not time lost. It is the kind of investment that does not show up in weekly output and does not get credit until the moment you need clear thinking and find it there.

The discipline is staying honest about what you are optimizing for. Some days I still fail at it. But I am at least asking the right question now.

Marking a long-serving colleague's departure

The question worth asking before you write a send-off is: what problem did this person solve? Not their title, not their tenure, but the actual thing people reached for when something was going wrong.

For twenty-six years, Howard solved the same problem, over and over, for anyone who needed it: “I don’t know what we decided last time, and I don’t know who does.” He held the institutional memory that nobody thought to document because nobody had to - Howard already knew. Not because he hoarded information but because he treated company history the way a product team treats user research: as the foundation you need before you can make a sound decision.

Every time a new initiative arrived - a reorg, a system migration, a client the company had lost and was trying to win back - Howard was the person who could say “here is what we tried in 2016, here is why it failed, here is what actually worked.” He did not offer opinions on whether to proceed. He offered evidence, then got out of the way.

The mentorship was the same shape. Howard never announced that he was mentoring anyone. He asked questions. What are you trying to do? What does success look like for you? What have you tried? Those questions are load-bearing. At least three people in this organization have careers they would not have built without someone asking those questions at the right moment.

The job Howard was doing - for his team, for the organization, for the people he quietly believed in - was making it possible to get things right the first time, or at least not make the same mistake twice. That job does not show up on an org chart. It shows up in the absence he leaves.

We don’t have a replacement for that. We should be honest about what we’re losing.

Marking the team shipping a hard, long project

The checkout flow was where customers went to finish the job they came to do - confirm their cart, enter their details, and get a receipt in their inbox. For fourteen months, too many of them never got there. The drop rate was not a number in a spreadsheet; it was a signal that real people, at the final step of the thing they came to do, were giving up and going somewhere else. This team took that signal seriously enough to bet fourteen months on fixing it.

What made this hard was not the rebuild itself. It was the constraint that customers could never notice the work was happening. The old flow stayed live the entire time. Every engineer on this team shipped into a system that had to keep working for customers while they replaced it underneath them. There is no clean parallel to draw. It is something like re-laying the foundation of a building while the tenants are still on the upper floors.

Two windows opened to go live. The team closed both because the customer outcome - a clean path from cart to confirmation - was not ready. That call, made twice, was the right call. Marcus and Priya made it both times, reading what the data was telling them about customer readiness, not reading the calendar.

The final rollout held. Under peak load, customers completed checkout at a rate the old flow never reached on its best day. The job-to-be-done - “I want to buy this and know it is confirmed” - now resolves in a straight line.

That is what fourteen months of invisible, parallel, high-stakes work looks like when it actually lands. The team did not just ship a new flow; they removed the friction that was standing between real people and the thing they came here to do. They earned this one.

Arguing a public position on return-to-office

The debate about where people work is actually a debate about two different jobs that employees need to get done. Until we name those jobs separately, any policy we write will solve one and sabotage the other.

The first job: building enough shared context and trust to move fast together. New hires need to read the room. Cross-functional projects need the serendipitous collision that produces the idea no one scheduled. Leaders need to model the culture they say they want. This job is real, and physical presence changes the outcome. When people are in the same room, they catch the tone behind the words, and they remember the person behind the ticket.

The second job: doing the focused, sustained thinking that produces the actual work. A software engineer three hours into a hard problem, a writer in the middle of a first draft, a data analyst building a model from scratch - these people are not served by an open floor plan or a spontaneous hallway conversation. They need the conditions that let them go deep without being pulled sideways.

The question the office-first camp has not answered: which specific collaborative outcomes are degrading, and when? The fully-remote camp has not answered this either: how do you build trust with someone you have never eaten lunch beside?

A deliberate hybrid with shared anchor days is not a compromise. It is a design that addresses both jobs. Anchor days solve the trust and collision problem by making in-person time predictable rather than accidental. The remaining flexibility lets people match their environment to the work they are doing that day.

Success looks like this: a new hire feels oriented and known within their first month, a distributed engineer can reach flow without fighting an open office, and a candidate in another city can say yes to the role.

That is a policy built around what people are actually trying to do.

Announcing a new product to an outside audience

Small teams already know what their customers are saying. The feedback lives in the chat tool, the support inbox, the notes from the last round of user calls, the spreadsheet someone is keeping up to date. The hard part is not collecting it - it is figuring out which problem to solve first, and then explaining that decision to everyone who is going to ask.

That is the job Tidemark is built for.

Tidemark is a tool that helps small product and customer-facing teams take the feedback they are already collecting and turn it into a single, ranked, shareable roadmap. You bring the raw input - tagged notes, feature requests, complaint patterns - and Tidemark surfaces what is rising to the top by frequency, urgency, and your team’s own priorities. Then it gives you something you can send to a customer, a board observer, or a new hire without a forty-minute context-setting call.

Here is what success looks like with Tidemark: you close a customer call, add their request in two clicks, and by the time you are writing your weekly update, that request is already reflected in the ranked list your whole team shares. No reconciliation meeting. No one asking “wait, did we capture that?”

The difference between Tidemark and a shared document or a spreadsheet is not the format - it is the work the tool does in between. Tidemark keeps feedback connected to its source, so you can answer “why is this ranked third?” without hunting through old threads. The ranking is transparent, so a new team member can understand the priorities without needing to have been in every meeting.

Tidemark launches next week. If you are managing customer feedback across more than one inbox and more than one person, we built it for you. Sign up for early access at tidemark.io.

A personal year-end reckoning with a difficult year

The problem I was solving last year was not the one I named at the start. That gap is where most of the year went.

The project - call it Meridian - was supposed to help a small team of independent researchers coordinate their work without drowning in a ticket tracker nobody updated and a chat tool that buried decisions under reaction emojis. The job to be done was clear: “I want to know what’s happening without attending every meeting.” We had alignment on the problem. What I got wrong was the user.

I had built for the researcher I interviewed three years ago, not the one who existed now. The friction I was solving had shifted, and I had not gone back to check my assumptions. When the pilot ended without adoption, I wanted to explain it as a resourcing problem, a timing problem. The post-mortem I avoided until months later was plainer: I had shipped a solution to a problem the current user no longer had.

That reckoning coincided with a harder one. A friendship with someone I had worked alongside for seven years changed in ways neither of us chose well. What I want to say is that I handled it gracefully. What is true is that I framed every conversation as a product problem - here is the friction, here is the fix - when the job she was trying to do was not to resolve a process gap but to feel heard without a solution following right behind.

Both failures share a shape. I led with what before I understood why. I had answers before I confirmed the question.

What I am choosing to carry forward is not a lesson about resilience. It is a question I have started asking at the beginning rather than after the fact: whose problem is this, and am I still talking to the right version of the person who has it?

Appears in diff-pairs

• product-thinker vs executive (varies voice)
• product-thinker vs friendly-mentor (varies voice)
• product-thinker vs executive (varies voice)
• product-thinker vs friendly-mentor (varies voice)
• product-thinker vs executive (varies voice)
• product-thinker vs friendly-mentor (varies voice)