Working With a Product Manager
The PM owns the why and the priority; you bring the cost curve, the smaller version and the question behind the ticket — and when there is no PM, you say out loud which of their jobs you are now doing.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
What does an engineer bring to a product manager that the PM cannot get from anyone else?
The PM posts in the team channel: "Customers keep asking to save their cart for later. Can we get this into the next sprint?"
Estimate it, flag the technical risks, and build what the PM asked for. The PM owns the product, engineering owns the how. It is a clean division of labour and it keeps everyone out of each other's way.
The estimate is for the PM's solution, not the problem. "Save cart for later" can mean a wishlist, a cart that survives across devices, or a reminder email — three very different costs — and nobody asked which problem the customers actually have.
- The estimate is for the PM's solution, not the problem. "Save cart for later" can mean a wishlist, a cart that survives across devices, or a reminder email — three very different costs — and nobody asked which problem the customers actually have.
- The PM wrote the ticket with the information they had. You know the cart is already stored server-side for logged-in customers, which makes a cheap version possible. That knowledge dies inside a five-point estimate if you do not say it.
- "Engineering owns the how" slides into "engineering has no opinion on the what". The PM makes scope calls without knowing what each part costs, and the expensive part ships because nobody said it was most of the cost.
- When the PM is on leave, or the team has none, the work either stalls or an engineer quietly does discovery on top of the sprint. Nobody sees it, and it surfaces as "why is this late?"
What is really going on
- A PM holds the why and the priority: which problem, for which customers, why now, and what it beats on the list. What they rarely hold is the cost curve — which parts of a solution are cheap and which parts are expensive, and why.
- The engineer holds the cost curve and the system's memory: what already exists, what is risky, which part is two days and which part is two weeks. A good product decision needs both halves; a ticket carries neither.
- The most useful thing you can hand a PM is a smaller version with a price and a lesson attached: "Keeping the cart for logged-in customers is two days because the data is already there. Guests across devices is two weeks because we would have to identify them first." That turns an estimate into a decision.
- Trust with a PM is built on predictability and on never making them wrong in public. The challenge happens one-to-one and arrives with an alternative; the planning meeting sees the options you agreed to present together.
- With no PM, the PM's jobs do not disappear — talking to customers, choosing priority, saying no. Somebody does them. Naming who, and for how long, is what stops the work from being invisible.
The ticket is the PM's best guess
The PM heard something — a support pattern, a sales call, a line in a survey — and wrote down a solution. That is their job, and they did it with the information they had. What they did not have is the inside of the system: that the cart is already persisted for logged-in customers, that guests are identified only by a cookie, that a reminder email would need a consent check.
Your first move is not an estimate. It is getting the problem back out of the ticket, and doing it in a way that sounds like help rather than an audit.
The PM posts "Customers want to save their cart for later — can we get this in next sprint?" in the channel and tags you.
"Sure, probably five points. Do we need it for guests too? That is a lot more work."
"Happy to. Before I size it — do you know what customers said exactly? If they mean 'my cart was gone when I came back', we can keep it for logged-in customers in about two days because it is already stored. If they mean 'I want a list for later', that is a wishlist and a different thing. Can we take ten minutes today?"
Bring the cost curve, not a number
An estimate is one number for one shape. A cost curve says where the cost lives, which is what a PM can actually trade against. Most features have one part that carries most of the cost and most of the risk; the PM cannot cut it if they do not know which part it is.
Saved cart: 8 points. Risk: medium.
Saved cart for logged-in customers: 2 days, the data already exists. Saved cart for guests across devices: about 2 weeks, we would need to match a guest to a later visit, and that touches the privacy notice. Reminder email: 3 days plus a consent check with legal.
The first gives the PM a number to accept or haggle over. The second gives them three decisions, with the expensive one isolated, so they can choose the order and the size themselves.
Disagree in private, align in public
The planning meeting is where a PM is most exposed: their lead is there, other teams are there, and changing their mind in that room costs them something. The day before is where they can change their mind for free.
The rule is not "never disagree in the meeting". It is "never let the meeting be the first time they hear it".
The PM has put guest cross-device carts at the top of next sprint. You think the logged-in version should go first. Planning is tomorrow.
In planning, in front of the PM's lead: "I am not sure guests is the right priority — have we validated that?"
One-to-one, the afternoon before: "Could I suggest an order for tomorrow? If we ship the logged-in version first, in two days we will know how many people come back to a saved cart. If almost nobody does, we have saved two weeks on guests. If lots do, guests goes next with a real number behind it. Happy to present it as your call either way."
When there is no PM
Plenty of teams have no PM, or share one so thinly that it amounts to none. The jobs are still there: someone reads the support queue, someone chooses what goes first, someone says no to the finance request that would eat a month. When nobody names who, engineers do it in the gaps and it shows up as lateness.
The team has no PM this quarter. How do the product jobs get done?
when Never as a plan; it is what happens by default.
cost Discovery happens on top of the sprint, estimates look wrong, and the person doing it burns out unseen.
when Most teams without a PM for more than a few weeks.
cost Engineering capacity visibly drops, which is honest but has to be defended to whoever set the sprint goals.
when When priority calls keep stalling or bouncing between people.
cost Someone outside the team — often the engineering lead — takes calls they have less context for, so they need the cost curve in writing.
1## Product work this sprint (no PM)2 3- **Support triage for checkout** — Priya, ~half a day a week4- **Talking to finance about the refund report** — me, one call5- **Priority calls** — engineering lead has the final say; we bring options6 7This is why planned capacity is lower than usual. We will revisit when a PM joins.It turns invisible work into planned work, and it says who can overrule whom before anyone needs to.
How to do it
Most important first.
- Ask for the problem before you estimate: "What did customers actually say, and roughly how many said it?" (Problem Before Solution).
- Bring the cost curve in one or two sentences, not a spreadsheet: which part is cheap, which part is expensive, and the reason (The Cost of a Feature).
- Offer the smaller version with its price and what it would teach: "Two days, and we would find out whether anyone comes back to a saved cart at all" (The First Version That Teaches You Something).
- Propose how you will both know it worked. Most PMs welcome an engineer who suggests the signal instead of waiting to be told (Picking a Metric That Moves When the Product Gets Better).
- Disagree one-to-one first and bring an alternative; in the room, present the options you agreed on.
- With no PM, write down which PM jobs you are covering this sprint and ask who holds the final call on priority. Then put those jobs in planning as named work.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead by playing the problem back: "So the goal is that people who leave before paying come back and finish the order — is that right?" It confirms you listened and lets them correct you cheaply.
- Then the cost curve in one sentence: "The cheap part is keeping the cart for logged-in customers. The expensive part is guests on a second device."
- Then the option and what it buys: "I would ship the logged-in version first, see how many come back to it, and decide on guests with that number in hand."
- Close with what you need from them: "Could you check with support how many of these requests come from guests? That decides whether the expensive part matters."
- When there is no PM, say it to your lead in plain words: "There is no PM on this, so I spent Tuesday reading support tickets to find the real problem. That is why the estimate moved. I would like that to be a named part of someone's week."
- "Just give me an estimate, I do not need options." Fair: five days for the full thing. I mention the two-day version because it tells us whether anyone uses saved carts, and the five-day version depends on that answer too.
- "That is product's call, not yours." Agreed, and it stays yours. I am giving you the price of each part so the call is informed; I will build whichever you choose.
- "We do not have time for discovery." Then let us pick the version that is cheapest to be wrong about.
What can go wrong
- Becoming a second PM: rewriting every ticket, reopening prioritisation weekly, making the PM defend decisions they are accountable for.
- Offering the smaller version so often that it reads as "engineering always wants to do less". Offer it when the cost curve is steep, not as a reflex.
- Deferring completely: estimating whatever arrives and then saying in the retro that the roadmap was wrong. The retro is the most expensive place to have the opinion.
- The no-PM version: choosing priorities by what is technically interesting and calling it product judgement.
- "The PM decides what, I decide how." The how changes the what: the price of each part is a product input, and only you know it.
- "If I disagree with the priority, I should say so in planning." In front of the room is where a PM is least able to change their mind. Say it the day before.
- "No PM means I am the PM now." It means some PM jobs need doing. Say which ones you are doing, for how long, and who can overrule you (Disagree and Commit).
Knowing whether it worked
- The PM starts bringing you problems before the ticket is written, not after.
- Tickets arrive with a line saying why they exist, and estimates stop being haggled over because the options were priced together.
- "We built it and it was not what I meant" stops appearing in retros.
- Without a PM: discovery work appears in planning as named items rather than as unexplained lateness.
- One PM per team makes this a daily conversation. One PM across three teams has no time to decompress tickets, and the engineer who does it becomes load-bearing — which should be acknowledged, not assumed.
- In a large organisation PMs negotiate with other PMs, and your cost curve becomes the argument they carry into that room. It has to be written down to travel (The One-Pager).
- The core does not change with size: the problem, the cost, the smaller version, the signal. What changes is how much of it has to be in writing.
- Asking for the problem and pricing options takes longer than estimating what arrived, and sometimes the ticket was exactly right.
- Proposing the smaller version means sharing the outcome. If it turns out too small, it was partly your call.
- Some PMs experience it as interference at first. There is a relationship cost before there is a relationship benefit.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- TEAM-SPECIFICWith a dedicated PM this is a partnership where you lead on cost and signals. With one PM across several teams you do more of the decompressing yourself. With no PM at all the jobs land on engineers and must be named as work, not absorbed.
- ROLE-SPECIFICA junior engineer contributes by asking for the problem and pricing the parts; the priority call sits with the PM. A senior engineer is expected to propose the options and share the scope call, and is held to the outcome alongside the PM.