[August 2026 edition]

The Art of Defining Problems, Part 2 — Four Axes: Boundary, Standpoint, Time and Constraints

Published: Aug 11, 2026
Reading time: ~14 min

Part 1 separated the solution from the request and wrote the problem as a gap against the current state.

The same facts, however, can yield different problems depending on where you cut. Part 2 takes the four axes that decide where that cut falls, one at a time.

Axis	What it settles
Boundary	How far the scope reaches, from where to where
Standpoint	Whose problem it is written as
Time	A value at one point, or a trend over time
Constraints	Which conditions cannot be changed

1. Where to draw the boundary

A problem definition drawn too narrowly produces local optima. Define it as “speed up invoice entry for the finance team” and OCR and input assistance become the candidates; but if the real problem is “the same transaction data is entered several times between placing an order with a supplier and paying them,” speeding up invoice entry alone leaves the duplication intact.

Widen it too far and it becomes unworkable. Improve company-wide productivity, raise customer satisfaction, achieve digital transformation, improve information sharing. These are policies or wishes, not units that lead to concrete investigation and decisions. A workable width sits somewhere around this: not closed around a local symptom, yet within what a single team can verify, covering a connected sequence of user actions, and written out as far as the boundaries of the affected work and organisations plus what is out of scope.

Whether the boundary you drew is sound becomes clear once you move it.

Direction	Question
Upstream	What happens one step before
Downstream	What happens one step after
Across organisations	What appears once you cross a departmental boundary
Toward the user	Where does the boundary sit if you include achieving their goal
Out of scope	What is not included this time

If widening it one step changes the solution, it is worth redefining at that width.

The Double Diamond, created by the Design Council in 2003, draws this widen-then-narrow movement as two diamonds. It came out of Richard Eisermann, then Director of Design and Innovation, asking his own team how to explain the design process. The stages are Discover, Define, Develop and Deliver. On the first diamond, the Design Council writes that “the first diamond helps people understand, rather than simply assume, what the problem is.” Keeping exploration and convergence structurally separate is what stops the initial request or hypothesis from being fixed in place as the problem.

2. Whose problem is it

2.1 Problem definitions without a subject

Problem definitions with no subject can be written endlessly. Information is not shared, procedures are complicated, data is not used, the system is hard to use, processing is inefficient. Because none of them say for whom, while doing what, and with what inconvenience, the solution ends up being decided by organisational convenience alone.

Demanding a subject is also what human-centred design asks for. NIST’s description defines the approach as building usable systems by focusing on users and their needs and requirements, and holds that design must be based on an explicit understanding of users, their tasks, and their environments. The first activity it places there is likewise understanding and specifying the context of use. Unless it is settled who is trying to do what in which situation, design cannot begin at all.

From the same facts, a different standpoint yields a different problem. Say an application takes a week. For the applicant, the problem is the wait until a result arrives; for the processing staff, it is incomplete entries and the volume of enquiries. For a manager it is the inability to see where processing has stalled, for an auditor the absence of evidence behind decisions, and for an executive perhaps the cost of processing. The bare fact that “an application takes a week” has not yet defined a problem. It becomes one only once it is settled who finds what undesirable, against which state and by how much, and why it should be solved now.

The parties to identify go beyond the requester. Line up the actual users, the operators, customers, managers, downstream staff, audit, legal and security, and the maintenance and operations team, then look at who gains and who picks up a new burden.

2.2 The choice of subject decides the solution

The choice of subject directly decides the candidate solutions. Define a project to reduce call-centre enquiries as a problem for the company and it becomes “throughput per operator is low and running costs are high,” which lines up shorter response times, AI voice response, and operator assistance. Define it as a problem for the user and it becomes “users cannot reach the information they need and have to phone in,” which lines up simplifying the procedure, better notifications, rewritten explanations, and visible processing status. Neither is necessarily the only correct one, but unless you record which standpoint you placed at the centre, there is no way to review the decision later. The phrase “operational efficiency” readily conceals this choice.

Once a standpoint is chosen, establish what that choice brings to whom.

Subject to check	Question
Target of improvement	Whose metric are you trying to improve
New burden	Whose work increases as a result
Transfer	Has the burden merely moved to another department
Conflict	Does the customer’s optimum conflict with the organisation’s
Priority	If they conflict, whose outcome takes final priority

Proceed without recording this and there is no way afterwards to trace whose decision it was.

Take a request such as “we want to introduce generative AI into enquiry handling.” Swap the subject and it takes a different shape.

Start by writing the problem from the organisation’s standpoint. Enquiry volume is high and there are not enough people to handle it. Think about a solution to that problem and automated responses will come up, for instance.

Now write the same situation from the user’s standpoint. 42% of new users cannot judge whether they qualify to apply or what they need to submit, and so contact the desk before applying. The explanations are split across the website, a PDF, and the application screen, and each says something different. Asking a member of staff produces different answers depending on who answers.

The users in this example, in other words, are not contacting anyone because they want to; they are contacting because they cannot judge for themselves. Read that way, the target state is not “enquiries can be answered quickly” but “people can decide without enquiring.”

Think about solutions to that problem and the candidates do not narrow to one. Reorganise where the explanations live, merge the three separate documents into one, build the eligibility check into the application screen, simplify the application conditions in the first place, provide search, have an AI answer. All of them line up in the same column as candidates, and AI is one of them.

2.3 Users also speak in solutions

Users, too, sometimes describe their own problems in the form of solutions. I want a list screen, I want CSV export, add more search conditions, let me approve from my phone, have an AI answer. The list screen may be about spotting missed cases; CSV export may be because the aggregation they need cannot be done inside the system. Search conditions may point to the absence of a shared identifier for locating the data in question, phone approval to processing stalling while managers are away, and AI answers to rules and information being scattered across several documents. Implement requests as they arrive and you get only the solutions the user was able to imagine. That is the reason GOV.UK’s page on user research in the discovery phase asks teams to understand who users are, what they are trying to achieve and how they behave today before moving on to design and build. Users are experts in their own experience, and the feature they proposed is not necessarily the best solution.

IDEO’s design thinking is likewise described as a framework that integrates what is desirable for people, what is technically feasible, and what is viable as a business. IDEO defines it as a human-centred approach to solving complex problems, positioning it as an iterative process that learns by making and testing rather than deciding the solution in advance. Write the problem from only one of those three standpoints and the other two will show up later as constraints.

2.4 Skipping the examination becomes rational for both sides

Implementations that skip the examination recur not because the stakeholders are judging wrongly. It is because both the client and the vendor are better off that way.

An implementation built without examining the underlying problem leaves that problem in place, so the commissioning organisation keeps paying small change afterwards. Every time a data definition changes, they order a fix to the conversion logic; every time the rules are revised, they order a tuning pass on search accuracy. Until the organisation sorts out its definitions and rules, these payments do not end.

Even so, this is not necessarily a losing choice for the client. Unifying data definitions across departments, tidying up and retiring rules, settling where responsibility lies — each involves negotiating with other departments and a decision that strips someone of authority. There is no telling when any of it will conclude. Settle for an implementation without touching the organisation and that pain converts into maintenance costs that can be put on a budget. Turning a fundamental problem into a controllable one with a known price and timing keeps the wound shallow.

For the vendor, this maintenance is continuing work. The longer the problem remains, the longer the change requests keep coming, and the revenue with them. Solve the organisation’s problem and the maintenance is no longer needed.

The decision to skip the examination, in other words, holds because both sides chose the short-term gain. It is not individual laziness but the product of a structure in which the two sets of interests mesh.

2.5 No mechanism rewards the decision not to build

The force that makes an unresolved question hard to raise also comes from the organisation. “We want to investigate the problem” does not get a budget; “we will introduce a new system” is more readily approved. For a project lead, screens and features are easier to present as an outcome than a conclusion that no system will be built. On the engineering side, volume of implementation and number of releases are easy to measure, while development rendered unnecessary by reframing the problem is hard to credit.

Accounting and tax treatment pull the same way. Software is treated as a depreciable asset, and software for internal use is recorded as an intangible fixed asset when the conditions are met. Build a system and an asset remains; eliminate the work and resolve the problem and there is no asset to record.

Add to that the budget, contract and approval structures covered in Part 3 of The Art of Not Building. Institutionally, the decision to build can be rewarded, but no mechanism exists to reward the decision not to. The incentive pointing away from building is weak to begin with.

3. A value at one point, or change over time

Enquiries are high, stock is high, incidents are high, development is slow, technical debt is growing. Situations like these are easy to misread from the current value alone. When did the rise start, is it a temporary fluctuation or a sustained trend, does it recur cyclically at particular times, did it fall once after a countermeasure and then rise again, how does it move together with other indicators. The same figure means something different depending on whether this information is attached.

More telling than the fact that enquiries run at 1,000 a month is that they rose from 300 to 1,000 in six months with no change in user numbers. With stock, too, what needs solving is less the state of having a lot than the structure in which fear of stockouts raises safety stock, storage costs rise, and bulk ordering piles up further inventory.

System dynamics calls this pattern of behaviour over time a reference mode. The 1981 International System Dynamics Conference includes a paper by VanderWerf devoted to the use of reference modes themselves. A 2010 paper on problem definition by Ali N. Mashayekhi and Soheil Ghili sets out that what the field has emphasised is not “modelling a system” but “removing a difficulty and solving a problem.” The model is built not against the system as a whole but against the problem behaviour that needs explaining.

What to establish is when it began, what marked the change, whether there is periodicity, whether it reverted after an improvement, which indicators move ahead of it, and which effects appear with a lag. For the main indicators, drawing the past through the present to the desired future on a single time axis conveys the shape of the problem faster than prose.

Add a time axis to a problem definition and the strength of the statement changes. “Over the past six months, with user numbers roughly flat, enquiries about application status have risen from 300 a month to 1,000 a month” is a different document from “there are a lot of enquiries.”

4. Constraints and unverified assumptions

The current approval stages cannot be changed, this form cannot be retired, systems have to be separate per department. This data must be retained indefinitely, and customers must always submit on paper. The existing system cannot be modified, and processing must run in a batch at month end. Conditions like these narrow the solvable range before the problem is even solved.

Some constraints genuinely cannot be changed: law, contracts, safety, budget, deadlines, technical limits. Many others, though, are merely assumed to be unchangeable. Sometimes past practice is simply being carried forward, sometimes nobody wants to authorise a change, sometimes the relevant departments have never been consulted. A system specification may have been mistaken for a business rule, something may be set by internal rules rather than law, or a stopgap response to a one-off incident may still be in place. Rather than listing them, separating them by kind changes how they are handled afterwards.

Category	Contents	Handling
Absolute constraints	Law, safety, physical laws	Accept as given
Chosen constraints	Budget, deadline, target region	Renegotiable as a management decision
Negotiable constraints	Contracts, inter-departmental rules, existing products	Put on the table for adjustment
Unverified assumptions	Custom, belief, past decisions	Establish the basis

Which category something falls into is settled by tracing the basis.

Question	What it distinguishes
Where is the document that provides the basis	If no document appears, it is an unverified assumption
Who decided it cannot be changed	Whether the deciding party is inside or outside the organisation
Is it law, or an internal rule	Whether there is anyone to negotiate with
Is it a constraint, or a past decision left in place	Whether it still holds
When was it last reviewed	Whether the basis has gone stale
What becomes possible if this assumption is wrong	Whether checking is worth the effort

If the last question produces a concrete answer, it is worth checking.

Well-chosen constraints can raise the quality of the options, while unverified assumptions only narrow the solvable range. Daniel Markovitz, also a member of the Lean Enterprise Institute faculty, wrote an article on framing problems for HBR in 2020 along the line that how a problem is described determines how it gets solved. What it quotes there is Charles Kettering’s remark that “a problem well stated is a problem half solved.”

5. Setting the frame with the four axes

The four axes each prevent a different failure. Boundary prevents local optima, standpoint prevents solutions being decided by organisational convenience alone, time prevents misreading the current value, and constraints prevent the solvable range being narrowed unnecessarily.

Axis	What it settles	If left unsettled
Boundary	How far the scope reaches, from where to where	One step gets faster and the duplication remains
Standpoint	Whose problem it is written as	Only the organisation’s metric improves and the user’s burden grows
Time	A value at one point, or a trend over time	Reacting to the size of a figure without looking at the cause of the rise
Constraints	Which conditions cannot be changed	Changeable assumptions are treated as constraints and candidates are discarded

These four are not the kind of thing that yields an answer by passing through them in order. Move the boundary and the stakeholders change; change the stakeholders and the metrics change; change the metrics and the weight of the constraints changes. It is a back-and-forth: move one, revisit the rest.

Whether they are settled becomes clear on rereading the problem statement you wrote. Is the scope written, along with what is out of scope. Is it written whose problem it is. Is the current state written as change over time. Are constraints and unverified assumptions written separately. With all four in place, there is a level field for comparing solutions.

The problem definition written first is only a hypothesis. Part 3 covers updating the definition as investigation proceeds, through to handing it to requirements definition.