Experiment: a day of structured brainstorming

A few weeks ago I had an idea for an exercise that our team should do, which sounds like a frighteningly corporate experience.

The idea was to do a brain dump of two things: internal, team-based improvements so we could work more efficiently, and product-facing improvements and ideas for Point.

The team was open to it, but I could sense a bit of hesitation. What exactly is this brainstorm going to be about? Do we really need to do it? If we have one of these sessions shouldn’t it be about growth or engagement or pressing product decisions?

I had my reservations as well.

The timing was questionable — should we really carve out an entire afternoon mid-week to do this type of thing? And the idea of scheduling a ‘free-flowing’ brainstorm session sounds a bit unnatural.

Regardless, we thought we’d give it a go. At worst we’d lose a couple hours, and at best we’d find ourselves with a handful of interesting suggestions.

A few hours later we came away with some of the most useful and productive improvements we’ve considered in a while. We revisited product ideas from last summer — reminding ourselves that they’re still exciting concepts — and dreamt up fascinating features for the future. We found ourselves collectively voicing a need for a bit more structure and organization in how we plan, while also considering a bit more flexibility in how we work.

We found it to be time well spent, and walked away with 5–7 internal changes, and a post-it note board full of future ideas.

In the early days of a startup you have the luxury of spontaneity, and spending endless hours imagining what your app could do.

Once your product is in the wild you’re operating at a different level. There are bugs to fix and features to build. There are users to get and investors to talk to. It’s hard to stop in the middle of a sprint and say, hey, are we working as optimally as we could be? What might we do better? What do you guys think about this crazy idea we could do in the future?

It’s hard for a couple of reasons.

First, is that mentally if your focus is on building out growth architecture for your app, you’re not thinking about how to optimize the way you plan your agenda for the month. It’s hard to shift gears so quickly, if not frustrating altogether.

The second is that even if an idea does strike you — “woah it would be so cool if our product would let you do xyz” — it’s difficult to throw it in a Slack chat. It distracts from the team’s immediate focus, and can derail the day if your comment gains momentum. This can be good in some cases, and bad in others. It can also make your team wonder — we’ve got important stuff to do this week — are you really fantasizing about these non-actionable future ideas right now?

In creating a structured time for brainstorming we were able to have an open and free-flowing conversation. We didn’t feel guilty for discussing “out-there” ideas that might be months or years down the road, and even spent time hypothesizing how they might work. We also found ourselves with a number of ideas for improving how we work as a team — ideas that otherwise may not have seen the light of day.

When building a startup it’s easy to fall into the day-to-day. Build and ship product, manage users and customers, and keep growing. As much as you want to hustle and buckle down, I think we’ve found it equally important to have days which are a bit more unstructured, and a bit more conducive to free-flowing conversation. Having your team get excited about the future and solving the frustrations they’ve had in the past is rarely a day lost.