At our recent team retreat in Colorado, I led Zapier through a quick brainstorming exercise known as a design studio. It's an organized method for harnessing massively parallel feedback from every team member in a way that can actually be absorbed. It’s a very effective technique that I haven't seen discussed online, so I'm here to share one of our secret tools!
I first ran a design studio a few years back at a workshop I organized called Toolbox. I also ran a few design meetups while the company I co-founded participated in Y Combinator's Summer 2012 session. It was a great way to validate potential designs in a fast-paced environment and I thought the timing was right for Zapier to do a session as well.
First though, let me examine the problem with traditional brainstorming techniques.
Brainstorming via whiteboards is usually seen as an indispensable technique for businesses to discuss strategy, hash out ideas, or nail to specific designs. It's even glamorized in movies and TV whenever a geeky hero has a sudden insight—they'll grab a sharpie and start writing to capture their eureka moment.
So as a remote team, does Zapier miss out on this valuable tool? Or does whiteboarding only exist amongst the select few of us that are near each other, which generates work that others dutifully execute?
It turns out neither is true. One of the dirty secrets of business (even startups) is that it's 90 percent execution and is less about inspiration or random strategizing. Constant whiteboarding is a sign of a distraction, not of productivity. Our team is comprised of "armies of one" that are responsible for generating ideas for work but most of the time are busy getting shit done.
Even worse, whiteboarding has a few flaws that make it less valuable than most people think.
One practical matter is that whiteboarding is not versioned—once you've wiped away some ink, it's gone forever. Even capturing it on your phone isn't that great, since it's never the same fidelity as the original and usually squirreled away on a single person's device.
Another problem is that whiteboarding is often very single threaded. The format is single participant and many listeners, which isn't the most conducive for everyone expressing their opinion.
The worst aspect of brainstorming is a cognitive one: if everyone has a Sharpie and is working together, it still doesn't solve the problem of groupthink, since they're working on a single whiteboard to create consensus around a lowest common denominator.
There's even research studies backing this up—groupthink is the typical team dynamic and the results are inferior to solitary thought by individuals.
So what's the solution? It's a simple exercise that requires notebooks and pens, a stopwatch and a few ground rules.
Any solution to replace whiteboarding would have to improve upon it and have the following goals:
On a Sunday afternoon, I acted as moderator and fired up a short Keynote presentation to explain the overall goals and format of the design session. I listed a handful of topics that had been floating around as potential projects and we voted for the top three that we thought were most immediately relevant to our company goals.
Then, our 10 person company split into three sub-teams to tackle each of the projects. From there, we went into a highly structured session of sketching and brainstorming. Here's how it worked:
We did three rounds of activity. Each round was 10 minutes long, with 5 minutes of sketching designs on the pads and 5 minutes of discussion.
Here's the really important bit: every round has a different format of sketching:
Every person sketched silently by themselves, without talking to anyone, to get out their initial ideas. To help them come up with several concepts and not get locked into a single approach, I had everyone do what's called a six-up by dividing their first paper into six evenly-sized boxes, which they had to try to fill up with as many different concepts as possible.
Then at the end of the 5 minutes, each subteam got 5 minutes total for each member to take a minute to describe the various ideas they had.
The focus of this round is divergence—to come up with as many different approaches as possible. Three team members all drawing six thumbnail sketches each pretty much insured that there would be at least a few surprise curveball ideas.
Everyone went back to 5 minutes of sketching alone without talking again, but this time with new instructions: they were required to steal at least one idea from one of their team members that they had just heard about.
Then the subteams got another 5 minutes for everyone to share their work. The focus of this round was to begin to switch from divergence to convergence - to start picking the best ideas from the crop and evolving them.
In practice, the ideas are firing rapidly and it's hard to get people to shut up at the end of the 5 minutes to move on to the next round. That's a good sign! It means the ideas are flowing.
For the final round of sketching, the sub-teams now had a new task. Instead of sketching individually without talking, they had to do the exact opposite: now they had to sketch a single set of interfaces as a group and talk their way into consensus.
Then the sub-teams all presented to the other sub-teams and got insights into the different projects everyone was working on.
We found that people naturally and organically gravitated towards the sub-teams where they had been thinking about the most. For example our support team had a lot of thoughts to share about our onboarding process, the developers clustered together to talk about the platform for third-party integrations, and our marketing folks tackled app discovery and exploration.
So it ended up that there was at least one person on each sub-team that will go on to work on implementing ideas on the related project.
Our team members seem to really like it, too. "It was a fast and effective way to braindump a ton of information pretty quickly and also reach a broad consensus at the same time," said our CEO, Wade Foster.
So that's how you run a design studio! Feel free to ask any questions in the comments if you want to run one with your team.
99% of the time buying is the best decision for a startup. That may be a slight exaggeration, but the sentiment is true.
For instance, a startup would be silly to not to pay for an email service like Mandrill, MailGun, or SendGrid when it comes to sending transactional email. Or to slap down $40/mo for live chat on Olark rather than building their own live chat. Probably.
But rather than just defaulting to slapping down money on a commercial solution it makes sense to think about whether or not buying really is the best solution.
At Zapier we use two pretty simple rules to decide whether we should build a solution or whether we should buy a solution. Both conditions must be true for us to build.
Zapier makes it really easy for non-technical users to integrate over 100 different web applications. Because Zapier is a broad utility we attract a diverse user base that is solving vastly different solutions.
This presents unique challenges for supporting diverse use cases and for communicating with diverse users.
There are lots of nice help doc, knowledge base solutions. All of them are static and aren't easy to bake into our own product. Because we need to support n^2 support instances where n equals the number of services we support, we need an easy way to dynamically change the help docs presented to the user in the core application.
No one will likely build that solution except us. That solution allows our users to more easily support themselves and drastically cuts down the time we spend on support.
There are also a few nice drip campaign solutions out there, but we found most of them (at least at the time) have limited segmentation features, were unreliable, and didn't give us the control we needed for who we send email to.
So we built a simple drip campaign tool in Django that lets us segment off any piece of information we have in our database so that we can send the right emails to the right customers at the right time.
Note from Bryan: We're planning on open sourcing the Django drip campaigns soon!
Given the opportunity I'd much rather buy. We spend money on more than a dozen services each month like live chat, help desk, forms and more just because they get the job done quickly and easily and we can spend time on other things that better enhance the value of our company.
Given the opportunity buying is likely the best solution for the rapid pace at which startups need to develop. Rather than just defaulting to that though, think for a few minutes about what your situation is and whether building might make sense.
This morning we are super excited to announce the launch of the Zapier developer platform. Service providers already building on the platform include HubSpot, Podio and 12 others (see below).
The Zapier developer platform lets users and vendors easily add their own apps to Zapier instead of waiting on us to build them out. App developers can instantly hook into the 60+ apps we already support plus any new ones added by building one integration rather than building out all those integrations themselves.
This saves app developers weeks to months in developer time building integrations and lets an app developer spend more time focusing on their own apps.
Building a product from scratch that will support you, a co-founder and your collective families is hard. Really hard.
One of the most comprehensive guides I have seen for doing this is the Thoughtbot Playbook which covers building and growing a product from start to finish.
But after reading a playbook like that you can easily be overwhelmed. After all the playbook has 60+ steps and each step is quite easy to simply not do at all.
So the instinct is to pick and choose articles you see on HN and imitate the darling tech companies we know. Eventually ours brains are stuffed with things like:
All good things. But if you're a two or three man startup with zero customers none of this matters.
So how do you get to a point where these things matter?
This advice has been beaten like a dead horse, but I still see startups every day trying to over optimize their startup in the beginning for scenarios that may or may not ever exist.
[Sidenote: Are we really sure that the process we are trying to optimize can't scale? Zappos managed to scale personalized customer service which I never would have thought to be possible. So maybe some things that feel like they can't be scaled actually can?]
Instead do things that help you learn more about your market. Learn about your customers. Learn about how your business might actually work.
At Zapier we had a guess based on building our own web apps and conversations with a few people who used multiple SaaS apps that integrations might be a pain point. Past that we didn't know much.
It would have been easy to build our version of the ultimate integrations machine. But from the very beginning we insisted customers be a part of the conversation.
So we added Olark to our site and we started chatting with users who somehow stumbled across our site. We had one conversation, then ten conversations, then a hundred conversations and we started realizing that our version of the ultimate integration machine isn't what was needed.
The conversations were so valuable that we ended up sending over 25,000 messages to users before we launched while trying to get feedback by iterating on problems and features, and taking conversations to Skype where we could hand build integrations for first time users.
Our vision of the ultimate integrations machine turned into a simple way for businesses to create an integration between 48+ web apps and automate their businesses.
We might have eventually figured it out ourselves, but thousands of conversations with users made it way easier.
So for us doing things that seem to not scale was the most efficient way to build our product. Maybe it will be for you too.
Get new articles about productivity, company building, process delivered to your inbox once a week.