Don’t do innovation projects
I should probably define exactly what I mean by “innovation projects”. I’m talking about projects where a few Designers and/or Product people get into a room and try to come up with a new vision for a product, usually with the vague aim or delivering the “best possible UX”. In service of that aim, participants in innovation projects are usually instructed to brainstorm ideas without paying due consideration to the usual constraints that apply when building products. Constraints such as technical feasibility, commercial viability and user desirability, all of which are required for a product to be successful. The idea is that if you include Engineers, Project Managers, User Researchers, Business Analysts or anyone else who might cast a critical eye over things, the ideas that the group produces will be watered down and the creativity of the group will be stifled. These innovation projects usually aren’t time-boxed, and don’t appear on roadmaps. That’s because estimates, deadlines and roadmaps restrict what can be conceived and place unwanted constraints on the free flow of ideas. Very often, innovation projects involve doing Big Design upfront, creating all the fully fleshed-out production UI mockups not to hand off to Developers to be built, but instead to “sell the vision” to Senior Management, or to “socialise” the new idea around the company.
In other words, innovation projects are (most often) those pet projects of senior people that circumvent the normal product delivery structure in a company. The logic is, “we need a completely new vision for our product, we need to deliver something truly exceptional. For that, we need total freedom of creative thought. And for that, we need to break out of the system and work on our own to insulate ourselves from any outside forces that might knock us off the path to our grand vision.”
My question is, if that’s the way to create the very best products, why don’t you do that all the time? Why isn’t that the normal process? If you feel like you need to get away from the normal delivery structure in order to make something great, then your delivery structure is broken. I will always be suspicious when 5 people come out of a room patting each other on the back, delighted with their creative reimagining of the entire product, their Sketch files bursting with highly-polished but totally untested UI designs. The first three questions to ask about any innovation project, or indeed any product proposal at all, are:
1. What problem is this intended to solve?
2. Do you have any evidence, or a plan to look for evidence, that this will solve the problem?
3. If all it took was a few brainstorm sessions to conceive this great idea, how come we haven’t done this before? How come the product doesn’t work like this already?
In relation to question 1, the goal of innovation projects is usually too vague to be really useful or measurable. “We want to create the best possible UX for our product”, or “we want to create a product that will be better than [some other product]” are typical goals of innovation projects. If the goal was well defined and understood, e.g. “reduce the time spent on the application form”, Engineers and other critically-minded analysts would be included in the process to keep it on track and in line with the business’ constraints and capabilities. As Jordan DeVoss notes in a great article on framing design problems, good problem statements are broad enough to allow creative solutions while being narrow enough to maintain the team’s focus.
In relation to question 2, rarely does any such evidence exist because the innovative idea has just been conceived. There’s nothing wrong with that of course, but I do have a problem with teams going way too far down the path of designing the new product without even thinking about how they might validate the idea. The problem is that, in order to finish their polished UI designs, the innovation team need to make a great many assumptions. If you make 10 assumptions, what are your chances of getting them all correct? Extremely low. The more assumptions you make in designing your vision, the lower your chances of successfully delivering that vision.
“Declaring our assumptions up front and testing those that present the highest risk are key steps in defining the problems a product or service team must solve. Only once we’ve done that can we form useful hypotheses regarding design solutions for those problems.” — Pabini Gabriel-Petit
Very often, if you dig into the hypotheses and assumptions behind the vision, you will find that they can be tested quite quickly without doing all that Big Design upfront. And I think the team’s time would be better spent validating their fundamental hypothesis than finishing off that beautiful Sketch file.
In relation to question 3, the answer is usually something like “we didn’t think this way at the time we built the product” or “we’ve had ideas like this before, but something more important always came up” or “senior management never backed us to do this before”. Sometimes it might be, “new information has come to light which prompted us to brainstorm ideas.” All of these are legitimate answers, but my question was loaded. What I really want to dig into is, why didn’t our normal product delivery process lead us to this solution?
In a company I worked in some years ago, we had an innovation project which involved completely redesigning the entire product, with vague goals and many assumptions. It was presented at a wider team meeting and received some praise from the audience. One Product Manager even said that “we should do this for [the product I’m responsible for].” But the product she was talking about was completely rebuilt from the ground up the previous year, specifically because it was old and creaky and we felt we could only deliver a high-quality user experience by tearing it up and starting again. The new version of that product, even though it was still an MVP, was supposed to represent the first iteration of the best product we can build.
If you don’t feel the need to change your product delivery process, but you do feel the need to side-step it every now and then to make something really special, then you are being intellectually dishonest and failing to confront a major issue in your organisation. If your product roadmap doesn’t represent the best ideas you have, the best bets you can make, and the right path forward for your product, you probably need to take a look at how that roadmap is being created. You shouldn’t need to break the system to do your best work. The system should enable your best work. And if it doesn’t, your time is better spent redesigning that system so that it can consistently produce excellent results, rather than circumventing it for one-off “innovations” that rarely deliver on their promise.
