Problem Before Solution
Every ticket arrives with the solution already chosen. Decompress it into the problem, the people, the evidence, the change and the smallest test before you estimate a single line.
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 problem is this ticket solving, and how would we know if something smaller solved it?
A ticket lands in the sprint: "Add a save-for-later button to the cart." The PM says it came from a customer call, and marketing wants it live before the spring sale.
The ask is clear and not very big. Build the button, a saved-items list and a move-back-to-cart action, estimate it honestly, and ship it before the sale.
The button ships and nobody wrote down why it existed, so nobody can say whether it worked. Three months later someone asks "do people use save-for-later?" and the only answer is a click count that means nothing without the problem it was meant to solve.
- The button ships and nobody wrote down why it existed, so nobody can say whether it worked. Three months later someone asks "do people use save-for-later?" and the only answer is a click count that means nothing without the problem it was meant to solve.
- The customer call was one shopper who saw the shipping cost at the last step, left, and came back to an empty cart. The problems were surprise at checkout and a lost cart. Save-for-later treats neither, and abandonment does not move.
- Scope grows by solution-thinking: sharing the saved list, price-drop alerts, a wishlist page. Each addition is reasonable once the solution is fixed, and none is checked against a problem because there never was one written down.
- Refinement spends twenty minutes on whether saved items live in a table or in the session, and no minutes on who is saving what, or why.
What is really going on
- A solution is easier to discuss than a problem because a solution has edges: you can draw a button, estimate it and demo it. So every step between the customer call and the ticket nudges the description towards the solution, and every meeting afterwards talks about the thing with edges.
- The person who wrote the ticket chose the solution with the least information anyone will have — before design, before the data was pulled, before an engineer said what the system already does. The engineer building it will know more about cost than anyone else in the room.
- The five questions from What a Product Engineer Actually Is each remove a class of waste. *For whom* stops you building for "users". *How do we know it is real* stops you building for one anecdote. *What changes* gives you a signal. *What is the smallest thing* gives you a cheaper first version.
- A problem statement is testable; a solution is not. "Shoppers drop off when shipping appears at the last step" can be checked against the funnel this afternoon. "Add save-for-later" can only be built.
- Anchoring: once a solution is on the table, every alternative is judged against it rather than against the problem. Writing the problem down first, in words that do not name a feature, is the cheapest way out of the anchor.
The solution arrives first
By the time a ticket reaches the board, the problem has usually been compressed out of it. "Add a save-for-later button to the cart" records what someone decided to build. It does not record the call, the shopper on it, or what she was trying to do when she gave up.
That is not carelessness. Solutions have edges and problems do not, so each hand-off between the call and the ticket moves the words a little further towards the thing that can be estimated. The engineer is the last person who can cheaply ask what the edges are for — and the first person who knows what the alternatives would cost.
Decompressing save-for-later, out loud
The five questions take about as long as the estimate discussion they replace. Here they are on the save-for-later ticket, in the order they are usually useful.
- What problem? "Returning shoppers lose their cart and do not come back." No feature in the sentence.
- For whom? A shopper on mobile who adds items, sees the total, and leaves to think about it.
- How do we know it is real? One call so far. The funnel can say whether it is a pattern: pull the cart-to-checkout drop-off before refinement.
- What changes if we solve it? More returning shoppers reach checkout with the cart they built. Countable per week.
- What is the smallest thing that would tell us? Keep the cart for 30 days instead of one. If returning shoppers still do not convert, save-for-later would not have saved them either.
Refinement, ten minutes before the sprint is locked. The PM presents save-for-later and mentions marketing wants it before the spring sale.
"Should saved items sync across devices? Is it a separate page or a drawer? Feels like an eight, not a five."
"Can you tell me what happened on the call? — She added things, saw the shipping cost at the last step, left, and came back to an empty cart. — So that is two problems: the shipping surprise and the lost cart. Keeping the cart for 30 days is about a day, showing shipping on the cart page is about two. Could we ship those before the sale and then see whether save-for-later is still what we need?"
Put the problem sentence in the ticket
The questions only help if the answers survive the meeting. The cheapest way is to put them at the top of the ticket, above the solution, in words that someone who was not in the room can check against later.
The test for the problem sentence: it must not name a feature, and it must be possible to be wrong about it. "Shoppers lack a save-for-later button" fails both. "Returning shoppers lose their cart and do not come back" passes — and a query can tell you whether it is true.
1## Problem2Returning shoppers lose their cart and do not come back.3 4## Who5Shopper on mobile who builds a cart, sees the total, and leaves to think.6 7## Evidence8- 1 customer call (anecdote)9- Cart-to-checkout funnel: most drop-off is on the shipping step (pulled for refinement)10 11## What changes if solved12More returning shoppers reach checkout with the cart they built. Weekly count.13 14## Smallest thing that tells us151. Keep carts for 30 days instead of 1 (config, about a day)162. Show estimated shipping on the cart page (about two days)17 18## Original proposal19Save-for-later button and saved-items page (about two weeks). Revisit after 1 and 2.The evidence line admits it is one call. That is fine to start from; what is not fine is a ticket that hides how thin its evidence is.
When not to decompress
Asking the five questions of every ticket is its own failure mode, and the fastest way to make a team stop inviting you to refinement. The skill is noticing which tickets are bets and which are chores.
How much decompression does this ticket need?
when Bug fixes, copy changes, legal or contractual changes with a fixed shape, and follow-ups to a problem that was already decompressed.
cost Now and then you build a chore that was secretly a bet. Cheap, as long as it was small.
when New user-facing behaviour whose problem is not written down, or anything more than a few days of work.
cost Ten to twenty minutes of meeting time, and some friction the first few times with whoever wrote the ticket.
when Nobody in the room can answer "how do we know it is real", and the build is measured in weeks.
cost A few days before any code, and a visible delay the requester has to accept.
How to do it
Most important first.
- Rewrite the first line of the ticket as a problem with no feature in it: "Returning shoppers lose their cart and do not come back." If you cannot write it without naming the button, you do not have the problem yet.
- Ask where the ticket came from and get the original — the call notes, the support tickets, the funnel chart. One source is an anecdote; say so without dismissing it.
- Name who has the problem as a role doing a task at a moment, not "users" (Users and the Jobs They Hire Features For).
- State what would change if it were solved, in a form you could observe: a number, a ticket category, a behaviour (Picking a Metric That Moves When the Product Gets Better).
- List at least two other ways to address the same problem — including "change something that already exists" and "do nothing" — before estimating the one on the ticket (Options, Not Answers).
- Propose the smallest thing that tests whether the problem is real and the solution fits, and put it next to the full version with both costs (The First Version That Teaches You Something).
- Timebox it. On an ordinary ticket the five questions fit into ten minutes of refinement. If they need a week, that is a discovery task and should be planned as one.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the problem you think it is, as a question rather than a correction: "My read is that shoppers lose their cart when they are not ready to buy — is that what the call was, or was it something else?"
- Put the evidence next to it: "The funnel shows most drop-off on the shipping step, not on the cart. That makes me wonder whether save-for-later solves what the customer actually hit."
- Offer options with costs instead of a verdict: "Keeping the cart for 30 days is about a day. Showing the shipping cost on the cart page is about two. Save-for-later with a list page is closer to two weeks. The first two would tell us within a week whether they were the real problem."
- Close with what you will build either way: "If the sale needs save-for-later regardless, I will build it — I just want us to agree now what we will look at afterwards to know it helped."
- "The sale is in three weeks, we do not have time for this." Ten minutes now is the cheapest this question will ever be. If the answer is that the sale needs the button regardless, I build the button — and we still write down what we expect it to change.
- "A customer literally asked for this." One customer asked for this solution to their problem. I want the problem, because the next ten customers may have it and need something different.
- "Isn't this the PM's job?" Mostly, yes. But I know the cart already keeps shoppers' items for a day and could keep them for thirty with one config change. The PM cannot know that, and it changes which option is cheapest.
What can go wrong
- Interrogation: firing the five questions as a checklist at the PM who wrote the ticket, so it lands as an audit. Ask them out of curiosity, one at a time, and answer some of them yourself.
- Paralysis: refusing to start until the problem is proven. Most problems cannot be proven before something ships; the fifth question exists so you can ship the thing that proves it.
- Swapping their solution for yours: decompressing the ticket only to arrive at the design you wanted anyway. If every decompression ends at your favourite architecture, you are anchored too, just on your own idea.
- A problem statement that is the solution in disguise. "Shoppers lack a way to save items for later" is the button, rephrased.
- Doing it to everything. A copy fix, a broken link or a legal change with a fixed shape already has its problem, and asking again is noise that teaches people to route around you.
- "Problem before solution means no solutions in tickets." Tickets can propose solutions. They should also state the problem, so the solution can be judged against it.
- "If I find the real problem, the PM should drop their ticket." Recovering the problem gives the team a better decision to make; it does not hand the decision to you.
- "This is discovery, and discovery is the PM's job." Discovery that ignores what the system already does and what things cost is incomplete. The engineer is the one who can see the cheapest options.
- "The five questions are a gate." They are a conversation. A ticket with a thin answer to one of them can still ship, as long as someone knows which answer was thin.
Knowing whether it worked
- The ticket carries a problem sentence that names no feature, and the PM wrote it or agreed with it.
- In refinement, the first question about a new ticket is "what is it for?" — and it comes from someone other than you.
- After launch, someone can say whether the problem went away, because it was written down before the solution was.
- Fewer "while we are at it" additions, because each one gets checked against the problem sentence.
- Now and then a ticket shrinks or dies in refinement, and the PM is the one who is relieved.
- On a small team the five questions are a conversation. At 10x team size the person who had the conversation is not in the room, and the problem sentence in the ticket is the only thing that survives. That is when a template starts to help, and not before.
- At 10x users, anecdotes multiply: every problem has a customer who asked for it. *How do we know it is real* becomes the question that matters most, and funnel data and support categories replace single calls.
- At 10x revenue, the cost of solving the wrong problem is mostly opportunity cost: the team that spent the quarter on save-for-later did not fix shipping transparency. The questions do not change; the price of skipping them does.
- It delays the first line of code, and on a ticket that was right as written, the delay bought nothing.
- It can bruise the person who wrote the ticket even when done kindly. Some PMs welcome it; some hear it as not trusting their judgement.
- The problem you recover is often bigger, vaguer and harder to schedule than the solution you were handed. A clean two-week button is easier to plan than "shipping cost surprise".
- You will sometimes misread the problem, argue for the smaller version, and build the original anyway — having spent a few days of goodwill on it.
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.
- GENERALThe gap between ticket and problem exists on every team that writes tickets. It narrows with a PM who writes problem statements, and widens when tickets come straight from sales or leadership with the solution already promised.
- STAGE-SPECIFICPre-product-market-fit nearly every ticket deserves decompression, because the product itself is a hypothesis. In a mature product with a stable roadmap most tickets are operational, and the questions are for the handful that are bets.
- PRODUCT-SPECIFICIn regulated or contractual work — a tax rule, a payment provider's deadline — the problem is fixed from outside. Decompression there is about the smallest compliant version, not about whether to do it.