One of the things that Michael Lopp mentions in his book Managing Humans is the idea of holding a kind of brainstorming meeting with your team. I must admit, I had resisted the idea of doing this for a considerable period before finally biting the bullet. We’ve had a couple of meetings now, using my newly devised brainstorming format, so I figured it was safe to at least share my progress in this regard.
Why was it even important for me to organise some brainstorming meetings with my team? Well, for the last year or so I have been trying to hold at least a weekly product features related meeting with the core members of the product team. Originally this was envisaged as a kind of grooming meeting in the classic agile style. Because of how we currently work though, it never really worked out as I originally envisaged it. And because of my workload, the meeting often got skipped because I didn’t feel as though I had done the necessary preparation for it in advance. Indicators of a potential anti-pattern right there!
Over time, the product meeting had evolved into me doing a kind of show and tell of the features, enhancements and ideas that I was bringing to the table. All of those things were ok as far as they went, revolving around agreed upon artefacts such as the business strategy, the product roadmap, previous discussions etc. But there were at least a couple of issues that were becoming obvious to me:
Anchoring and Sunk Cost Effects
Because I was doing lots of work up-front, solutionising; any subsequent discussion was anchored to the work I had already done. What if that work was completely wrong? What if it was based on a false premise arising from e.g. a fundamental misunderstanding of the architectural choices available to us for a specific feature or component? If such an issue was identified during subsequent discussions, there would be some potentially strong resistance from me to rip up the designs and start again from scratch.
There’s also a tendency towards valuing the Highest Paid (or most senior, or the person actually facilitating the meeting) Persons Opinion (hence the HIPPO acronym) over everyone else’s that I wanted to overcome. Probably the HIPPO Effect is a bit of a misnomer for the problem I’m actually describing, but I didn’t want to get too hung up on the name. The point is, I wanted to hear everybody else’s ideas, not just my own. And the problem I was seeing was that, as the product manager – it was my responsibility to make decisions on what and how things go into the product. So if I presented a set of already more or less complete ideas and designs to the room, there was a strong likelihood that people were going to defer to my supposed authority in this matter, rather than questioning whether my approach was fundamentally the right one, or not.
So, I decided to try and address the problem by not presenting my own ideas in advance. But by presenting them along with everyone else’s in a more free-form, brainstorming style event. There was however, some degree of internal resistance to following this path.
On reflection, I think there were several reasons for my trepidation.
Reasons to be Fearful
It was a little out of my comfort zone, since I hadn’t really done a brainstorming meeting before. Though you would think, not so much; since I have facilitated a great many retrospectives and affinity mapping type sessions during which people are carrying out much the same kind of work. Still, there was some fearfulness. Mainly I think because I wasn’t sure how the team were going to respond.
Facilitation of the meeting was another question though. How do you actually go about facilitating brainstorming in a sufficiently unstructured way so as to get people’s best work out of them? I gave this a fair bit of thought in preparation for the meeting; more details on which, below.
Reflecting deeper still, I can see that another major pain point for me when taking this approach was – loss of control. Oh yes. I think a big part of me thought that if I encourage the team to do this, I will in some way lose some power or authority over the process, or the outcome, or something. A complete fiction, no doubt. But a real fear nevertheless.
This wouldn’t make much of a blogpost if I just decided to give up and carry on doing things as I always had done. So, I decided to ignore my fears, and give it a try anyway.
Since, as it turns out, I am a bit of a control freak (who knew???!!!), the first thing I needed to get a grip on was how to run the meeting. Simply turning up on the day without a plan for how to facilitate a brainstorming workshop was simply not an option for me. And, after some consideration, I decided it was time for my colleagues to “say hello to my little friend” Trello again. A simple Trello Kanban board with a backlog column, To-Do, Doing and Done constituted the framework for our initial discussion. It worked well, and the board has since evolved (after 2x meetings) to the following columns: Random Ideas, Backlog, In-Progress, Parked, Product Dev and Done – with the Product Dev and Done columns both currently empty. They may yet change and evolve still further… We’ll see.
The other tool I dug out to help facilitate brainstorming style thinking was De Bono’s Six Thinking Hats. If you’re not familiar with how the Six Thinking Hats work, the idea is relatively simple. During a discussion or creativity session, you just spend some time wearing each of the hats (figuratively speaking – you don’t actually have to go out and buy different coloured hats!) in order to think about the problem, concept or whatever it is you’re working on, from a different perspective.
During our initial discussions, we spent a lot of time looking at the objects of our discussion wearing the green and yellow hats; thinking about things from a creative and/or positive perspective in other words. How I used the Six Thinking Hats was simply to, when we arrived at a natural break, ask people to consider things from a different perspective. For example, “let’s try thinking about things from a Black Hat perspective for a while. How might the proposed solution not work well for our customers? What are the security implications?” etc.
We Have Lift Off
As an initial approach to breaking out of our creative rut, this seems to be working well. The Six Thinking hats approach to facilitating creative thinking is fairly well worn, yet sufficiently stimulating to get the desired response out of people. Particularly if they’re not familiar with the model, as was the case for most of my team. Similarly, using a Kanban board to organise the inputs and outputs for the meeting worked well. In essence, stuff we want to think about, stuff we’re currently thinking about, stuff we already thought about.
Probably over time, the approach will evolve still further. I’ll let you know about that in due course. In the meantime though, if you’ve tried to facilitate a creative discussion with your team, I’d love to hear how you went about it.
Footnote: On the subject of getting out of a rut, checkout my e-book I created some time ago with the Ministry of Testing, here: 60 Powerful Heuristics to Bust a Testing Groove WithThanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.