A big part of what we do is workshops for product invention and for strategy. They’re also a tool in our work in design, communications, and R&D.
I talk with people about how these work a fair amount, so I thought I’d put my notes here.
We get involved early in projects. Our clients have very broad questions. For example, how do we maintain and build the value of magazines in an age of digital tablets; what new storytelling opportunities are there with digital media in the domain of “history”; how can TV formats take advantage of two screens now everyone has laptops or phones?
These are strategy questions, and we answer them with strategic recommendations and product invention.
Why product invention? Because strategy has to take into account three big realities:
- The material. If we’re working with a magazine, what are the existing editorial processes? If we’re working with technology, what’s new and what’s possible? If we’re working with data, what can be revealed with algorithms? The material is the clay in our hands.
- Business needs. Design is at least one third organisational change. All projects beyond prototypes are collaborative — how will people in your firm organise to support and build your product? Do you have the right capabilities, or how can they be built? Some ideas are beautiful, in theory, but a distraction for your particular company… how can you tell if it’s a good idea or not?
- People and the market. Call them customers, readers, or users, they’re all people. And human psychology is bigger than your product. People now expect to be treated as peers, and involved in the product conversation. The market has its own expectations too. A good product will market itself… if it fits the market well.
By forcing our strategy recommendations to be expressed in the form of products, we ensure they’re buildable and amazing, make business sense for this particular organisation, and take advantage of the accelerant that is the market.
We use 2 principals (from Matt Jones, Jack Schulze and me), and run the workshop over 3 full days. We prefer to use the client’s offices, and have maximum 3-4 in the room other than ourselves. These people should represent
- deep knowledge of the material with which we’re working, and its opportunities (eg, if it’s a magazine, then knowledge of the editorial process and how editorial decisions get made). This is often a technologist
- audience/market/customer insight. This is usually an editor or product manager
- the strategic aims and business needs of this project. This is generally the project sponsor
And, somewhere in this mix, the authority to say “yes.” If we don’t have that, it’s almost impossible to discover what the project is really about.
We like working with clients. Invention happens between us. Everyone asks a lot of questions. Often the stupidest questions are the most revealing.
Before the workshops start, we work with the client to figure out the brief: what the material and context is, what form the output should take (usually a presentation, if it’s a standalone workshop), and what the purpose of the overall project is. We’re keen to discover who needs to be convinced: often the ultimate aim is a public prototype… but just as often, we’re informing the strategy of the investors or management.
This brief is often revised as the workshops happen, but it’s good to have a starting point.
The format is loooose. It’s improvised jazz, with whiteboards. But there are some commonalities.
Day 1 is typically “download.” We’ll present/discuss initial thoughts, and we like everyone in the room to do some homework and present for at least 5 minutes too. Most of the day is discussion and whiteboards. If it’s ideation rather than strategy, we’ll collect as many ideas as possible. The rule is: if you say it, you have to write it on a post-it. The other rule is: you have to use fat pens. If people don’t write enough on the walls, sometimes we refuse to let them sit down.
Day 2 is about mapping the territory. If we’ve been gathering ideas, on day 2 we’ll run exercises to cluster these ideas, and sketch candidate products around them. By the end of the day, we should have a shortlist of concepts to take forward. If this is primarily a strategy workshop, we’ll be collecting principles and ways of framing the discussion as we go.
Day 3 takes each of the concepts in turn, prioritises it, and builds it into a product microbrief. We’re aiming to create 3 to 6.
Output takes the form, generally, of these microbriefs. A microbrief is how we encapsulate recommendations: it’s a sketch and short description of a new product or effort that will easily test out some hypothesis or concept arrived at in the workshop. It’s sketched enough that people outside the workshop can understand it. And it’s a hook to communicate the more abstract principles which have emerged in the days.
Often the microbriefs are used internally to kick off a project, or as the basis for a RFP or strategy document. Sometimes we need more time to produce standalone illustrations or documents for circulation. Often the project sponsor already has exactly what they need to go ahead and write their own project brief.
Or the microbriefs can go on to be built as prototypes. This is a great way to test a concept against the three realities of the material, the market, and the business. Sometimes BERG is involved. More regularly the client prototypes internally or with their digital agency.
And then there’s product invention itself. The third possible outcome is that we already know we’re going on to create something – like a film, an iOS app, or an ongoing research effort – and here the microbriefs are in the form of options in a proposal, or a roadmap. The workshop is the kick-off to a longer relationship.
(Product invention workshops are one of several ways we work. If you’d like to talk about whether these would suit your new project, please do drop me a note at firstname.lastname@example.org. We’re always happy to chat.)