7 Powers: The Foundations of Business Strategy has been around for nearly ten years. It’s full of wisdom for business strategists. And it’s useful for designers too.

What is Power and how can you use it to guide your design effort?

I’ve put together a simple summary and a “four-step process” to help guide your most critical design decisions.

The meaning of Power

Strategy can often seem esoteric. Helmer makes it simple by explaining that it’s really just about gaining Power. He defines Power like this:

The set of conditions creating the potential for persistent differential returns.

In other words, a company has Power when it has engineered a situation where…

• It can make a lot more money than others in the same market – that’s the differential returns part (also known as the “Benefit”)
• And it can keep doing that for a long time because others can’t compete effectively – that’s the persistent part (also known as the “Barrier” or the “Moat”).

All the most successful businesses in the world, like Amazon or Nvidia, have Power. For years, they have made huge returns, and no-one has been able to knock them off the top spot. Every business that wants to grow should be seeking Power like that, in the hope that it can transform…

from an unattractive rat race commodity business to a bankable cash flow generator.

As a designer, that’s

the business you’re in too. Helping your organisation to succeed in the quest for more Power.

The seven types of Power

Power takes seven different forms. Just seven. After decades as a strategy consultant and lecturer at Stanford, the author, Hamilton Helmer, is confident that he has found them all.

Here they are:

• Counter positioning (AKA disruptive innovation): Disruptive innovations let companies change what people buy, and often reduce prices. Older players in the market can’t match the prices or the features, while still making a profit. For example, Sketch disrupted Adobe, and Figma disrupted Sketch.
• Scale economies: The bigger you get, the lower your costs for each unit of stuff you produce. So you can charge less, or increase profit margins, or both. AWS is a nice (digital) example of this – even though Microsoft and Google are catching up.
• Switching costs: Some businesses have customers that can’t leave them without incurring a cost that’s too high to bear. SAP is a good example.
• Network economies: Marketplaces and social networks are the most valuable when they have the most participants. Customers or users want to go to the place where they’ll find most other users to work with. An example: Instagram.
• Process power: A few businesses can deliver output at lower cost and higher quality than anyone else in a way that can’t be replicated by competitors. The famous example here is Toyota, with their unique production system.
• Branding: Having a strong brand is a source of Power. It means customers perceive your product to be of higher value than equivalent competitor products, will choose it in preference, and frequently pay more for it. Coca-Cola, for example.
• Cornered resource: If you have access to a resource that no-one else can access, or no-one else can access at a competitive price, you have Power. An interesting example right now is ASML, currently the only company in the world that can produce the EUV machines that create top-end microprocessors.

Absolute Power?

Great. But if you’re not working for a business that has already established an unassailable position of Power, should you give up? No. Complete Power is rare – and you still have to earn a living.

Chances are that if you work for an organisation that is turning a profit, it does have some Power. I think it’s interesting to analyse what Power your company does have, and then use your skills as a designer to help it strengthen that.

How to get Power

And there’s a fascinating twist. Helmer explains that the kinds of Power mentioned above are “static”. That means they’re a sort of “end state” and comparatively little changes once you have reached it (at leats for a while). But he also touches on the topic of “dynamics” – how you actually get to a position of Power in the first place.

There are only a few situations when a company can gain true Power, like the example companies above have attained. And those situations usually occur in a dramatically changing market or a brand-new one. At those moments there is little competition, or the competition hasn’t understood the moves you’re making.

Coca-Cola, for example, built their brand with intense focus for about 40 years before Pepsi managed to establish a consistent branding approach. And Toyota quietly and consistently established systems for delivering quality well before American car manufacturers realised that quality was the new competitive battlefield.

These moments of opportunity emerge when a company does something new. To attain Power, you need to do new stuff. That should be music to most designers’ ears.

Two killer quotes…

Power arrives only on the heels of invention. If you want your business to create value, then action and creativity must come foremost.

‘Me too’ won’t do: Action, creation, risk—these lie at the root of invention. Business value does not start with bloodless analytics. Passion, monomania and domain mastery fuel invention and so are central.

In other words, if your business isn’t creating, innovating, trying new stuff, you will never increase your Power. Design, anyone?

Applying Design to build Power

If you can identify know where your organisation gets its Power, you can focus your design effort on those areas. And by creating vision for what those areas could be, you might inspire the organisation to allocate effort to implement improvements or innovation in those areas.

Here’s my sketchy four-step process for how to get there…

Step 1: Identify the kind of Power your business has

Understanding how much Power your organisation has in each of the 7 dimensions is a great lens to understand your business, and where to focus your effort

So why not make yourself a little scorecard? Where does your org sit on the following seven dimensions…?

Counter positioning: Incumbent ....... Disruptor
Scale economies: Boutique craft ....... High-volume
Switching costs: Switching is easy  .......  Strong lock-in
Network economies: No network effects  ....... Dominant platform
Process power: Standard processes  .......  Unique systems
Branding: Weak recognition  .......  Loved and trusted
Cornered resource: Generic access  .......  Exclusive ownership

Fill in the chart and you might gain a fresh perspective on the strengths your company has that enable it to make money – and the weaknesses that are holding you back.

Step 2: Establish the elements that support your Powers

Each different Power has different elements that define and support it. When you understand which Powers your organisation has, you can look for the specific problems that go with it. That might mean expert evaluation, user testing, or some time with your analytics tool.

For example, if your organisation makes a product that has high switching costs, you might need to check:

• Activation: Do new customers make it to the moment of lock-in effectively, or do a lot of them give up and drift away? If there’s an issue, is it caused by high integration effort, a high learning curve, or internal resistance to change?
• Upsell: Are you understanding existing customers’ growing needs and creating the right new modules to upsell to them, so you can maximise ARR?

Or if your organisation is a two-sided marketplace, you might need to check:

• Liquidity: Are you successfully activating new sellers, and creating enough supply to attract buyers? And are you attracting enough buyers to make the marketplace attractive to sellers?
• Matching: Are buyers finding what they need via search? Are you attracting them back when the right supply does become available?

Maybe that’s obvious to you. But I’ve found it’s oddly beneficial to take that step right back and articulate what you’re choosing to focus on and why, as a designer. You might find yourself prioritising your time more wisely.

Step 3: How might we… build Power?

If you’ve found some problems that are reducing your Power, you’re back in familiar territory again. With a problem statement (or an insight into a new opportunity), you can flip the problem to a “How might we” question, and use that as a basis for ideation.

• How might we activate and lock in customers more effectively, given that they find the integration process too onerous?
• How might we get more customers to subscribe to alerts and increase demand, given that they are nervous about getting spammed?
• How might we make our core product offering more effective and delightful so that customers become effective word-of-mouth evangelists?

Step 4: Power play

Getting change to happen in your own organisation can be hard. You’ll need allies (usually your Product Managers) and you’ll need to pitch.

But as a designer, you’ve got the skills to explain user needs and create visions of solutions.

And this time you’ll have something extra in your arsenal. You’ll be focused on the dimensions that demonstrably matter to your business. You’ll speak a new language, which will make you smarter. And you’ll have a well-respected system to help you justify exactly why you’re proposing the change.

Bonus tips

• You can read the book and skip the maths. If you do, it’s pretty short, but still excellent.
• If you ask an LLM to help you understand and apply the 7 Powers, you can get plenty of interesting advice.

“Why does my org do such weird things? Why am I excluded from the real decision-making process?”

I ended up doing a talk about this for the Friends of Figma Meetup in Krakow.

The answer is more complicated than I could really cover 20 minutes. But I chose to focus on:

• The fundamentals of money, strategy and metrics that designers need to understand
• The basic professional skill of getting things done, while staying sane
• The need to focus effort in areas that match your organisation’s strategy
• How designers generate unique value by mastering speed, vision and simplicity.
  
  Big thanks to Backbase for hosting, Friends of Figma, Kraków for sponsoring and publicity, and Patryk Szymański for making it happen!

Quick recap

You really need to read part 1 before this post, or it won’t make much sense.

This post covers objections, and also the process, timing and templates for making it happen.

Objections

Objection 1: How does senior leadership actually know what objectives to set?  Aren’t they going to ignore customers and make terrible choices?

We’re talking about a scale-up here.  So senior leadership should not be too divorced from the reality of the customers or the software. But in addition, this process acts as a forcing function to make sure they stay very much engaged.

Von Moltke, the inventor of mission command, created strategy for entire military campaigns. To do that well, he used reports from senior offices, reports from his own special team that he sent out to gather information, and… his own telescope!  He needed insights about what was happening, and he made sure he got them.

By agreeing that the commanders’ intent is where alignment begins, “commanders” make themselves accountable for forming a good strategy. They’ll need to work with senior product, design and tech to understand their situation, and formulate a good strategy.  The intention is to ensure that senior leadership sets up the systems and process to pull the information they need to them, from across the org. leaders who are not connected to customer and organisational feedback will become divorced from reality, missing out on the knowledge and ideas they need to make the right calls. They’ll also be perceived as aloof, living in an ivory tower, and similar.

You can see that part of the process captured in the diagram later in this post.

Objection 2: Yes, but what if the commanders really are misguided and are doing the wrong thing?

Unlike many of Von Moltke’s soldiers, you do have the option to go get another job. If you’re convinced the commanders are driving the company to certain doom, then it’s best for everyone if you go get a job in a company that you do believe in. It’s best for your current org too, because you’ll be slowing them down if you’re not really aligned with the direction.

But before you dust off your CV, just check: 

• Are you convinced there is a profound misjudgement, or is this just a matter different ordering: Certain things have to happen first?
• Do you understand the factors driving senior leadership’s choices, and the objectives you’re being set? Sometimes things like “We need revenue now or we’re dead” trump things like “Our customers would have a nicer time if…”
• Have you communicated your proposal crisply, convincingly and to the right people. Do not sit there saying “I have no voice”, just start speaking. Take charge, write a doc/make a video and send it to the senior leaders. Keep it positive.

Objection 3: What’s all this talk of commanders? It sounds like I just take orders and do nothing creative!

In The Art of Action, Stephen Bungay explains that beyond management and leadership, there’s that there’s a third dimension that excutives need to master: Command.

• Leadership is about making sure teams and individuals succeed at their task. Picture the leader of a SEAL team for example.
• Management is about organising and making resources available, so that teams have what they need to win.
• Command is the name that’s used in the military world to describe the process of defining a strategy and giving clear instructions so that the strategy can be executed. 

Understanding that command is the “missing category” in leadership discussions really helps.  The word “command” can be off-putting for people in business – we tend to use “director” and “directions” or “objectives”  But once I understood what was meant by command, I realised it’s a wonderful thing.  For me, the fresh use of the term brings fresh thinking.

Objection 4: Doesn’t this cause product squads to disengage?

Yes, if you do it wrong. But if you do it right, it makes squads breathe a sigh of relief. 

Product squads will feel productive, valued and empowered if…

• You explain the reasoning and the amazing history behind the idea. 
• You demonstrate that they get a lot out of it: Trust to own the how, and the right to demand a clearly defined what and why.
• Make sure you have good mechanisms in place to get insights and ideas from squads to leadership – clear channels with feedback  so they can see evidence that their voices and ideas are being heard.
• Make sure that when a squad is having a planning week, the whole squad works together to create the plan/back-brief.  This is hugely powerful, because it gets engineers engaged in understanding the strategy and objective and formulating the solution. No waterfall from product to engineering. No chance for developers be excluded from the ideation work that they actually love.

Timing, process and templates

The process

The timing

Work backwards from when you want quarterly planning to be finished. Here are some key events I recommend.

Document templates

There’s simple recipe for briefs in Art of Action. Here’s an outline with a bit more detail, for digital product.

Product objective brief for a squad

• Intent
  • Goal
  • Win state (what customers and the org will have, and be able to do, when the objective is reached)
  • Why make this investment
  • Trade-offs (investments we’re not making, so that we can make this one)
  • Budgets (how many people, for how long)
  • Scope / boundaries (how far to go, what not to do)
• Proposal
  • Principles
  • Problem/solutions areas
  • Press release
  • Concept sketches
• Metrics
  • Key business metrics (which major metric to move, direction, but probably not amount)
  • Product team KPIs (adoption, leading metrics, performance…)
  • Health metrics (what not to break)

Back-brief/plan

This is created by the squad. Remember the rules of artificial certainty from the previous post: Create certainty to get speed, and there’s no shame in changing the plan when you get new information.

• Restating the intent, and response to the intent
• Outcomes and dates
  • Milestone 1
    • Outcome
    • Features
    • How we’ll do it – approach
    • Trade-offs
    • Risks
    • Delivery date
  • Milestone 2
    • … (as above)
  • Minestone n
    • …
• Metrics
  • Key business metrics
  • Product team KPIs (adoption, leading metrics, performance…)
  • Health metrics

Notes about the content of the foundational/context items

These are blog posts in themselves. But as a quick guideline, I think…

• The one-page strategic plan is a good way for a business to articulate everything it needs for the org-level strategy and goals to be clear.
• The product vision needs to articulate what the product will be like in the future, when we’ve made our goals a reality. It should contain personas, concept sketches and narrative copy. It should articulate the benefits that customer get from the future product. And it will need videos, presentations and workshops too.  
• It works well if the the vision is based on a brand promise: a statement of what we promise to customers, why, and how we measure if we’re delivering on the promise.

To keep drilling into these essentials, read: Reforge 4D roadmapping.

There’s more to cover and more to learn in this space. So do feed back to me with learning and ideas from the battlefield.

Footnotes

[1] Defining the who

• Strategic org leadership: CEO, COO, any other clearly-defined strategy leaders (eg. Head of Strategy, Founder…)
• Product/tech leadership: VP Product, CTO, VP Design, and any other key leadership roles (eg Group Product Manager, Head of Data, …)
• Triad: Product manager, engineering manager, senior product designer

We dream of speed

“I’m back working on a tiny startup again. You can go so fast!  Because everyone is aligned and focussed on the goal.  If only we could keep that as we get bigger.” — S, a product-manager friend

“We’ve pretty much lost a whole quarter. The squad is hearing one set of instructions from one stakeholder and the opposite from another. They don’t know what to do.” — M, another product-manager friend

Speed is the number one capability that enables success for any digital business. [1]

Software squads that go fast rely on clear context and sensible, unambiguous goals.  If your squads don’t have that, then they can’t go fast.

The Art of Action

To get that clarity, and unlock the speed, you can use a recipe based on mission command. It’s an approach invented by Prussian general Von Moltke in the 19th century, and proven ever since[2].  Most people in the digital product space have heard of it. But most don’t know how to apply it well. Marty Cagan is a big proponent, but fellow fans I have spoken to all say “Empowered is good, but it’s a bit vague”.[3]  

The Art of Action [4] is a classic book which explains the reasoning behind mission command, and why it’s effective. That makes easier to apply it with sanity and conviction. After reading the book, and applying it with some success, I’m all fired up.

Axiom: In a scale-up, too much freedom slows you down

Von Moltke’s military campaigns and scale-ups have a lot in common: They need to move fast, but there’s too much information for everybody to know everything. You need coordination to make sure that people with limited information don’t bump into each other or do irrelevant things. 

If squads are spending their time on trying to identify, debate and select strategic problems to solve, they are gonna be spinning their wheels a lot. Instead, squads need to focus their effort on actually solving strategic problems that have been defined clearly by product and business leaders.

Then squads will have time and bandwidth to craft awesome solutions that work for customers, and make business win.

“The team is given a small number of problems to solve…”

Empowered

5 rules of the quarterly planning game

Rule 1: Senior leaders need to define context and strategic intent

Context means they need a coherent company mission, company strategy, product strategy and product vision for everyone. The artefacts in this stack [9] should be clear, high quality, available and understood. Squads will not do well if they are expected to just take a guess. If you don’t have a comprehensible product vision, for example, then squads can’t align to it.

Product strategy is about identifying the right problems for product to solve, and framing those as clear objectives that people can deliver. It needs to be created by a small group of senior leaders, who go ask their teams when they need important information. It can’t be done “by everyone” or it will take forever.

Product strategy will typically include problems and solutions, or objectives and results. Conceptually, these take the form of trees. Going down the tree is “how”, going up is “why”. 

“The strategic context provided by the company mission, company scorecard, company objectives, product vision and principles, and product strategy is meant to apply to all product teams in the company.”

Empowered

Rule 2: Give squads autonomy by providing a clear what-and-why, then letting them define the how

Write one short product objective briefing document for each major objective your squads need to deliver. Include the what (objective), the why (objectives two layers up, at most), and the missions you believe they might need to tackle (a starting point for how). Your goal is to give the product squad control of all the how below that point.

A brief should also contain boundaries: what not to do, how much to spend, how long we’ve got…. I’ll share a format in the next post.

With this framework, a squad knows the boundaries of trust they have with senior management. They can innovate safely within those boundaries and demonstrate what Von Moltke’s people called “independent thinking obedience”.[5]

“[As a manager] it is up to me to create a context in which I can trust you. The framework of strategy briefing allows me to do this.”

The Art of Action

Rule 3: Make your product objective briefs seriously brief

Von Moltke could direct an entire army to decisive victory in 250 words or less. Seriously. He sweated hard to make orders clear, complete and short. Can you manage an Amazon-style 2-pager? No more than a 6-pager. [6]

Long documents are easy to misunderstand. Only include what a team needs to know to get the job done. Too much context is confusing. Short documents are more likely to get read and understood.

“Clarity of thinking and clarity of expression go hand in hand” which means writing good, short briefs is hard. Respect the challenge.

UI concept sketches make product briefs easier to understand. But you need to continually remind everyone that the pictures are jumping-off points, not specifications.

“What matters about creating alignment around a strategy is not the volume of communication, but its quality and precision. In order for something to be clear, it must first be made simple.”

The Art of Action

Rule 4: Eliminate the mess with the “back-brief” process

Squads need to write a response (the “back brief”) to the briefing they get, saying how they will deliver the objective. Or how much of it they can deliver and what resources they would need to be able to fully deliver it.

Leaders can then spot misunderstandings, which are guaranteed to occur because humans are involved.

They can also learn what’s possible and what’s not. And ask questions about compromises, approaches, assumptions. They can inspect the sum total of responses from squads and understand what the overall strategic impact will be from all the squad’s work.

Leaders can revise their objectives and with finite amounts of negotiation, reach a written agreement with each squad about value the squad will deliver, and by when.

“Every order which can be misunderstood will be misunderstood”

Jakob Meckel, Prussian Army General

Rule 5: Create “artificial certainty” to boost clarity and status updates

Building software contains a lot of unknowns and is infamously hard to predict.  Predicting how much software value you can deliver at the start of the quarter, before you’ve had a chance to do much discovery, is extra hard.

But when teams have certainty about what needs to be done by when, they can focus, push hard and achieve more.

So here’s the hack: 

1. Explicit definitions: Set a firm deadline, define a firm scope, and a firm statement of the expected ROI even though you are uncertain. Just make the call, and remove the uncertainty. 
2. Treated in good faith: Consider your decisions completely as if they are facts. Behave accordingly.
3. Explicitly revised: When solid new information appears that affects scope or deadline, change the scope or deadline. Define an organisational standard that says there is no shame in it. Squads must just commit that they will communicate and agree to material changes with senior leaders.

This takes some getting used to, for many teams. But it’s hugely liberating. It gets you psychological safety and focus in one.

“When we’re acting with sufficient certainty, our brain senses patterns, successfully predicts next steps, and operates much more efficiently. But when we lack certainty and can’t predict what will happen next, the brain must use dramatically more resources, involving the more energy-intensive prefrontal cortex, to process moment-to-moment experience.” 

Ed Batista and David Rock, Neuroscience, Leadership and David Rock’s SCARF Model [7]

How to make it happen

Before you can install a new approach to quarterly planning you have to explain the rules to everyone affected, make sure they understand, and get agreement.  Some people will not like the rules when they first hear them. They seem a bit strange. It will help a lot if you explain the thinking and get people to engage with Empowered and Art of Action.  

But when people have tried it for a while, they will probably be surprised at how much more time they have, and start to like it.

Next post,  I’ll make it practical and give some war stories.

Thanks to: Malan and Philip Joubert, Gys Muller.

I’d love to hear your feedback. Get in touch.

Footnotes

[1] Speed is the number 1 capability? What about craft? What about customer centricity? What about…? Calm down. Speed is necessary but not sufficient. However going fast enables you to deliver more value for customers than going slowly. And it lets you explore more alternatives, to discover things that really delight and engage customers – more instructive failures, more surprising discoveries. That’s all. Read: Speed as a habit.
[2] If you haven’t heard of mission command, or are wondering why I am talking about Prussian generals, try here or here.
[3] Empowered by Marty Cagan. 4.34 on Goodreads. Impressive.
[4] The Art of Action, by Stephen Bungay. 4.33 on Goodreads. Also impressive.
[5] AKA “Directed opportunism” or “Disciplined initiative”. Some of the military terminology in this book can feel weird. But get over it. Bungay contextualises words like “command” and “obedience” and they make sense. Imagine if everyone in your org was disobedient all the time. Would anything get done? But imagine if they were always completely obedient? Terrible things would happen then, too.
[6] Yep. Written documents. Amazon style. They work well in remote and async contexts. They act as stand-alone reference, people can go back to whenever they need to. They force you to get your thoughts in order. They provide lots of information quickly. They make meetings better. Quick overview.
[7] Neuroscience, leadership and David Rock’s SCARF model
[8] The one-page strategic plan from Scaling Up is a good place to start.
[9] Nice one, Reforge: The product strategy stack

(I wrote this for the OfferZen Blog – because the issue had been bugging me after some conversations with designer friends. It contains ideas I’ve learned at OfferZen, I guess – an organisation where people really get things done.)

Digital product designers often tell me they chose their career because they want to make a positive impact on real people’s lives. But they often seem to look a bit disappointed. It seems that because of the approaches designers take to their work, they often don’t achieve that impact at all.

I’ve been there. And I’ve got some hard-won tips to help overcome the problem.

But first let’s examine why it happens…

Your designer-brain: Blessing and curse

I’m not a formal expert on thinking styles or personality, but I’ve hired, trained and worked with great designers for the last twenty years. And I think there’s a fighting chance that you have:

• An opposable mind. Strategist and design thinker Roger Martin wrote a book about it. Powerful design thinkers, he argues, can hold an idea and its opposite in their heads at the same time, without getting freaked out. “What if this were true? Or what if that were true?” Or any of the other options in the middle. That skill is what lets you explore many alternatives to find the best one.
• A tendency towards perfectionism: Poor service, inconsistencies, doors that you pull when they look like you should push them – they all drive you crazy. But it’s your sensitivity to those details that makes you the right person to design something better.
• An N in the middle of your Myers Briggs type indicator (rather than an S). N stands for iNtuition. And if you do lean that way, you “tend to trust information that is less dependent upon the senses, that can be associated with other information.” About 2/3rds of people are NOT like you. They are more “likely to trust information that is in the present, tangible, and concrete”. But if you only thought about things you can see and touch today, you wouldn’t be so good at imagining the UX of tomorrow.

Feel special? You should.

But remember that every superpower has a dark side. Here’s yours: Your broad range of ideas, your imagination and your perfectionism can stop you from getting anything finished. Before you know it, years can go by without you actually achieving anything you really wanted.

Three rules to make the most of your talent

So below are three rules I’ve been learning and relearning for my whole life. They can help you use your design brain better, and make that proverbial “dent in the universe”…

Rule 1: Find and focus on the most important thing

“The most important thing is to keep the most important thing the most important thing.” Donald P Coduto (a structural engineer!)

Don’t try to do too many things at once

With your divergent, imaginative brain, you can think of twenty awesome ideas before breakfast. But even if you can imagine them all, I promise you can’t do them all.

One key reason: Work in progress is a killer. Lovers of Kanban and process optimisation will tell you: iIf you have a lot of different pieces of work in progress, your overall productivity will be lower. Why? Because of distraction/clutter and the cost of switching from one job to the other. And this applies to your brain too. Context switching is a killer if you’re trying to get anything significant done.

So if you can’t do everything, you will have to say no to lots of ideas. Steve Jobs was of the same opinion. He’s famous for saying, “I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”

Sounds hard, giving up on all those great ideas? Perhaps. But reframing can help. Greg McKeown explains this trick in his book Essentialism:” “Essentialists see trade-offs as an inherent part of life, not as an inherently negative part of life. Instead of asking, ‘What do I have to give up?’ they ask, ‘What do I want to go big on?’” That positive framing is much more exciting.

Only spend time on things that make a difference

But how to ‘pick carefully?’ It’s by no means easy. And sometimes we’re actually battling against our own cognitive bias too. One example is called the focussing illusion.

As humans, we attend to something when it is important – of course. But our brain often gets things upside down and assumes that something must be important because we are attending to it! In the words of Daniel Kahneman, the father of behavioural economics, “Nothing in life is as important as you think it is while you are thinking about it.” So check yourself. Are you obsessing over straightening the pictures, when your party guests don’t even have drinks (metaphorically speaking)? If you’re fixating on stuff that doesn’t matter, your party won’t go with a bang.

Lots of disciplines have developed methods to help you find the thing you really should focus on:.

• Systems thinkers will tell you to look for leverage points – places where small changes have a disproportionate impact.
• Lean/kanban experts will tell you to look for the bottleneck in your processes – the one area in the production line where everything is going the slowest.
• Design thinkers will tell you to hunt for your problem statement, and put it right in between the two diamonds of the design process.

But they all have core ideas in common: map out your problem space, consider lots of methods to help you articulate your reasoning, and make a choice about the most important thing to try.

Rule 2: Plan to deliver value in small steps

“There is only one way to eat an elephant: A bite at a time.” — Desmond Tutu.

Don’t try to deliver one huge, perfect, finished result

A friend of mine has worked at a giant financial services company for most of his career. He told me “I make sure I never work on a project that has more than 100 million of funding. Those projects always take years and never end up delivering.”

I consulted at the company myself, and one time I worked on a project that was very successful. The leader of that project kept the project focussed on delivering just one simple product for one single audience segment. He focussed on getting the product shipped – not perfect, but shipped. That let him make some sales, measure some data, get some feedback and show the organisation something concrete. And all that gave him the energy, insight and backing from his organisation to keep going and make something really great. He delivered, and for far less than 100 million.

Create a plan that shows how you’ll make valuable things frequently

I’ve worked with several designers who told me they do their best work when they have clear goals, scope and timelines to work within. Consider these two project briefs:

Brief 1: “Draw a customer journey map by talking to ten customers. Make something you can present to the CEO and her leadership team. Highlight practical project ideas the business could undertake, to improve the customer experience . You have 3 weeks.”

Brief 2: “Draw a customer journey map. Lemme know when you’re done.”

Which one feels like you can win at it?

Answer: The first one. Right? Because it delivers value (practical project ideas) to the real world (the CEO and team), with a specific scope (10 customers, 3 weeks).

That’s a better way to do one step, and the approach scales.

Break your work down into a series of small, concrete, valuable steps and you’ll get big things done.

Of course, for huge and amazing things, you can’t always plan exactly what all the steps need to be – design is about uncertainty, after all. A good approach in that situation is “vision and roadmap.”

• Set a vision for roughly what the outcome should look like. Put it at the end of a timeline. (That vision is a piece of tangible value already).
• List out the problems you will need to solve to move towards the solution. Dot them along the timeline on the way to the vision.
• Add effort estimates, decision checkpoints and clouds of fog if they help to convey useful detail.

And the good news: Timelines and plans themselves are pieces of value. By creating your plan and sharing it with colleagues or stakeholders, you’ve clarified your own thoughts, and taken a step towards aligning everyone’s expectations. So finish your plan quickly – it’s your first win!

Rule 3: Get things out quickly

“To achieve great things, two things are needed: a plan, and not quite enough time.” – Leonard Bernstein

Don’t let a piece of work drag on too long before you show it to the world

A friend of mine likes photography and told me he hopes to earn a living selling stock photos. I asked him if he’s sold any stock photos yet and he said no. It turns out he hadn’t submitted any. When I asked him why, he told me: “First, I am going to get good at taking photos. Then, when I am really good at it, I’ll submit some to the stock photo websites.”

The problem is, he’s not getting any thrill and he’s learning slowly. By avoiding the potential disappointment of rejection, he’s losing out on the energy he could get from selling a photo. And because he never gets feedback (every rejection comes with a reason), he’s got no way of knowing if he’s really doing it right.

In her book Grit, Angela Duckworth talks about how people who’re passionate about something gain expertise. “As soon as possible, experts hungrily seek feedback on how they did. […] experts are more interested in what they did wrong— so they can fix it —than what they did right.”

Set deadlines so you’ll share your work quicker

When will my friend be ready to submit a stock photo? Maybe never. He might get bored of photography and give up without ever sharing his talent with the world. There’s no specific event to tell him he’s ready and no urgency to speed him on his way.

To make sure you finish something quickly, deadlines can really help. For years, I thought I hated deadlines because they felt like they constrained my ability to do my best work. But they don’t really. Deadlines actually enable you to do your best work for three reasons:

1. They force you to focus on one thing. No time for that toxic context switching. You have to turn off notifications and get something done.
2. They make sure you deliver value. Setting a deadline is a mechanism for making sure you do _something. _And doing something is very often better than doing nothing.
3. They enable you to do more. Because work famously expands to fit the time allowed for it, allowing less time doesn’t make the outcome worse (within reason). And you can apply the time you save to your next project – which will also go quicker because you set a deadline for that too. More stuff done, in less time.

Look back with pride

So there you have it. Find and focus on the most important thing, then make a plan to deliver it in small, valuable steps. Set yourself deadlines so you can get things out there quickly. Then instead of feeling disappointed about what you haven’t achieved as a designer, you’ll find yourself looking back with pride.

Design activities can feel alien to engineering teams and designers can feel isolated, since they’re often in a minority. Designers with limited experience can struggle to influence team practice, or take the lead at the key moments when they should.

I did this talk with Dean Broadley to offer some viewpoints and practical ideas about how agile teams can use design and designers more effectively.

A few highlights of what we covered…

1. A case study of an organisation here in South Africa called Healthforce. They have used human-centred design to create a successful telemedicine and record-keeping product for clinics in pharmacies. A classic B2B issue: the nurses who use it every day are not the paying customers. Often this type of situation leads teams to focus on building what will impress the buying decision makers, rather than what will help the people who actually use the system. Healthforce has managed to make it clear to everyone, from their own development and management teams all the way through to the buyers, that adoption and use by nurses is key for ROI. They’ve used design to focus on that and it’s been a winning strategy.

2. Symptoms that you have a design problem. This slide got some positive feedback…

I think product teams live with these issues every day, to the point where some don’t even notice them any more. But from my perspective, (UX) Design has a major role to play in making them go away.

3. If you have too few designers, you’ll get very little benefit from them. Lining up and colouring in your UI doesn’t solve the problems above. But one junior designer will only have time to do that, and is unlikely to know how to extend the conversation in the team to anything bigger. As Dean said, imagine you’re a junior developer and you sit in a room full of lawyers, who are discussing complex legal issues all day. You’ll be battling to get them to understand the value of your software, or the importance of many key development activities you know you have to perform. You’ll have no-one to review your work or sound out ideas with. It’s not going to end well.

As John Cutler points out having too few designers actually messes up team workflow to such an extent that it’s counterproductive.

4. Design for agile means continuous discovery and delivery. And that requires conscious change. There are some good recipes for it out there. Our suggestions included:

• Draw up and agree a new process with the whole team.
• Make discovery an explicit thing with its own docs and tickets.
• Have a discovery workshop for each relevant epic.
• Have a discovery kanban board/experiment board, because your discovery tickets won’t behave like your delivery tickets.
• Have a discovery room (if you’re feeling deluxe) where the whole team can go for immersive discovery activities
• Keep each epic ticket in a special, visible location and annotate it with with links to the dashboards you’re using to measure their success.
• Declare and celebrate “business impacts”, not shipped code. Make sure teams get a round of applause when the metics show the positive growth in revenue-generating activity that they aspired to. Making these declarations into a big deal, means people won’t forget to measure continuously too.

We also touched on purpose and vision, edge effects, how to argue, the value of making artefacts and waste. Here are the slides. Enjoy.

I moderated a panel about ways that tech teams can work better at the Merge conference in Johannesburg in December 2019. It was part of the “Tech team playbooks” track.

Topics included:

• How to encourage constructive and honest communication without hurting people’s feelings
• Making mistakes, and dealing with them constructively
• Knowing whether you’re making good decisions when each outcome is too small and lag time is too big

Plus amusing detours into Gmail in North Carolina, Tastee Wheat, measuring whiskey consumption and the effects of sleep deprivation on junior designers.

The remarkable panel members: Ashi Krishnan, Warren Foxley, Ridhwana Khan, and Dean Broadley.

Here’s the video, if you’re in the mood. There’s also a transcript. Or, get the podcast version..

I touched on a few favourite topics including:

• How many UX designers it takes to change a lightbulb, and why we should be proud of that. (The answer is “does it have to be a lightbulb?”)
• Outcome over ego: Great designers work in service of the design, and the user and the outcome, not their own artistic vision.
• You can still build up a UX portfolio even when you don’t work in UX. The trick is just to do some UX things in your current role: Interview user, map journeys, identify points of pain, conceptualise solutions. There’s always something you can do. (One attendee told me, afterwards, that he’s admissions officer for an educational institution – but that he was mapping and improving the admissions user experience).
• There are couple of tips for how to handle a UX interview and a UX assignment/critique session. Jump to slides 42 and 43 for those.
• And how to get paid more as a UX designer: Learn how to talk about the financial value of what you do.

Here are the slides from the talk.

In it, I ramble on about…

• How designers think
• How to do human centred design
• What design thinking is (sort of)
• Designers working with developers
• Lean UX

It also contains a surprising number of pictures of spice racks. Like this one.

Thanks, Anne and Offer Zen, for all that generous effort. I hope everyone gets something out of it.  I certainly did.

Here’s the article…

https://www.offerzen.com/blog/why-a-lean-ux-mindset-makes-for-better-software-products

I thought I’d capture it here for you as a special treat. Donald Norman fans will love the mental models aspect. And for product teams everywhere it’s a grim reminder that you need a robust product delivery process, rather than just assuming “it’ll obviously work for customer.”

Let’s set up parental controls, kids!

The kids were turning into housebound zombies so I bought a new router with parental controls. An TP-Link Archer D7. It had an app so you could control and configure it from your iPhone.

I sat down at my computer to configure parental controls on a Saturday. The kids devices would only be able to access the internet in the evening and the morning. During the day and after bedtime they’d need to do something else. Like play or sleep.

So here we go… I enter the MAC address of my daughter’s device and click the little icon to set “Internet Access Time.”

Next, up pops a grid. Days and times. And that key at the bottom: green means “System time”. A little experimentation shows that you click on a box to make it turn green. Super.

So my daughter can access the internet from 6:00am – 8:00am and then again from 4:00pm to 9:00 pm. I save the grid. Activate the master switch and… Nothing happens. My daughter carries on consuming junk Youtube, unfettered by paternal do-gooding.

I go back and fiddle. Check again. Nope… nothing happening. It the time set right on the router? Yes. Is the MAC address for my daughters iPad entered correctly? Yes. Hmm.

I try the mobile app. It’s a little wacky… two nested clocks that I need to use to “set the effective time for this device.” But the clock reflects what I entered into the grid, and when I save my choices, nothing new happens.

I google the problem, and get a shock.

Parental controls are not working?!

I search again and again, and find frustrated forum participants moaning about how parental controls don’t work. Nor does timed wi-fi on-off. In fact, people are saying, things like “a word to the prospective buyer: better steer clear of TP Link. They really don’t work so well.”

Dismay. I just paid good money for this. I check firmware versions etc. All up to date. It’s just a bad product. And TP-Link are conspicuously silent.

I google once more in disgust and find this.

So green means “off” and white means “on?”

I go back to the grid and swap all the colours around. And lo! The internet stops and my daughter starts complaining. Well I’ll be!

Mental model

My mental model was: make the square is green when you want your child to have access to the internet. Green means go. Then my child can go go go onto the internet. The link said “set internet access time”. The key said “System time”. All pointing pretty clearly in the same direction, I think.

But the developer’s mental model was: “Colour a cell green when you want to activate the software switch that filters out internet access.” The developer was writing a feature – a filter that would be activated at selected times. When a user colours a cell green, he assumes that means they want to activate that filter. Green means activate, right? So green means activate the parental control filter. Of course.

Brain flipped? Quite.

It’s like a Necker cube. You can see it one way, or see it the other.

Except it’s fairly clear to me from the forums that normal, human consumers are thinking about it my way, not the developer’s way. Because the humans don’t give a monkeys about the fact that the developer wrote some code and that code will be activated according to a timer. They care about when the access is available (green = on) and when it’s not (white = off).

I’m pretty sure that the designer was thinking like a consumer. And the copy writer. And the product manager. And the technical author who wrote the manual.

But the developer and the tester were thinking the other way round. And once the feature had been thrown over the wall to them, no-one ever tested it with users. So no-one ever found out that there was a problem.

The moral: Quality process, always

People on product teams will see things from different perspectives, of course. But a good product process, and a good product team, will make sure that:
– Ambiguities are flagged and discussed by real human beings who aren’t afraid to have a conversation
– UX is tested with users
– User feedback from the wild is gathered and acted upon, so that your product can continually improved

Hard work. That’s digital product design.