When Brainstorming Goes Wrong
Okay go with me on this for a sec… If you’re our client, we don’t need your solutions and we don’t want to brainstorm with you. How’s that hit you? You might be thinking is “wow that’s arrogant! Make your own product, why don’t ya?! Isn’t my idea for my product the whole reason I want to work with Ovyl?” That’s fair, but hear me out.
Do what only you can do
Ovyl’s whole value proposition is that we create solutions; the right ones. We offer businesses an instant team of experts across the suite of disciplines needed to develop high-end high-tech devices. You might have some serious technical chops you’d like to put to use, but we work with all kinds of clients, with all ranges of technical skill, and we’ve found that we can get good outcomes for them all, regardless of the client’s contributions to idea generation. Don’t read that to imply we hate client involvement, though. We love it and we need it! There’s a crucial project role that only you, our client, can perform. You have to know and communicate your problem. Every single interaction you have with our project team should be centered on mapping your problem space, and getting that map into our heads. All of us can generate potential solutions, but only you can choose the problems to solve. As we produce solutions, your job is to compare them to your problem space, and flag areas that wouldn’t yet be solved by them. That feedback loop is part of how we internalize the problem set. (If you’re actually not 100% sure you have a handle on all moving parts of the problem space, we offer design strategy and research services that can help fill those gaps.) The issue I’ve seen in brainstorming with clients is that it distracts from that critical role. Time spent talking about how to make it work is time not spent talking about why to make it work.
The right kind of brainstorm
When most people brainstorm, they typically aim to walk out with The Key Idea that becomes The Killer Solution. I call this ideative brainstorming. We do this all the time internally, but counterintuitively, this is what I’m suggesting we should not be doing together. You may now be thinking “I’ve been working on this problem for years, and have a lot of ideas and I think I have a lot to add here. Am I just supposed to shut up and keep that to my self?” Nope! You’re not. Here’s all I ask: Let’s treat your ideas as a way for us understand your problem space as well as you do. Until we do, we can’t give you help that meets our standards. I know I came on strong with all that we-don’t-want-to-brainstorm-with-you talk, but there’s actually a type of brainstorming we should do with you. I call it Didactic Brainstorming.
How it plays out
Because the goal is different, Didactic Brainstorming won’t feel like brainstorming sessions you may be used to. For example, imagine we’re working together on a remote patient monitoring device for hospitals. If you suggested we use cellular tech to push data to the cloud you wouldn’t hear, “Okay! We’ll can talk to some carriers about setting up a plan, and we’d have to keep the data packets small to keep data costs low, and we’ll want to use an FCC pre-certified cell module etc”. That’s all how. We're good at how, but it's not time yet. Instead you’d hear, “Interesting. What, in your mind, is better about cellular than wifi for this?” to which you might say, “In our field observations, spotty wifi was one of the most-cited frustrations that our users have. If it’s too unreliable, they’ll just abandon the device altogether.” That’s why! See how much more we get out of that? Insanely more! That gets us closer to the right solution, which may or may not involve cellular. With Didactic Brainstorming it doesn’t even matter that much if an idea someone proposes is physically possible. “Magic wand” solutions can be just as instructive as realistic ones. If you said, “People just hate fiddling with these things! I wish there were a way to just snap my fingers and set up all 50 devices in the facility…” it could spark some solutions on our end, like using RFID or QR codes for serializing and tracking devices.
This kind of brainstorm is about communication, not ideation. Success isn’t measured by the great ideas we walk out with, but on the clearer understanding of the problem we walk out with. No ideas are accepted at face value or treated as a dictate. Instead they’re examples that help us trace the silhouette of the problem set. They’re a a conversational prompt that helps us to talk about abstractions in concrete terms. Didactic Brainstorming is something we really enjoy doing with our clients as long as the goal is clear: Communication, not ideation.
Even if we end up eventually agreeing that your original idea is the way to go, it’s not that we wasted time re-tracing your steps when we should have just trusted you. To really do our job, we have to get there by the same logical steps you took to get there. It’s like a doctor listening to your description of what hurts where (of which you are The Undisputed World Expert), but still needing to make her own diagnosis and prescription, even if it ends up being the same medication you googled. Anything else would be malpractice. Walking that path to your solution is the real value, so much so that the solution becomes nearly incidental. Many problems seem to solve themselves once they are deeply understood. Our team absolutely, positively must inherit our own understanding of your problems and take ownership of the solutions so we can lead them through the maze of additional problems and solutions that is product development, and we can’t do that by taking your word for it. It’s also worth noticing that if you are consistently coming up with better solutions than our whole team, either you’ve missed your calling in product development (and we’d like to offer you a job), or more likely, it’s because you still understand your problem in ways that we don’t. That’s a signal that we probably have more to talk about.
Wrapping up
To be clear, we don’t run “Didactic Brainstorming Sessions”. It’s just one of many communication tools we use to extract problem nuance from our clients, and it usually ends up peppered into meetings ad hoc. I write this because it’s really important for everyone in the room to recognize when it’s happening, and acknowledge its purpose so a problems-conversation doesn’t devolve into a premature solutions-conversation. If our client starts to rev up an ideative brainstorm with us, we’ll morph it into a didactic one to keep it about why.
Now, If you read all of that and are left thinking, “I really just need someone to make the design in my head”, then there are way cheaper options than Ovyl. But if you need an instant, cross-functional team of tight-knit experts, who can really understand your problem space and guide you through the labyrinth that is product development, we’d love to talk.
