I recently wrote about the process of collective improvisation as the foundation for product strategy collaborations, and I focussed on the how and why of jamming. Metaphors from niche musical genres are all well and good, but how do we apply this to cross-functional collaboration in a product and technology team that needs to build software for journalism and news publishing?

Jamming on a new product strategy for the Australian Financial Review

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, product designer, and 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 his set of tasks, go away, do his bit of the work, and eventually put it all back together at the end of the sprint. Sometimes that’s OK. In fact, it’s often how a band makes an album in the studio — with each musician recording and re-recording his 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 two-week 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 or a deep dive.

From setting out our sprint goal and the specific questions we needed to answer, we would segue into a whiteboarding session. We sketched out a bunch of different concepts for a service supporting a particular need we think is important to our audience. We looked for divergence first and listened carefully to each other’s 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 but open to disagreements — and always documenting our assumptions to test with our intended audience.

Over the next few days, there would be periods of independent work. As researcher, I would start to recruit participants and build a discussion guide. Meanwhile, my designer counterpart would start 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 times a day to review progress, sense check, and shape each other’s 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 make sure the discussion guide and the designed concepts work well together and increases the chances we get the answers we need to make 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 had a discussion guide with specific scenarios and probing questions, complementary digital artefacts participants would interact with, and a documented set of questions and hypotheses the evidence we were about to gather should help us test.

When it came time to test concepts with real members of our target market, I 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 used our wall of observations to run a collaborative synthesis session. This led to a shared understanding of what we learned and a documented set of answers and insights helping 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 so to keep track of our ideas and learning journeys rather than to manage the handoff between silos.

What do we gain from jamming?

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

1. We make sure our work is aligned and complementary so the design concepts, discussion guide, and assumptions and hypotheses to test everything address our key question for the sprint.
2. Everyone in the team 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 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 built up through collaboration to get even better at collaborative problem-solving.

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 need 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. 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.

When and how much should we jam?

Jamming — collective improvisation — is a potent foundation for really great collaboration and 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 require 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, you won’t need a hundred solo takes in the studio to get it right, nor does any one individual need to play every instrument. With collective improvisation, you’ll make sweet music together.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .