Search results

Brainstorming by transposing patterns from one category to another

by Tom Johnson on Oct 19, 2018
categories: writing

Last week during an internal writers conference at Amazon, Carla Johnson (co-author of the Experiences: 7th Era of Marketing and other books) gave a workshop that ostensibly was about how to create more persuasive pitches for change within an organization. But what resonated with me a bit more was the novel technique for brainstorming by transposing categories of experience, which despite my background in literature and writing, I had never encountered.

The brainstorming technique

The basic idea is that patterns you observe in one category can be transposed to another category to create a new way of seeing that category. It’s difficult to explain the technique without an example, so here’s what we did in the workshop.

First, we established an objective. For this scenario, our objective was “to get 100% responses on technical reviews.”

She started out by telling us to write down, on sticky notes, all our observations in a coffee shop (for example, empty coffee cups, baristas calling out names, seniors chatting in a book club at a table, people standing in lines, etc.). In our group of six, we generated approximately 100 sticky notes full of observations.

We then arranged the sticky notes into various groupings (affinity diagramming). Some of our piles were “furniture,” “people,” “merchandise,” “gross things,” “noise,” etc. These were essentially the patterns within the coffee shop experience.

We then created “How might we …” questions for each of these patterns, transposing the details in the coffee shop to our original objective of getting 100% responses on technical reviews. For example, with the furniture category, we asked “How might we make the review process more comfortable for reviewers?” For the noise category, “How might we eliminate the noise in the process to help reviewers focus on the parts of the document that matter?” For the gross category, we asked, “How might we eliminate parts of the review process that people dislike?”

Can you see how we used the patterns of experience in the coffee shop to look at our technical review situation with new eyes?

Next, we chose the most interesting “How might we …” question and worked out a possible answer. We decided to focus on the question “How might we eliminate the noise in the process to help reviewers focus on the parts that matter?” We decided that providing checklists for reviewers to focus on during the review would help eliminate the noise (in this case, noise is the extraneous content not essential to the review, such as content that doesn’t need review). The checklists might be specific areas we want the reviewer to focus on, or questions we need answered, or areas we’re particularly unsure about. Additionally, we decided that in document reviews, we should highlight the content we want reviewed.

Now that we had our idea worked out, it was time to pitch it. Carla recommended using the familiar story of the coffee shop as a bridge to our pitch. She said that while people want evidence and data, it’s better to start with a story first, as it helps fire dopamine in the brain before first, and then lead into the evidence (which triggers cortisol).

Our pitch was basically this:

I had some experiences in a coffee shop last week that gave me an interesting perspective related to our objective to get 100% responses on technical reviews. When I went into the coffee shop, I was a bit confused about where to stand, by the noise and variety of coffee to select from. It seems like there are 17 different flavors of coffee! And the sizes have unfamiliar names too (Venti, Grande, etc.). Overall, it was a bit chaotic. It would help if there were more guidance in the process of simply buying coffee — clearer lines, maybe some coffee specials and recommendations (and possibly fewer choices), and an easier way to see cup sizes and names.

And I thought, you know, the technical review process is kind of like my coffee shop experience. Reviewers are often given many pages to review, and it’s not so clear what to focus on, or what you expect them to do, how much they should comment, and when or how. The reviewers need more guidance — like a checklist of what to focus on, and highlighted parts of the document to review. For example, we could highlight parts of the document and add little questions we have as comments for them to answer. In this way, they’ll have clearer direction about what to review and how to do it.

Here’s the process depicted in a quick graphic:


Interesting, eh? I don’t make many pitches, though I think I’ll try this out when I do. I’m more intrigued by the idea that the observations in one experience (a coffee shop) can be extracted into higher level patterns that you can transpose on a completely different domain (technical reviews) to see it in a new light.

One guy was skeptical in my group about the need for this roundabout brainstorming approach. He asked, Did we really need to start with the coffee shop to brainstorm ways to improve the review process? He didn’t think so. Personally, I’m not sure. I think the process did get us thinking in directions we might not have considered otherwise.

The larger questions is whether there are unseen connective themes that undergird a wide variety of experiences. For example, in almost every experience, we might end up with a few archetypical categories — gross things, comforting things, people, and so on. Perhaps these archetypical categories could be converted into a rubric of questions so that you don’t have to start with the 100 observations on sticky notes approach? Even so, this brainstorming technique is a new one that I’d never encountered.

As for the pitch strategy, I honestly don’t make enough pitches to know how well this would work. For example, with the plan to get 100% technical reviews, I don’t need to pitch this idea to anyone. I’m simply going to implement it the next time I ask for a SME to review my docs!

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.