Who is this for?

A strategy has several users: the person making the decision, the person carrying it out, and the customer who eventually lives with it. I find it useful to ask what each of them needs before deciding what goes into the deck.

My training was in design. In UX work, asking who will use something is an ordinary starting point. You want to understand what the person is trying to do, what they already know and what gets in their way.

I think that habit is useful in strategy as well. The executive deciding whether to enter a market and the team planning its first operating steps may be working towards the same goal, but they need different things from the material in front of them.

A document can be analytically thorough and still leave its reader uncertain about the decision. Asking who it serves gives me a way to inspect that gap.

Make the decision visible.

Design teaches you to choose what receives attention. A page cannot give every element equal prominence and still tell the viewer where to begin.

The same question applies to a strategy artifact. What is the single decision this page needs to support? What evidence matters most? What can move into the supporting material?

Consider a fictional decision about whether to expand a pilot. A useful first page might look like this:

ILLUSTRATIVE DECISION BRIEF · NOT A CLIENT DOCUMENT

Should we expand the pilot?

Decision neededExpand now, run a second test, or stop.
What we knowWhich parts worked, for whom, and under what conditions.
What is uncertainWhether the result holds in a different operating setting.
Next stepName the owner, the next test and the evidence required to proceed.

Supporting analysis follows the decision, with assumptions and limitations made explicit.

This structure does not replace the analysis. It gives the reader a way into it. It also makes it easier to challenge an assumption, ask for missing evidence or agree on what happens next.

Listen close to the work.

The person approving a strategy is one user. The person expected to execute it is another.

Design research has made me attentive to that second perspective. An expert can explain a market. A person doing the work can reveal a constraint that the market description leaves out: an awkward handoff, an incentive, a repeated workaround or a step that takes much longer than expected.

Useful questions can be quite simple. Walk me through the last time this happened. Where did you get stuck? What did you do instead? Who needed to be involved?

These conversations do not settle every strategic question. They help test whether the proposed direction fits the conditions in which people will have to act.

Test the proposition while it can still change.

In design, an early version gives people something specific to react to. I see a similar use for an early strategy proposition.

A short decision brief can surface disagreement before the team invests in a finished presentation. It can expose that two people mean different things by the same objective, or that the recommendation depends on an assumption nobody has examined.

What does this person need to understand, decide or do next?

The early version needs enough substance to invite a useful response: a clear question, the current recommendation, the evidence behind it and the uncertainty that remains. Feedback can then change the reasoning while changing it is still relatively easy.

A habit I want to keep.

My own path has taken me from designing software workflows to strategy and operating work. I do not think every business problem should be treated as a UX project. I do think the habits of asking, listening, arranging information and testing an early version travel well.

For me, bringing a designer’s eye to strategy begins with a practical question: what does this person need to understand, decide or do next?

That question helps me decide what the work should become.

WHERE THIS PERSPECTIVE COMES FROM

From a market-entry thesis to an operating business.