Chapter 6 Do you like the work?

Architect? didn’t ask whether you were smart enough to be an architect. It asked whether you liked what architects actually do all day.

Same question here.

You’ve seen the job: three questions that never resolve 1, traits that matter more now that scaffolding is cheap 2, mental moves that define how PMs think 3, the peer relationships that determine whether anything ships 4, and what the craft looks like when the tools are free 5.

Now we stop describing. We test.

This chapter is six exercises. They are not hypothetical. Each one asks you to do something — write a document, have a conversation, make a call, spend a week differently. Do them. The feeling you have during and after each one is the data.

There is no score. There is no pass. “I hated this” is as useful as “I couldn’t stop.” Both tell you something the job description doesn’t.


6.1 Exercise 1: The Inbox

The scenario:

It’s 8am. You open your laptop. In the past twelve hours:

  • Your CEO sent a Slack asking for a competitive analysis by noon — a major competitor just announced something.
  • Your lead engineer sent a message saying the sprint is blocked: they need a decision on whether to keep or cut Feature X, which has a technical dependency that’s become a problem. They need it in the next hour.
  • A customer success rep marked a support ticket “urgent” — a high-value customer is frustrated by a behavior in the product that is technically working as designed but is clearly wrong for this user’s workflow.
  • Marketing left a message asking you to join a “quick thirty minutes” today to align on the Q3 launch messaging.

You have ninety minutes before your first meeting. You can make meaningful progress on one of these. Maybe two.

Do this: Write down, right now, what you do first and why. Not what you think a PM “should” do. What you would actually do.

Then write down how you feel about the other three things sitting unresolved while you work on the first one.

What it tells you:

If you felt energized by the triage — if the act of sorting priorities and picking the most important thing felt like a puzzle you wanted to solve — that’s signal. The inbox is every morning. It does not simplify. Most PMs find their triage instinct gets sharper with experience. But the base level of tolerance for a constantly replenishing queue of competing demands is something you either have or you don’t.

If you felt dread — if the scenario made you want to clear everything before starting anything, or to ask someone else to make the call on which thing matters most — that’s also signal. Some people need a defined problem and clean space to work. Product management, especially at a startup or scale-up, does not provide that. The inbox is the job. The “real work” happens in the gaps between the inbox items.


6.2 Exercise 2: The No

The scenario:

Your team has been asked to build something. Maybe it’s a feature a large customer requested. Maybe it’s an internal stakeholder’s pet project. Maybe it’s something your CEO mentioned offhand that has since taken on a life of its own. You believe — based on what you know about the product, the users, and the priorities — that building it this quarter is the wrong call.

Do this: Write the document that says no.

One page. Real. These are the components:

  • What you’re saying no to, described fairly — not a strawman version of the request.
  • Why the person or team asking wants it (their actual motivation, not your interpretation of their bad judgment).
  • Why it’s the wrong call right now — not in general, specifically for this quarter, with these resources, against these alternatives.
  • What you would do instead, or when you’d revisit.

Then send it to someone who would want the thing you said no to. Not for their approval. For their reaction.

What it tells you:

If you found yourself enjoying the construction of the argument — if writing the case for “no” felt like solving a puzzle, a chance to be precise and right — that’s signal. PMs write “no” more than they write “yes.” The document is not actually the hard part. The hard part is the conversation that follows when the person you said no to pushes back, and you have to hold the position without becoming defensive or caving.

If you felt uncomfortable writing the doc — if you found yourself softening the “no” into a “not now” into a “maybe” into “let’s revisit” before you even sent it — that’s signal. Some people find that holding a position against resistance takes more out of them than it returns. That’s not a character flaw. It’s a job fit question.


6.3 Exercise 3: The Room

The scenario:

You are in a meeting. Multiple people with different perspectives are in the room — or the call. There is a real disagreement underneath the surface, but no one is naming it directly. Everyone is being professional. The meeting has fifteen minutes left and is heading toward a false consensus — an agreement that everyone will nod at and then immediately walk away from with different interpretations.

Do this: In your next meeting where this is true, say the thing no one is saying. Not to be provocative. Because the team needs someone to name it before they waste two weeks executing on a misalignment.

After the meeting, write two sentences: What did you say? How did it land?

Then write one more: How did you feel in the ten seconds before you said it?

What it tells you:

Conflict navigation 2 is not about liking confrontation. It is about tolerating the discomfort of naming the real thing when it is easier to let the meeting end with ambiguity intact.

If saying it felt like relief — if you experienced the naming of the disagreement as a weight lifted — that’s signal. PMs who surface conflict early protect their teams from executing in the wrong direction. They’re often unpopular in the moment and thanked later.

If you couldn’t do it — if you waited and the meeting ended with the misalignment unnamed — that’s also signal. Ask yourself what stopped you. Fear of the reaction? Not knowing how to say it? Uncertainty about whether you were right? Each of those has a different implication.

Some excellent PMs delegate this to their managers or their strongest engineering partner. That works until there’s a decision only you can make, and the misalignment underneath it has been accumulating for a quarter.


6.4 Exercise 4: The Story

The scenario:

You are going to explain your current project — or your most recent one if you’re between projects — to someone outside your field. A family member. A friend in a completely different industry. Someone who has no obligation to care and no professional reason to nod along.

Do this: Explain it in two minutes. Out loud. Not in writing — out loud, to a real person.

These are the constraints: - No jargon. No “we’re building a platform.” No “we’re optimizing the funnel.” No “AI-native.” - You have to explain the problem before you explain the solution. - You have to explain who has the problem before you explain the problem.

When you’re done, write down: Did they ask a follow-up question? Or did they change the subject?

What it tells you:

Narrative gravity 2 is the trait that most determines whether a team will follow you through uncertainty. AI gives you unlimited words. It cannot give you conviction, and it cannot give you the clarity that produces conviction.

If they asked a follow-up question — if something in your explanation hooked their curiosity — you found the story. That’s the version you want in every doc, every deck, every new employee orientation, every press pitch.

If they changed the subject — if your explanation was technically accurate but created no pull — you haven’t found the story yet. That’s fine. It usually takes more tries. The exercise is finding it, not performing it. Try again with a different angle. The story is in there. It’s usually closer to “who has the problem and why does it matter” than to “what we’re building.”


6.5 Exercise 5: The Call

The scenario:

There is a decision on your current project — or on a project you’ve observed — that has been in a holding pattern. More information is being gathered. Another stakeholder needs to weigh in. The conditions aren’t quite right yet.

Do this: Make the decision today. Not because you’re confident. Because you’ve identified that the real barrier is not missing information — it’s discomfort with uncertainty.

Before you make it, write down: What is the minimum information you actually need to make this call? (Not “feel ready to make this call.”) What is the cost of waiting another week versus deciding now?

After you make it: Write two sentences about how it felt. Not whether it was right. How it felt.

What it tells you:

The PM role requires tolerance for making consequential decisions at 60% confidence and executing as though it were 90%, while remaining genuinely willing to update when the evidence comes in. That tolerance is not a skill you can acquire. It is a disposition you either have or you are building toward.

If making the call felt like relief — if the act of deciding, even under uncertainty, gave you energy rather than draining it — that’s signal. Good PMs have a bias toward resolution. They find ambiguity uncomfortable in a productive way: not paralyzing, but motivating.

If the decision still felt premature — if your instinct was to gather one more input before committing — examine what input you’re actually waiting for. Sometimes it’s real. Often it’s the feeling of readiness, which the data will never fully provide.


6.6 Exercise 6: The Week

The scenario:

You are going to look at a PM’s actual calendar.

If you know a PM, ask them to share one week’s view — not their best week, not their worst week, a representative week. If you don’t know one, ask in a community or on LinkedIn. Most working PMs will share this.

Do this: Look at the calendar. Count the hours in each category:

  • Meetings with engineering (planning, refinement, unblocking)
  • Meetings with design (review, feedback, direction)
  • Meetings with stakeholders (alignment, updates, escalations)
  • Time with data (reviewing experiments, checking metrics, investigating anomalies)
  • Time actually writing (docs, specs, one-pagers)
  • Time actually thinking (no meeting, no Slack, just thinking)

Then block your own calendar to match that week. Actually do the week that way.

At the end of the week, write three sentences: What energized you? What drained you? What did you miss?

What it tells you:

The calendar is the job. The docs, the frameworks, the strategic narratives — those are produced in the hours between the calendar items, often late, often under time pressure from the next calendar item.

If the week felt like the week you want — if the mix of meetings, decisions, relationships, and occasional windows to actually think felt right — that’s meaningful. The PM calendar does not simplify with seniority. It shifts. The meetings become more consequential, the windows to think get harder to protect. If the structure of the week felt energizing at the entry level, it probably stays that way.

If the week felt wrong — if you spent the whole time wishing you could be heads-down on one thing instead of across ten things — that’s also useful. The job is the week. Not the outcomes of the week. The daily lived structure of it.


6.7 What to do with the results

There is no formula. You did six exercises. Some felt right. Some didn’t.

If four or more felt energizing — if most of the exercises produced the feeling of “yes, this is the kind of problem I want to spend my time on” — keep reading. Chapter 7 is about how to get in.

If three or more produced dread or flatness — if the exercises revealed a disposition better suited to adjacent work — also keep reading. Chapter 7 covers the paths out too. Architect? didn’t tell people who concluded architecture wasn’t for them that they’d made the wrong call. It gave them a map of where else their instincts might fit. Same here.

If you’re split — two or three in each direction — that’s the most honest answer of all. The job has hard parts and good parts and how you weight them depends on what context you’re in. Chapter 7 can help you find the context where the ratio works for you.

The self-diagnostic isn’t a test. It’s calibration. The job is the exercise. Pick the one that stuck.