[{"data":1,"prerenderedAt":374},["ShallowReactive",2],{"blog-\u002Fblog\u002Fproblem-statements-vs-solution-requests":3,"blog-surround-\u002Fblog\u002Fproblem-statements-vs-solution-requests":356,"blog-related-\u002Fblog\u002Fproblem-statements-vs-solution-requests":364},{"id":4,"title":5,"audience":6,"body":10,"cluster":322,"date":323,"description":324,"draft":325,"extension":326,"factCheckedAt":327,"faq":328,"featured":325,"language":327,"meta":338,"navigation":339,"order":314,"originalAsset":327,"path":340,"pillar":341,"primaryKeyword":342,"relatedProject":343,"releaseScope":327,"reviewCycle":344,"reviewStatus":345,"reviewedBy":346,"searchIntent":347,"seo":348,"sources":327,"stem":349,"tags":350,"type":354,"updated":323,"__hash__":355},"blog\u002Fblog\u002Fproblem-statements-vs-solution-requests.md","Problem Statements vs Solution Requests",[7,8,9],"engineering-manager","product-lead","business-analyst",{"type":11,"value":12,"toc":312},"minimark",[13,30,35,42,116,120,127,131,138,172,183,187,193,217,225,229,239,243,269,277,285,288],[14,15,16,29],"p",{},[17,18,19,20,24,25,28],"strong",{},"A solution request tells you ",[21,22,23],"em",{},"what"," to build; a problem statement tells you ",[21,26,27],{},"why","."," \"Add a report showing exposure by entity\" is a solution. \"Treasury rebuilds exposure by hand every month-end and it's error-prone\" is the problem behind it. Converting the solutions people ask for back into the problems they're actually solving is the single highest-leverage move in project intake — because a solution built without understanding its problem is how teams confidently deliver the wrong thing.",[31,32,34],"h2",{"id":33},"the-difference","The difference",[14,36,37,38,41],{},"People almost never bring you a problem. They bring you a solution — the first answer that occurred to them — phrased as a request. That's natural, but it's a trap: the requested solution is ",[21,39,40],{},"one"," answer to a problem you haven't seen yet, and it's often not the best one. The problem statement is the thing underneath: what's broken, for whom, and why it matters.",[43,44,45,60],"table",{},[46,47,48],"thead",{},[49,50,51,54,57],"tr",{},[52,53],"th",{},[52,55,56],{},"Solution request",[52,58,59],{},"Problem statement",[61,62,63,77,90,103],"tbody",{},[49,64,65,71,74],{},[66,67,68],"td",{},[17,69,70],{},"Answers",[66,72,73],{},"What to build",[66,75,76],{},"What's wrong and why",[49,78,79,84,87],{},[66,80,81],{},[17,82,83],{},"Example",[66,85,86],{},"\"Add an exposure-by-entity report\"",[66,88,89],{},"\"Treasury rebuilds exposure by hand at month-end; it's slow and error-prone\"",[49,91,92,97,100],{},[66,93,94],{},[17,95,96],{},"Fixes",[66,98,99],{},"One pre-chosen answer",[66,101,102],{},"The underlying need",[49,104,105,110,113],{},[66,106,107],{},[17,108,109],{},"Lets you",[66,111,112],{},"Build what was asked",[66,114,115],{},"Choose the best answer, or decline",[31,117,119],{"id":118},"why-requests-arrive-as-solutions","Why requests arrive as solutions",[14,121,122,123,126],{},"Because it's how people think. Someone hits a pain, jumps to a fix, and asks for the fix. By the time it reaches you, the problem has been silently compressed into a solution — and if you build the solution, you've inherited their compression, including whatever they got wrong on the way. The request ",[21,124,125],{},"feels"," actionable, which is exactly why it's dangerous.",[31,128,130],{"id":129},"how-to-convert-a-solution-into-a-problem","How to convert a solution into a problem",[14,132,133,134,137],{},"Work backwards from the request with a few questions, ideally ",[21,135,136],{},"with the requester",":",[139,140,141,148,154,160,166],"ul",{},[142,143,144,147],"li",{},[17,145,146],{},"What's the problem this solves?"," (\"Why do you need the report?\")",[142,149,150,153],{},[17,151,152],{},"Who has this problem, and how often?"," (One analyst monthly, or the whole team daily?)",[142,155,156,159],{},[17,157,158],{},"What breaks if we don't do it?"," (The cost of inaction — often the real justification.)",[142,161,162,165],{},[17,163,164],{},"What are you doing today instead?"," (The current workaround reveals the true need.)",[142,167,168,171],{},[17,169,170],{},"Keep asking \"why\""," until you reach something that isn't a solution.",[173,174,176],"callout",{"type":175},"tip",[14,177,178,179,182],{},"The tell that you've reached the problem: you can no longer answer \"why?\" with another feature. \"Add a report\" → why? → \"to see exposure\" → why? → \"because we hold too much cash as a buffer and miss investment yield.\" ",[21,180,181],{},"That"," is the problem — and it might be solved by something other than a report.",[31,184,186],{"id":185},"an-example","An example",[14,188,189,190],{},"Take the real-sounding request: ",[21,191,192],{},"\"Can we add a report that shows treasury exposure by entity? Finance keeps asking.\"",[139,194,195,201],{},[142,196,197,200],{},[17,198,199],{},"As a solution:"," you build an exposure-by-entity report. Six weeks later it's the wrong report.",[142,202,203,206,207,210,211,216],{},[17,204,205],{},"As a problem:"," you ask why. It turns out finance doesn't need a ",[21,208,209],{},"report"," — they need the month-end exposure number to stop being wrong, because today it's ",[212,213,215],"a",{"href":214},"\u002Fblog\u002F03-finance-team-friction","rebuilt by hand and errors slip through",". The best answer might be fixing the source data, or an automated feed — not a report at all.",[14,218,219,220,224],{},"Same request, completely different — and much better — outcome. (This is the shift from ",[212,221,223],{"href":222},"\u002Fblog\u002F06-slack-request-to-initiative","a raw ask to a decision-ready initiative",".)",[31,226,228],{"id":227},"when-the-solution-really-is-the-request","When the solution really is the request",[14,230,231,232,235,236],{},"Occasionally the requester ",[21,233,234],{},"has"," done the analysis and the solution is genuinely the right, well-understood answer — a specific compliance requirement, a known integration. Fine: confirm the problem quickly and move on. The point isn't to interrogate every request to death; it's to ",[21,237,238],{},"not build a solution whose problem no one has checked.",[31,240,242],{"id":241},"what-usually-goes-wrong","What usually goes wrong",[139,244,245,251,257,263],{},[142,246,247,250],{},[17,248,249],{},"Building the solution as stated."," Delivering exactly what was asked for, and discovering it didn't solve the problem.",[142,252,253,256],{},[17,254,255],{},"Skipping the requester."," Guessing the problem yourself instead of asking, so you invent a different wrong problem.",[142,258,259,262],{},[17,260,261],{},"Interrogation theatre."," Turning \"what's the problem?\" into a bureaucratic gate that annoys people, instead of a two-minute conversation.",[142,264,265,268],{},[17,266,267],{},"Naming a solution in the \"problem.\""," Writing \"we need a dashboard\" and calling it a problem statement. If it names a build, it's still a solution.",[14,270,271,272,276],{},"Convert the solution back to the problem, and three good things happen: you often find a simpler answer, you can tell whether it's worth doing at all, and you can define ",[212,273,275],{"href":274},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","a measurable outcome"," for it. Skip it, and you build precisely what was asked — and precisely the wrong thing.",[14,278,279,280,284],{},"This is the core of what ",[212,281,283],{"href":282},"\u002Fproducts\u002Fdelivery-sheet","Delivery Sheet"," does: it makes the problem, not the requested solution, the first field you fill in.",[286,287],"hr",{},[14,289,290],{},[21,291,292,293,297,298,302,303,306,307,311],{},"Part of the ",[212,294,296],{"href":295},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also the ",[212,299,301],{"href":300},"\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams","project intake process"," and ",[212,304,305],{"href":222},"turning a Slack request into an initiative",". The ",[212,308,310],{"href":309},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":313,"searchDepth":314,"depth":314,"links":315},"",2,[316,317,318,319,320,321],{"id":33,"depth":314,"text":34},{"id":118,"depth":314,"text":119},{"id":129,"depth":314,"text":130},{"id":185,"depth":314,"text":186},{"id":227,"depth":314,"text":228},{"id":241,"depth":314,"text":242},"intake","2026-07-23","A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.",false,"md",null,[329,332,335],{"question":330,"answer":331},"What is the difference between a problem statement and a solution request?","A solution request tells you what someone wants built — 'add a report showing exposure by entity.' A problem statement tells you what's actually wrong and why it matters — 'treasury rebuilds exposure by hand every month-end and it's error-prone.' The solution is one possible answer; the problem is the thing that actually needs solving, and it usually has better answers than the first one someone thought of.",{"question":333,"answer":334},"Why should you turn a solution request into a problem statement?","Because building the requested solution without understanding the problem is how teams deliver the wrong thing. When you know the real problem, you often find a simpler or better solution than the one requested, you can tell whether it's even worth doing, and you can measure success. Converting solutions back to problems is the single highest-leverage step in intake.",{"question":336,"answer":337},"How do you write a good problem statement?","State what's wrong today, who it affects, and why it matters — concretely, with the cost or pain, and without naming a solution. 'Finance can't see group cash intraday, so they hold excess buffers and miss investment opportunities' is a problem statement. 'Build a cash dashboard' is a solution. Keep asking 'why' and 'what breaks if we don't' until you reach the underlying need.",{},true,"\u002Fblog\u002Fproblem-statements-vs-solution-requests","finance-systems-delivery","problem statement","delivery-sheet","annual","reviewed","Tan Gravam","informational",{"title":5,"description":324},"blog\u002Fproblem-statements-vs-solution-requests",[351,352,322,353],"delivery","requirements","finance-systems","text","DIzWnqasyRyyPN9rSca5liYQk-CN5rU4dtdyZb9gNaU",[357,361],{"title":358,"path":359,"stem":360,"type":354,"language":327,"draft":325,"children":-1},"Planning Levels and Groups in SAP Cash Management","\u002Fblog\u002Fplanning-levels-and-groups-in-sap","blog\u002Fplanning-levels-and-groups-in-sap",{"title":362,"path":300,"stem":363,"type":354,"language":327,"draft":325,"children":-1},"Project Intake Process for Finance and Engineering Teams","blog\u002Fproject-intake-process-for-finance-and-engineering-teams",[365,367,370],{"path":300,"title":362,"description":366},"How a team receives, shapes and decides on incoming work before committing people — the stages, the fields that matter, and four honest decisions.",{"path":274,"title":368,"description":369},"How to Define a Measurable Outcome","A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.",{"path":371,"title":372,"description":373},"\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out","How to Write Scope In and Scope Out","Scope defines what work includes and — crucially — excludes. The 'out of scope' list is the half that prevents scope creep. How to define it from the outcome.",1785182341915]