Frame the problem before anyone builds the solution.

Welcome to Issue #07.
Every Saturday I ship one field-tested lesson from live BA × AI delivery — the stuff I actually use on client work this week, not repackaged theory.

Last month a client dropped a one-liner into the tracker: "Build a notification centre." The dev team sized it, a sprint got booked, mockups appeared. I asked one question in standup — "what happens today that made someone ask for this?" — and it unravelled. The real story: two operations staff had missed refund deadlines because approval emails were buried in a shared inbox. They didn't need a notification centre. They needed to not miss a deadline. A feature request is an answer someone already picked. Your job is to find the question first. Here's how I use AI to get from the shouted solution back to the problem worth solving.

Turn the request into a problem you can defend

Three moves that pull a solution-shaped request apart and rebuild it as a problem statement the whole team can point at — usually in the time it takes to write the ticket.

1. Ask "what breaks today?" before you ask "what should we build?"

A request tells you the fix someone likes; it hides the pain that started it. So I take the raw ask and run a structured prompt: "This is a proposed solution, not a problem. Reconstruct the underlying problem as: who is affected, what they're trying to do, where it breaks today, and what it costs when it does. Mark anything you're inferring as an ASSUMPTION." The output is never the feature — it's the missed deadline, the buried email, the double-charge. Now you're looking at the wound, not the bandage someone grabbed.

2. Separate the problem from the solution in writing — on purpose

The moment a solution and a problem share a sentence, the solution wins and the problem stops being examined. I force them apart: "In one line, state the problem with zero reference to any solution. Then list three distinct ways to solve it, each with the trade it makes." Suddenly "notification centre" is one option next to "route approvals out of the shared inbox" and "a daily deadline digest" — and the cheapest of the three solved 80% of the pain. You can't see the cheaper answer while the expensive one is baked into the problem statement.

3. Pressure-test the problem is real before you spend a sprint on it

Not every problem is worth solving, and confident requests are the easiest to over-fund. So I ask: "What evidence would tell us this problem is real and frequent enough to fund? If we have none, what is the smallest thing we could check first?" For the refund case that was one query — how many approvals missed their deadline last quarter. It was eleven, each a real cost. A problem with a number behind it survives the next budget conversation; a problem with a good story doesn't. The check is almost always cheaper than the build.

What NOT to do

• Don't let AI invent the pain. Ask it to reconstruct the problem from what you gathered and flag its guesses — not to imagine a plausible-sounding one. An invented problem is worse than the original request, because it sounds analysed.
• Don't skip straight to the best solution. Even when you're sure, write the problem line alone first. The team buys the fix far more easily when they've seen the problem it answers, stated without the answer attached.
• Don't treat the requester's words as the requirement. "Build X" is data about what they want, not what they need. Honour the person, interrogate the phrasing — the two are not the same loyalty.

Try this week

Take the next feature request that lands as a finished solution. Before you size it, run the "what breaks today?" rewrite, state the problem in one solution-free line, and list three ways to solve it. Then ask what evidence would prove the problem is worth a sprint. Walk into the planning meeting with the problem on the screen — and watch how often the cheapest option was hiding behind the one everyone assumed you'd build.

See you next Saturday.
— Dibya Mishra, Senior Business Analyst