One of the questions I am often asked is, “Which process should I use to innovate?” Many options exist and it seems as though new processes pop up every year or so. We’ve had Extreme Programming (XP), then Scrum, Kanban, Lean Startup, Lean UX, Design Thinking, Design Sprints, and Jobs-to-be-Done, to name a few. Many of these processes are in direct retaliation to others. All of them have merit and work well for a given team. However, as you’ve probably discovered, the process that works for maintaining your core business is not a process your team can use to recreate or evolve innovation.
This makes sense. To achieve predictability, reliability, and scalability teams add processes that mitigate risks, helping to deliver software that can handle the load of their customer base. However, by removing this risk, teams are less likely to explore possibilities outside normal operations. Luckily your Product, UX, and Development teams can try some of these popular methodologies without impacting your delivery team.
Let’s get this out of the way: none of the above mentioned processes will solve your problem if simply executed as the creators wrote them. The key to executing on any of these processes is understanding it’s OK to adapt them to the needs of your company and team. Teams are variable and therefore must vary how they work based on who is on the team, what their strengths and values are, at what point in the product lifecycle the product is, and what the team is trying to achieve. As the saying goes, “If all you have is a hammer, everything looks like a nail.” Thus, pick the right tool for the job; don’t pick one tool and make everything fit to it.
Popular UX Methodologies
Popularized in the early 2000s with the publishing of the book by Eric Reis, Lean Startup focuses on the idea of working towards learning, rather than working towards software. Build something (it could be a process, it could be a prototype, it could be an illustration of an idea), measure how people use/interact/react to it, learn what works and what doesn’t work. Repeat. This process also popularized the term MVP (Minimum Viable Product), which is the thing you “build.” Its main goal is to help founders avoid building excessive infrastructure without validating that the problem is real and that it affects a group of people.
Adapted from Lean Startup, Lean UX is a methodology whereby product teams have assumptions about their customers or the problem, and they try to figure out which assumptions are right as quickly as possible by testing hypotheses with iterative designs, prototypes, or processes. Where Lean Startup focuses on validating whether the problem is real and if it’s worth solving, Lean UX helps teams vet specific solutions very quickly.
Design Sprints were popularized by Google Ventures just a few years ago. The process suggests that you can achieve iterative learning in one week by getting Stakeholders, Designers and Development in a room at the beginning of the week to brainstorm and collaborate, have something that can be tested with customers by the middle of the week, and execute on tests with those customers by the end of the week. Its main goal is to ensure that everyone who has a stake in the project is involved in creation, and that those ideas are tested as quickly as possible with customers.
The best way to start any of these methodologies is to get a few eager teammates who like change, don’t get married to their ideas, and feel comfortable talking to users and/or customers. Give them a few months (yes, it will take that long) and several milestones to hit. Rather than asking for specific tangible deliverables at each milestone, ask them to bring you answers to a few very important questions:
- What is the problem you’re solving?
- Who are you solving the problem for?
- Why is the problem worth solving for your business?
- Why is the problem worth solving for your users/customers?
- How will you measure that you’ve solved the problem?
There are many ways to get started, but here is an example approach to jumpstart your path to innovation. First, utilize Lean Startup experiments to understand the problem your company should be spending time on. Through experiments you should be able to learn what problems customers face, how big those problems actually are, what percentage of the customer base experiences these problems, and what makes those people special.
Next, transition into Lean UX experiments with these customers to determine what solutions will solve their problems. In this phase you shouldn’t be utilizing fully baked designs but rather executing small tests using existing products, clickable prototypes, or multivariate tests. The goal is to test as many iterative solutions as necessary to get a significant percentage of customers to convert. This will provide the answers to questions three and four because you’ll learn how likely it is that the given solutions will succeed.
After you’ve obtained a general idea as to what direction your solution should take, you can become more specific by utilizing Design Sprints. These timeboxed iterations will get your team to tangible designs very quickly. Since the first two steps will take longer, you’ll feel good about how fast these can go. By the end of this stage, your team will know how it should measure success once the idea is implemented.
Innovation happens in environments where people feel like they have the freedom to experiment and sometimes fail. When we are working on large complex software projects, experiments can seem like the enemy, or at least a distraction. By allowing a small team to have (some mildly structured) autonomy to try new things without having to worry about all of your company’s or team’s day-to-day constraints, you may find you are able to discover new, innovative ways to solve real customer problems.