The power of an astute brief

 

Every design and innovation leader I know is talking about how AI might raise productivity. This concern is understandable when so many projects misfire, and even those that make it to market often involve much wasted effort. The good news is that AI will accelerate many parts of the process, from project research to concept visualisation. However, one of the most significant efficiency gains leaders can make is the very human job of ensuring their teams focus on the right problems, and tackle them in the right way.

A framing of the problem and a set of goals for the project form the core of any good innovation brief. Done well, these two things focus each project team member on the right challenge, provide a clear understanding of the problem, and offer a perspective that can guide the whole team to the solution. Done badly, they waste time and resources, fuel frustration and drain energy.

As well as providing a touchstone for the project team, a well-defined brief also helps other interested parties to understand what you aim to achieve and why – building support for the project. Good framing and goals are especially critical in new, ambiguous and multifaceted problem areas, as well as early in the process when the cognitive ‘fog’ can be especially dense.

 

Framing

The importance of a well-diagnosed problem has long been established, but it was only during the 2010s craze for Design Thinking that the term ‘problem framing’ really gained prominence. It made designers sound more strategic, sure, but what does it actually mean? And what makes me so certain that AI will never be able to take over the framing done by human beings?

Like using a camera, framing provides both perspective and focus. With a camera, we decide what angle to approach the subject and choose what to exclude from the shot. Similarly, a helpful frame provides a meaningful and action-orientated point of view on the problem at hand and, at the same time, crystallises, clarifies and organises its critical aspects. While always guided by insights gained in the past, good framing ideally provides the team with a fresh lens on the problem.

There are both hard and soft sides to framing. The rational side often consists of distilling a complex set of issues down to a few critical variables or dimensions, such as a 2x2 matrix or a mental model. The emotive side can be trickier, as it often involves articulating critical but uncomfortable personal or political issues. So, when conversations begin to get near the ‘elephant in the room’, it's best to name and claim the animal with care. Opening sentences such as  ‘It's probably just me, but…,’ or ‘You've probably thought of this already, but…’ may be best here.

Framing is an innate human ability. It relies heavily on capabilities that AI will never have: our experience, affinity, judgement and perspective-taking. Capabilities computers are inherently weak at.

AI is getting better and better at answering our questions, but it will remain our job to pose the right questions. That said, when we frame a problem, the resources we can marshal to tackle it influence how we approach it. As AI develops, it will take on more tasks in the innovation process and shape how we approach problems.

How human beings frame projects will change as teams use more AI-assisted tools. For example, if they enable the rapid generation of many options, you may decide to explore a broader range of concepts than before.

 

A structure for frames and goals

Once the problem has been accurately diagnosed and an ambition and angle of attack agreed upon, the next job is to outline some endpoints to the project in the form of goals. It’s these goals that define the size and shape of the project and are often heavily influenced by budget and timescale considerations.

Discussing goals is central to driving clarity at the start of a project, but this is best done around some clearly articulated draft goals. If the discussion is too free-flowing, and is only recorded on a few quickly scrawled Post-its, the risk of blind spots and misunderstandings is high – even when everyone leaves the room nodding in agreement and raring to go.

Over three decades and hundreds of projects, I’ve developed the following way of structuring frames and goals:

 

 

Context

Written out in a few paragraphs, this is where most of the framing happens. The paragraphs should outline the key elements of the challenge’s background. They should cover the broad business context, important drivers, why the project is being initiated and the assumptions, mental models and metaphors you consider helpful.

Those few summary paragraphs should be pithy and to the point, enabling the team and stakeholders to quickly grasp the project’s ‘why'. This is why using paragraphs is important here. Bullet points just don't cut it when building a coherent narrative on your point of view on the challenge and how best to approach it.

 

Ambition

It's always useful to distil the purpose of the project down into a single sentence. It should be concise and concrete without sounding like a vague wish. To find the right balance between brevity and detail, I typically generate a bunch of variants and, through discussion and iteration, narrow them down to the best statement of ambition.

 

Scope

This is where we break down different aspects of the challenge into various dimensions, such as: target market segments and geographies, product categories, use domains, touchpoints, business units, time horizon, etc.  Often, it’s enough to outline what is in-scope, but sometimes it’s necessary to clarify which elements of each dimension are out-of-scope.

 

Objectives

Written statements on each objective break down the ambition into the more specific goals that, when achieved, will see that ambition fulfilled. We find it helpful to start each objective statement with a verb such as: frame, discover, generate, develop, recommend, and to align these objectives with process steps.

The statements should describe what you aim to achieve – not what you will do. For example, ‘Identify three potential disruptions in our market landscape’, not ‘Analyse market trends’. Finally, try to keep the number of objectives down to between three and five – teams glaze over at the sight of a shopping list of objectives.

 

Outcomes

If objectives are the hard project goals, outcomes are the softer, often more important ones. Written statements of outcomes highlight the desired consequence or impact of the project, and often describe the shifts in attitudes, mindsets and behaviour that will hopefully drive business results. Sometimes known as success criteria, they portray what success will look and feel like.

A good question to ask a client or senior manager is to imagine you’re sitting together in two years' time: they're happy, and you’re reminiscing about the project. What changed as a result of the project? What happened along the way to bring about these changes? Encourage them to think about the impacts on themselves, on their team, and on the business.

Three examples of outcome statements:

• The executive team have had their eyes opened and their assumptions positively challenged.
• The leadership team has developed and aligned around a point of view on which categories to play in.
• The team feels confident that it has at least one compelling proposition which has the potential to generate high-margin growth.

 

Outputs

These are the specific and tangible ‘deliverables’ the project will produce, as either intermediate or final outputs. They should be as specific as possible to help you clarify with your client or your manager that these outputs match their expectations. Clear outputs help you plan the time, resources and budget required to produce them. Examples may include:

• One slide of recommendations.
• Agenda for a two-day workshop, including facilitation and summary.
• 40-slide foresight presentation.
• Presentation and half-day workshop in Seoul.
• Three digital prototypes as stimuli for consumer feedback.

 

Iterate and align

Writing down and aligning teams and stakeholders on project frames and goals is time well spent. The very act of writing what we think is clear in our heads usually highlights a few holes – then discussing them tends to highlight a few more.

It’s the discussion of goals and their collective crafting that brings clarity, rather than the goals themselves. Talking it through a few times with the team and stakeholders also helps hone a project’s narrative and iron out inconsistencies.

Once aligned at project kick-off, the goals should be made accessible in the team’s workspace so that they can easily be referred to as a touchstone for the rest of the project. Whenever I suspect the team is getting stuck in the weeds, I refer to the goals and ask if and how the current debate is helping us achieve them.

 

Mid-course correction

Often, the process of reflecting on the goals mid-way through a project highlights subtle shifts in the team’s understanding of them. As the management thinker Jon Kay put it “Our objectives are typically imprecise, multifaceted and change as we progress towards them – and properly so.”¹

If you don’t have the original statement of your frame and goals to hand, changes in objectives often morph without acknowledgement, leading to confusion. As well as helping to clarify mid-course corrections, logging revisions to project goals also helps with storytelling as you explain to stakeholders how the team progressively homed in on the nub of the problem.

 

Conclusion

Defining a project’s frame and goals is ultimately about providing your team with a useful perspective and focus. Rather than encouraging them to ‘think outside the box’, it channels their creative energies into a productive box to think within. This all requires the profoundly human abilities of judgement and leadership – skills I’m certain will remain a country mile ahead of what any AI bot will ever be able to muster.

 

Notes

¹ John Kay, ‘Decision making, John Kay’s Way’, Financial Times, 20 March 2010

A version of this article was first published on LinkedIn

---