If you’re building an innovation team and that team’s goal is to explore new concepts, test them, and pass off hopeful concepts to an expansion team, you’re going to need a certain combination of minds on that team. I call them minds because they represent styles of thinking, and because one person can be made up of varying combinations of different minds. We all have a little designer in us, or a little ideation, or a little execution. The best ideas come from knowing your minds and collaborating with the strengths and weaknesses that other people (and their minds) bring.
The Research Mind
The research mind is curious and thoughtful. It goes down rabbit holes of information, connecting dots and learning from past experiences in order to find trends or insights that the product mind can translate into features. It is comfortable scanning vast amounts of data for nuggets of actionable information, then summarizing and organizing that data. It reads quickly and communicates its findings through tightly formed theses.
The first step a researcher takes when innovating is to look at past innovators. This can be done by looking at direct competitors, then looking at how companies from different industries creatively solved problems. A cross-team brainstorming session at IDEO had members working on a handheld vacuum alongside members from a heart device team. While trying to come up with a flexible nozzle solution for the vacuum, a member from the heart device team suggested using an inflatable balloon similar to the intra-aortic balloons used in heart procedures. It was a wild idea that demonstrates the importance of cross-industry experience when problem-solving.
The Product Mind
While you may only have one dedicated product leader, you have a team of people who use products all of the time. The brain is constantly trying to solve problems based on things it has seen work in the past. When an idea is pitched, it might not fit with your product mind because you haven’t seen that work, but someone else may have. While you want someone to drive the product discussions in each meeting, you want input from the entire group. The discussion might start with ‘will this feature work’, but don’t linger there. The only way to truly know if something will work is to test it out. Product minds move the discussion to ‘what’s the quickest way to test if this could work’.
Innovation ultimately comes from creatively exploring new ideas. The more ideas that you generate, the higher the quality of the best ones. And the best ideas usually materialize towards the end of a brainstorm. It stands to reason that more people with more ideas will lead to better ideas and better outcomes. For this reason, the product mind is always striving for consensus through debate and data.
The Design Mind
Design marries building with ideation. It’s a creative mind that also thinks through the practical utility and application of a feature. It obsesses with how things work AND how they make you feel. The product mind may come up with the idea and the building mind may figure out how to implement it, but the design mind visualizes the user’s journey and experience as a whole, then translates that into mockups, wireframes, and design assets for production.
The design mind is always tending to the details. They determine the color and size of a button, the font, the drop shadow on an element, or the shade of grey when a button is in a depressed state. But they also are expected to think through the corner cases and include error handling into their UX. These skills do not exist inherently because they are designers, but are instead acquired methodically through the undertaking of design - by thinking, doing, asking, reading, understanding, and making those decisions, time and time again, until they become second nature. For this reason, designers are often able to evolve into builders or producers, while the opposite is not always true.
Need an impressive multimedia design? Check out what SF AppWorks can do for you
The Building Mind
Ideas are fun, but at some point, you have to build. While designers determine many of the details, the builders must ensure those details will in fact support the product. Building takes theory and moves it into practice, at great risk. For this reason, builders lean towards cynicism. The building mind says ‘slow down, I have some questions’. They are often uncomfortable questions that require details to be considered and scenarios to play out. This is a crucial mind in that, while it can be slow to accept change, once accepted it will keep you on course.
Builders ask obvious questions we all want to stuff away.
Which browsers will people use to access this page?
How will we protect the user data?
Where will we manage, host, and deploy the code?
These questions take pretty concepts like “this feature will sell more shoes” and bog them down with fringe cases and technicalities that will slow down implementation and poke holes in value propositions. But without this mind, it will be impossible to assess how much value an effort can produce because the effort itself hasn’t been accurately accounted for. Steadfast thoughtfulness and persistence are inconvenient at times, but crucial to the daunting challenge of making something real out of nothing.
The Testing Mind
The testing mind is highly analytical and depends on data to make decisions. Testers take nothing for granted, painstakingly documenting test cases then running those test cases repeatedly, keeping a keen eye on unanticipated behavior. The testing mind is critical at both the outset and the end of a project - at the outset, they ask what the functionality will need to do to ‘pass’ the test and at the end, they provide the stamp of approval on a feature.
To know how a test must be passed, we need to have our success clearly defined: testers don’t just seek to determine if the shopping cart functions properly from a technical point of view, but whether there is enough traffic to provide sufficient data to test.
The testing mind ensures analytics are set up to measure the results of their tests. They need to know if users interacted in the way the designers anticipated and whether the traffic expectations were sufficient to stress the system.
The testing mind might ask, early on, what success will look like in a project. This question puts expectations at the center of the discussion and aligns goals across the team.
The Selling Mind
Collaboration requires buy-in from all stakeholders. If you have an idea or a concept and you want others to participate in the realization of it, you need to sell them on it. The first rationale for this is that people invest more in the success of an idea if they feel personally invested. Giving people a chance to ask questions, bring up counterpoints, and come to the same conclusions that you have creates buy-in.
You also need to build support for your team externally so that you have the funding to keep doing what you are doing. Even if your product minds are working efficiently, churning out promising concepts that are ready for large-scale testing, you’ll need to convince people of this by showing them the results and the promise of your work.
The process of selling also helps you articulate your value proposition and validate your effort. If, when you explain what you are doing, people don’t immediately see the value, you may need to go back and explore why. If they do see the value, do they also appreciate the effort needed to create that value? Say you want to build a Facebook chatbot to reduce customer service requests for your business. You’ll first need to convince the customer service team that Facebook chatbots can in fact reduce their workload, and not increase it. Assuming they buy-in, you’ll need to convince the finance people that spending 3 months building and testing these chatbots, then training people to use them, will save money in the long run. By articulating these points, you can see where your value proposition breaks down - if the chatbots take too long to build and/or don’t reduce customer service requests, it’s time to move on to the next idea.
Innovation is strengthened by diversity of minds. When assembling a team, whether of 2 or of 20, open up a dialogue early about the different minds present at the table. Figure out your strengths and weaknesses, and which roles you believe you can fulfill with energy and enthusiasm. Then put that team to the test by brainstorming, which we will address in our next post.
We're a software development agency that does rapid prototyping and implementation of emerging technologies.
Andrew Greenstein is the CEO and Head of Production of SF AppWorks. When he’s not participating to a hackathon with his team of developers or helping clients improve their products and accelerate their innovation processes, he’s either playing basketball, traveling the world, or playing drums/piano. Andrew writes and consults on the topics of innovation processes, Agile methodologies, and design thinking.