Problem Framing: Clients Don't Know What They're Asking For. The SA's Job Is to Surface It.

Part 1 of the SA System Design Cycle. Previous: Manifesto. Out of sequence (already published): Discovery.

Note: this article is the catch-up. I published Discovery before this one - it was finished first and I shipped it out of order rather than sit on a finished piece. The cycle resumes order from here.

The Axioma e-commerce request

An electronics retailer once came to us at Axioma asking us to build them e-commerce. They had a chain of physical stores, they were watching their competitors put up websites, and they wanted in. They handed me a short list of “minimal changes” they wanted on the website - the front page, a product card, a cart button. Maybe a search bar. They had a budget number and a deadline.

Three weeks later I had to walk them through several dozen processes they had not even mentioned, and the budget for the project tripled in front of them. They postponed the implementation for a year. They came back the year after with a different brief, and we built something that worked.

That moment is the cleanest illustration of what Problem Framing actually does, and what happens when nobody does it.

If you read the manifesto, you saw the same failure mode on a smaller stage - a 60-minute system design interview at Tabby, where I started drawing before I asked. The damage in a six-month project is the same shape as the damage in a one-hour interview. It is just slower, and more expensive.

This article is the first stage of the cycle. It is about the work that protects everything downstream from being designed against the wrong problem.

What Problem Framing actually is

Problem Framing is the first stage of designing any system. It is the work most analysts skip - or, more precisely, the work most analysts treat as a five-minute formality before “real” requirements work begins.

It is not requirements gathering. Requirements gathering happens after Framing, on top of a problem that has already been named correctly. Framing is the harder, earlier work: taking a client’s request and turning it into something that can actually be designed against.

The Axioma client did not understand that “build e-commerce” was not a goal. It was a proposed solution to a goal they had not yet named. My job in that first month was not to write specs. It was to surface the goal underneath the request, and then to inventory the things they had quietly assumed would behave like their physical stores.

This is the SA’s actual professional contribution at this stage: clients almost never know what they are asking for, and they are not supposed to. They know what bothers them. They know what their competitors have. They have a budget number and a deadline. The translation from “what bothers them” to “what we should build” is the work senior BAs are paid for, and it is the part AI does worst.

Four sub-tasks, in roughly this order, though in real meetings you iterate between them.

1. Business goals - why does this system exist at all?

Not features. Not functions. Outcomes the business wants and cannot get today.

The classic mistake is to accept “we need an OMS” or “we need e-commerce” as the goal. That is not a goal. That is a proposed solution to a goal they have not articulated. The goal might be “reduce order-to-ship time from 72 hours to 24 across all three brands by end of next year” or “capture revenue from customers who walk past the store without going in.” Those are testable. “We need an OMS” is not.

2. Success metrics - how will we know it works?

Numerical. Observable. Agreed by stakeholders before launch. Metrics agreed after launch tend to drift toward whatever makes the project look successful, which is not the same as the project being successful.

Good metrics for an OMS rollout: order accuracy, average time from order to ship-confirm, inventory accuracy at SKU level, percentage of orders auto-routed without human touch, NPS for the order journey. Bad metrics: “user satisfaction will improve”, “operations will be more efficient.” Bad metrics are unfalsifiable, which is exactly why stakeholders prefer them.

3. Stakeholders and their conflicts - who wants what, and where do they disagree?

Multi-brand setups are political. The brand owner who is loudest in the kickoff is rarely the one who will block release at month four. The CFO who approved the budget will not be the one operationally signing off on the design. Map them all, and mark the conflicts you already see - they do not go away, they only get more expensive to resolve.

4. System boundaries - what is in, what is out, what we will not touch.

The “out” list is more important than the “in” list. It is where future scope creep gets pre-rejected. Every assumption that gets left implicit becomes a renegotiation later, usually at the worst possible moment, usually about something the architecture cannot easily absorb.

The core risk

Producing a Framing document that everyone signs and nobody rereads. Framing is only useful if it is referenced in week 12, when the brand-1 product owner asks why their pet feature is not in the design. Without that reference, it just becomes a document that sits in a folder.

OMS practice: questions before boxes

Three brands. Three legacy ERPs. The pitch: “unified OMS.” The first two meetings are not about features - they are about surfacing what each brand assumes will be true after migration.

Below are the questions a senior BA asks in the first two rounds, grouped by sub-task. In one OMS engagement I worked, the Framing stage took three rounds of discovery interviews with eleven people across the three brands and the central operations team. Eleven people sounds like a lot until month four, when you find out what missing one of them costs. By then the head of brand-2 operations is in the room explaining what they assumed, and you are looking at a redesign that costs roughly fifty times more than the question would have.

In a real Framing meeting you ask half the questions below; the answers generate the rest.

Goals

1. Why now? What changed this quarter that made this project a priority?
2. What pain does each brand feel today, in numbers? “Orders are slow” is not pain - “we lost 1.2 million euros to oversells last Black Friday” is.
3. Which of the three brands sponsored this initiative, and who in the C-suite owns it?
4. What’s the official goal versus the real goal? Cost reduction is often a cover for headcount reduction. Worth knowing - it changes what success looks like.
5. Six months after launch, what does success look like for the CEO? For each brand owner? For the head of operations?

Metrics

6. How do we measure if it works, and what’s the baseline today?
7. Who reports the metric, to whom, and how often?
8. What’s the failure threshold? At what number do we say “this did not work”?
9. Are there per-brand metrics, or only aggregate? Aggregate hides one brand failing while two succeed - and the failing brand will leave the platform.

Stakeholders

10. Who from each brand has decision authority? Who has veto power? They are usually different people.
11. Who has been burned by previous “unified platform” attempts? They will be the loudest skeptic, and they may be right.
12. Which brand has the strongest IT team? They will quietly become the de-facto standard, and the other two will resent it.
13. Where are the political third rails? “Don’t touch the brand-1 customer database” is the kind of constraint that kills a clean architecture if you discover it at HLD instead of Framing.
14. Who is currently running the brand-specific OMS today, and what happens to their role after migration?

Boundaries

15. What’s explicitly out of scope for V1? Returns, subscription billing, fraud detection, B2B EDI, loyalty, customer profile?
16. What systems must we not touch, and why?
17. What’s the failure case for each brand if we miss the deadline?
18. If V1 ships and one brand refuses to migrate, what happens?
19. Are there regulatory constraints that lock specific data flows? PCI DSS for payment, GDPR for cross-brand customer data, sometimes industry-specific rules.
20. What’s the V2 list - features the business wants but we are explicitly not designing for now? Knowing V2 shapes the V1 architecture.
21. The last question of every Framing meeting: “What do you assume is in this system that we have not talked about?”

That last question is the Axioma question. The electronics retailer assumed online would behave like offline because they had never run a parallel channel that did not. Asking it explicitly is the cheapest move in this entire stage. I have asked it now in maybe forty Framing meetings, and it has produced surprises in roughly half of them.

The two artifacts

Two artifacts come out of Framing. Both go on the wall in the project room, and both get referenced for the rest of the project.

The stakeholder map for our OMS shows three brands plus four cross-brand functions: operations, finance, IT platform, legal/compliance. The arrows are not reporting lines - they are conflicts. Brand 1 wants premium experience and will pay for it. Brand 2 wants volume efficiency. Brand 3 wants integration with its B2B clients’ systems. Operations wants standardization. IT wants one stack. The map puts the conflicts on the wall, so when the architect later picks a side, everyone in the room sees the trade-off being made.

The system boundaries diagram for OMS V1 shows four modules inside (order capture, orchestration, inventory reservation, status tracking) and explicitly labels what stays outside (PIM, WMS, payment processor, fraud detection, customer profile, loyalty, returns). Items outside are not “later” - they are decisions about responsibility. Outside means “another system owns this; we will integrate but not implement.”

Both diagrams should be cheap to update. Excalidraw or whiteboard quality is right for this stage. Polished tools come later, at HLD.

Back to the electronics retailer

The Axioma client had handed us the “minimal changes” list because they were thinking like a physical store: catalogue update, payment button, done. What they had not considered, until I went through it with them line by line, was a long list of processes that lived invisibly inside their physical operation:

• Returns logic for a channel where the customer cannot try the product before buying it
• Inventory split between physical stores and a central online warehouse, with reconciliation when inventory moves between them
• Fraud detection on remote payments, where the cashier cannot eye the customer
• Customer service for orders the cashier never saw and the floor manager cannot intervene on
• Courier integration with a 24-hour SLA expectation, and what to do when the courier is late
• A refund flow that did not exist in their POS, because in-store refunds happened at the till
• Roughly two dozen smaller processes that lived under “the manager handles it” in their stores

When I laid this out for them, they were not happy with me. The room got quiet, and the head of retail walked me through why each item I had surfaced was actually a different problem than I thought, until I could push back with examples of why it was the same problem - just one they had absorbed into manual operations and stopped noticing.

They were happy two months later, when their finance team had run the cost of the original “minimal changes” against the cost of the actual scope, and realized what would have happened if we had built only what they originally asked for. They would have shipped a website that took online orders the physical operation could not fulfill correctly, and the brand damage from that would have outlasted the project itself.

They postponed for a year. They came back with a brief that was actually framed.

That story is what convinced me Problem Framing is its own stage, not a five-minute warm-up before requirements work. The senior BA’s job at Framing is to translate what the client asked for into what they actually need - which is almost always larger, more complicated, and not what they wanted to hear. Doing that translation honestly is what keeps a project from arriving at completion already broken.

The same failure, smaller stage

The same disease showed up in my Tabby interview last week, only compressed into 60 minutes.

I started drawing the architecture - which is the equivalent of accepting “build e-commerce” as a complete brief. The interviewer was not Axioma, but the role they were testing for required exactly the discipline of pausing first to surface what they assumed and what they had not said. Once I had committed to a sketch, the constraints they had not yet told me started ambushing the design, and there was nothing I could un-sketch.

Tabby’s rejection email named this gap as “working closely under architectural guidance.” The diagnosis was precise. I had skipped the work that has to come before the marker touches the board.

That discipline is what this article is about. The cycle goes from here.

AI on this stage

Where it helps: synthesizing notes after a Framing interview is genuinely faster with AI. Drop in raw notes, ask for a structured summary by stakeholder and topic, get a usable draft in a minute. The output needs your edit pass before sharing - but it saves the hour you would spend organizing.

Generic question templates by industry are a useful starting point. Ask Claude or ChatGPT for “opening Framing questions for a multi-brand retailer building a unified OMS” and you will get a reasonable list. Use it as a baseline; replace half the questions with ones specific to what you have already learned.

Drafting a stakeholder matrix once you have named the players is solid. AI is good at filling in structured cells when you have provided the names and roles.

Where it lies: stakeholder maps generated from just a project brief are unreliable. AI invents plausible-sounding roles that do not exist in your organization (“Brand Innovation Council Lead” is a recent example), and you waste meetings looking for that person. Always start the map with names you have heard, not roles AI proposes.

Goals AI generates from keywords sound right and are not. “Improve customer satisfaction across channels” is a fine sentence and a useless goal. Trust goals only when they came from a stakeholder, not when they came from a model.

Last week I tested this directly. I asked Claude to surface “hidden processes” for an e-commerce project on behalf of an electronics retailer, deliberately giving it the same framing the Axioma client had given me. It produced a clean-looking checklist that missed three of the items the real Axioma client surfaced when I sat across from them - including the refund flow, which in their case turned out to be the most expensive single item in the eventual scope. AI cannot read what is not in the brief, and Framing is the work of reading what is not in the brief.

What you cannot delegate: the negotiation. Framing is partly a political act - getting three brand owners to agree on what success means is not text generation, it is facilitation. AI will not sit in the room and read who is holding back, who is nodding politely without buying in, who needs to be asked the same question phrased two different ways.

The non-obvious limit: AI generates first-level questions well. The questions that actually matter in Framing are follow-ups - questions whose phrasing depends on what the stakeholder said thirty seconds ago. “You said order accuracy is the priority. Is that because of compliance, or NPS, or cost of returns? Because the answer changes which system we would build.” That cannot be pre-generated. Until AI handles real-time conversational follow-up reliably, the Framing meeting is yours, and your skill at it is the differentiator.

Stage checklist

• Three business goals stated as outcomes, not functions
• Three to five success metrics, each with a current baseline
• All key stakeholders named, with their decision / veto / influence role marked
• Conflicts between stakeholder interests surfaced and acknowledged - not resolved, surfaced
• Explicit list of what’s IN V1 and what’s explicitly OUT (the “out” list reviewed by all stakeholders)
• One stakeholder map and one system boundaries diagram produced and visible to the team
• Final question asked in every Framing meeting: “What do you assume is in this system that we have not talked about?”

If any box is unticked at the end of your Framing - that is the next meeting’s agenda. Do not proceed to Discovery without it.

Next stage

In two weeks: Constraints - the diamond between ideal and realistic. Legacy ERPs we cannot rewrite. A budget that ran out before the kickoff. A team-per-brand structure that decides ownership before any architectural conversation. Compliance that vetoes the elegant option. Constraints is the work of admitting which parts of the right design we are actually allowed to build.

Discovery already shipped, out of sequence. If you have not read it yet, the link is above.

If this stage was useful, follow the cycle.

Two questions for you.

What is the worst Framing failure you have seen in your own work - the assumption that did not surface until month four? I want to collect patterns; the strongest ones inform the Constraints article.

If you ran a Framing meeting tomorrow on a system you actually have to design - what is the first question you would ask, and why?