We’re Jamming

In our Product and Technology team, our mission is to build products that create a sustainable future for independent journalism in Australia. Part of the work we do to achieve that is strategic design — we identify and explore opportunities for new products and services beyond what we have in market today.

When we’re in product strategy mode we deal with complex problems, and solving a complex problem often requires approaching it from multiple angles at once. Fortunately, we have specialists — product directors, designers, researchers, analysts, and technologists of many types — to work with.

There are lots of ways specialists can work together. In some cases, it makes sense to break up the work and solve pieces independently, joining them up when the individual specialists have done their bit. But this kind of division of labour can be risky — it can introduce or reinforce silos, and it can lead to divergent solutions that are inefficient or impossible to reconcile, especially when the problem is complex or ambiguous, and it often takes a long time to arrive at a solution.

We try to minimise those risks by applying the principle that “none of us is as smart as all of us” and working through direct collaboration. We use lots of specific techniques when we collaborate, but underneath them all is a process of collective improvisation. Basically, we work like a band — everyone plays their own instruments, together. But we don’t play pre-written music. We jam.

What is “collective improvisation”?

Probably the most familiar form of improvisation in music is when a soloist takes centre-stage while the rest of a group plays a support role. This is common in lots of musical genres — from jazz , to the guitar solos of blues, rock, and metal, and in hip hop’s freestyle rap. But solo improv doesn’t help us with our problem of getting a group of specialists to collaborate most effectively. Even when members of a group take turns soloing, the process is more like the divide and conquer silo situation we’re trying to avoid. And while solos are great, they are also often routine — they don’t diverge far from the musical structure of the song in which they’re played. When we’re trying to solve complex problems we need to open up to very different possibilities, so we want to avoid being too constrained by ordinary thinking.

Collective improvisation is different. Rather than individual players showing off their skills as they take turns in the lead, a group of musicians all improvise at the same time. This can take a few different forms. In old school New Orleans Jazz, the art of simultaneous embellishment produces a distinct sound (polyphonic improvisation, if you want to get technical) while allowing the group to stick to a pre-determined musical structure. (Here’s a cool video from the Jazz at Lincoln Centre Jazz Academy to hear and see what that sounds like.) At the other end of the spectrum, free jazz gives all the players almost complete freedom, sometimes leading to what sounds like total chaos (and other times leading to ground-breaking albums like this one by the Ornette Coleman Double Quartet).

When we collaborate, we want to end up somewhere between minor embellishment and total chaos, while still getting to new, unexpected places from our starting point. What we’re after is something more like the extended, full-band improvisation you’ll find at a live show in the (mostly American) jam band scene. Not everybody’s cup of tea, but a useful metaphor. (Full disclosure: it’s not always my cup of tea, but when it’s Phish, it definitely is.)

While these shows include a lot of solo improv — noodly guitar solos are a hallmark — the highlights are the unpredictable occasions when a single song turns into something else, sometimes for a few minutes, sometimes for 30 or more minutes. It doesn’t always work, but when it does, a band shifts gears, pivots, accelerates or decelerates, changes elevation, and locks into a new groove as if they’re sharing a single brain while using multiple bodies to play different instruments. It’s this ability to move together from a known starting point into the unknown and arrive at something magical that we want to emulate.

This kind of jamming works best with a lot of practice. I don’t mean that in the sense of rehearsals, where the band memorises and perfects music for performance, but in terms of intentionally training together to use specialised skills in complementary ways.

One example of a practice technique is a game that Phish calls “Include your own hey.” It starts out with one member playing a pattern, then each member adds to it in turn, trying to find their place in the mix without any pre-defined position to anchor them. What happens next is the cool part:

“we’re all listening to each other. Now, only when you hear that all the other musicians have stopped searching, once you hear they’ve locked in with what you’re playing, you say, “Hey!” So, since we’re still listening so intently to each other, we should all say “Hey” at the same time, but if we don’t — if someone says “Hey” when you’re still searching, they’ve basically just told you, “I’m not listening to you.” So we found, very quickly that it meant you had to always be listening to three people other than yourself. And the music, we found, improved immensely by not navel-gazing. So now the idea is, I’m not paying any attention to myself at all. I’m just responding to what they’re playing.”

With collective improvisation in a jam, what you’ve got is people who have learned their instrument, practiced like mad to get really good with it, and learned to listen to other players and their instruments. And if you do it really well, you end up with something that sounds perfectly planned, but is entirely unscripted.

How have we used this for product strategy?

Metaphors from niche musical genres are all well and good, but how do we apply this to cross-functional collaboration in a Product & Technology team that needs to build software for journalism and news publishing?

Here’s an example.

A while back we ran a series of product strategy sprints to help define a new service model for The Australian Financial Review. Our focus was on building a service model for a set of digital products to support long-term growth for the brand. The core team consisted of a Product Director, a Product Designer, and a Design Researcher (that was me). We also worked closely with our Chief Product Officer and our Head of Product Design, and brought in editorial leaders and other Product Directors as stakeholders from time to time.

One way to collaborate on a project like this would be to divide and conquer — each specialist in the core team could take their set of tasks, go away and do their bit of the work, and eventually put it all back together at the end of the sprint. Sometimes that’s okay — it’s often how a band makes an album in the studio, each musician recording and re-recording their part until it’s a technically flawless performance of the pre-written song. But product strategy work isn’t really like recording a pre-written song in the studio. It’s more like a live jam session.

In a typical sprint, our core team would start out on day one reviewing what we learned in the previous sprint and deciding what we needed to do next to answer our most urgent questions. In some cases, that meant our focus was to develop and test some concepts with people in our target market, similar to what happens in a design sprint. (And, if you’re into archival footage, you might want to check out this report from 1999 by Nightline on IDEO’s Deep Dive, illustrating the same process, currently available in part one; part two; and part three.)

From setting out our sprint goal and the specific questions we needed to answer, we would segue into a whiteboarding session. We’d sketch out a bunch of different concepts for a service that supported a particular need we think is important to our audience. We looked for divergence first, and listened carefully to each others ideas, building on them as we worked.

With rough versions of new concepts and our list of questions, we would then work together to map out how different aspects of the concept address our audience needs and work out what sort of scenario or journey we could run research participants through to test our assumptions and answer our questions. This is where we start to converge on some good candidate ideas, aiming for consensus, or for documented different assumptions to resolve during testing.

Over the next few days, there would be periods of independent work, while the researcher starts to recruit participants and build a discussion guide, and the designer starts to build out more robust versions of the concepts as stimulus for the testing sessions. But even then, we would come together at least a couple of times a day to review progress, sense check, and shape each others work. Here, everyone is playing their own instruments, but listening to the others and responding so we can move forward together.

This kind of collaboration helps us to make sure that the discussion guide and the designed concepts work well together and increases the chance we get the answers we need to make overall progress on the problem at hand. Working closely together also makes it quicker and easier to shift directions as a team when we need to.

By testing day, we’d have a discussion guide with specific scenarios and probing questions, complementary digital artefacts that participants would interact with, and a documented set of questions and hypotheses that the evidence we gathered through research sessions should help us test.

When it came time to test concepts with real members of our target market, the researcher (me) was in the room running sessions with participants, while the designer and product director ran an observation room with stakeholders beyond the core team. Every observer was briefed on our key questions, what to expect of the testing journeys, and how to capture observations on post-its. After each participant, we facilitated a post-up session where we grouped observations against our key questions and hypotheses. This gave us multiple angles on the same questions, which is helpful for digging deeper into what a participant’s words or actions might mean for us.

The day after testing, we would use our wall of observations to run a collaborative synthesis session. This led to a shared understanding of what we had learned and a documented set of answers and insights that would help us move forward in the next sprint. Because we collaborated all the way through, we didn’t have to rely on any individual to be the sole authority for any part of the work, and there was no additional effort to piece things back together at the end — something that often comes with the divide and conquer approach. And while we do document our work in various ways, we do that to keep track our ideas and learning journeys rather than to manage handoff between silos.

What do we gain from jamming?

Working collaboratively like this gives us a few key benefits that we wouldn’t get from breaking up tasks and working in isolation:

1. We make sure that our work is aligned and complementary so that the design concepts, the discussion guide, and the assumptions and hypotheses to test all address our key question for the sprint.
2. Everyone in the squad gets to be directly involved and is able to understand how and why we were doing the things we did. We decreased the risk of losing information or becoming misaligned via handoffs between soloists in silos.
3. Over a few sprints, direct collaboration helps us to work more efficiently together as complementary specialists. We don’t swap roles, and we don’t become hybrid product director-designer-researchers; instead, we learn how to listen and understand one another and to speak each other’s languages a little better, which helps us ask each other better questions, make richer contributions to the work, and push the work a little bit further, faster.
4. We also learn together what is working and not working with our techniques and activities, so we can iterate on those too, using the trust we had built up through collaboration to get even better at collaborative problem-solving.

Incidentally, listening to and learning from specialist collaborators was one of the key points of Ben Buchanan’s recent talk, “Things Designers and Developers Should Know” at Web Directions Summit. Addressing the age-old debate about “should designers learn to code” he used poll results to argue that most of us believe designers and developers shouldn’t be trying to do each other’s jobs; instead we need to understand each other’s strengths and work in complementary ways. Key to doing this is what he called the “golden rule of collaborative knowledge” and its corollary: “Learn about others as you’d have them learn about you; [and] be a guide for others to find the joy you found.”

Do we have the right band for this jam?

One of the big lessons we’ve learned as we moved from product strategy exploration to implementation with this specific project is that, to be really effective, we probably needed to expand our core team. During this project we treated a few specialists like guest musicians and others as members of our audience rather than musicians themselves, when we should have made them members of the band for the duration.

Ultimately we’re looking to create digital products, and having a technologist in the core team would not only bring in different perspectives and knowledge about the opportunities and constraints of software, but also help to build better bridges to development and delivery.

And because we’re building products for journalism, we need to work more closely with people from the editorial part of the organisation. While we made sure to include editorial leaders as observers in our testing sessions and organised end of sprint review sessions around their schedules, having an editorial specialist in the core team day to day would have brought additional perspectives on the existing product, content, and audience as well as different ideas around new opportunities.

Do we use it all the time?

Jamming — collective improvisation — is a potent foundation for really great collaboration, and for arriving at new solutions. We use it often, but not always, and we often use it in different ways.

It’s useful in short duration sessions — those jams at the whiteboard where anyone can pick up the markers and evolve the work; it’s useful in research synthesis, where multiple perspectives help to create really meaningful interpretations of research observations. It’s particularly valuable when we try to solve bigger, more complex problems, which can take a bit more time and openness to unconventional ideas.

The keys to success here are getting comfortable collaborating with people who have different skills and perspectives, and learning to listen carefully and respond constructively. When this really clicks, it doesn’t take a hundred solo takes in the studio and no one has to play every instrument to get the right sound — with collective improvisation, we make sweet music together.