Presenting to Align

For a recent project I was asked to propose a solution for enabling people to collaborate within a shared document space (a la Google Docs). Right away the team started talking about the various features we could add. But it’s not useful to think in terms of features so soon. When you start with features you tend to think about them in isolation, almost like objects. This perspective ignores the relationships between the features and how they fit into an overall system.

When the first thing the team does is start talking about features we can add, I’ve learned that some work needs to be done to situation those features in a bigger context. I try to do this right away, because some upfront investment here makes the rest of the project go better for everyone.

For this document collaboration project I decided to try developing some core concepts or ways to think about the problem space. I thought of each one as a sort of maxim or hypothesis that I could point to as justification for future design decisions. To develop these concepts I leaned on notes from things I’ve read about collaboration and conversation over time. Eventually some valuable ideas started to crystallize, and I formed them into the following statements, each with about a paragraph of explanation:

• Collaboration is the process of reaching shared understanding
• A collaborative document is a shared mind
• Creating choices is just as valid as making choices
• Collaboration is not a linear process
• A collaborative document is just one part of a much bigger conversation ecosystem

These statements were not meant to be irrefutable. I hoped that I could get buy-in on some of them, but I also hoped that others would start conversations that could expose hidden assumptions about collaboration in the stakeholder group.

I had never tried giving a presentation grounded in concepts like this before. I started the presentation by going through the concepts, and in the next section of the presentation I used them to frame the overall problem we were trying to solve. I felt it was important to go beyond listing the concepts, and try to immediately provide a context for their use.

A challenge with giving a concepts presentation is that the audience needs to be a little patient at the beginning while you’re planting the seeds for the discussion. When the team is used to jumping right into feature lists and solutions, spending 10–15 minutes talking about theory can be a challenge. The payoff comes later in the presentation, but you should still make sure that you keep your mental models clear and to-the-point, the presentation interesting, and that you’re being really clear about why you’re starting things off by not talking features.

I hope that presenting more of my thinking will lead to thinking being normalized as valid creative output, and increase the odds that design solutions I propose in the future will be understood and accepted.