Need for speed: Approaches to picking up the pace of development
Innovation is risky business. It is expensive and time consuming. The faster you move, the longer you can survive.
So we’re told to go faster – not just in product development, but with everything. And now there are all these ‘new’ methodologies and tools out there that are supposed to help us go fast. And those methodologies and tools are captured in so many books, videos and blogs (like this one!) that it’s almost impossible to keep track.
Lean Startup. Design Thinking. Design Sprints. Agile. How are we supposed to move faster if we need to spend days and months reading and evaluating methods? (Click here for descriptions and links to some good resources for more information.)
Even if you have time to dig deep into all of these methodologies, it can be hard to keep them straight – especially since they are not mutually exclusive from one another:
Lean Startup draws inspiration from the scientific method, Lean Manufacturing and Agile Development. Agile is an iterative approach that breaks development down into one- to two-week sprints. Sprints is the name of the book that Google just published. Sprints are like bite-sized pieces of Design Thinking – an iterative approach to innovation that relies heavily on prototypes to test ideas and learn. These prototypes are a lot like the MVPs of Lean Startup.
The good news, though, is that if you dig into each of these methodologies you’ll find they have a few core principles in common. These principles are at the heart of enabling speed:
Break down problems into smaller pieces
Instead of trying to bite off everything at once they tackle problems in bits, but in different ways. This can make things more manageable overall (think, Agile), but it also allows for a better understanding of what a “problem” is (in the case of Design Thinking, especially) or it allows red flags to be seen and addressed sooner than later (Lean Startup, Sprints).
Keep focus on the end-user
Whether it be a focus on a “customer” or a “human,” the end-user is at the heart of the process and decisions. Agile prioritizes customers in the first principle of the “Agile Manifesto.” Design Thinking is deeply empathetic, practicing “human-centered design.”
Lead with diverse and empowered teams
Going faster means having the right people in the room and empowering them to make decisions. While they all do this, Google’s Design Sprint methodology puts this front and center. The Sprint approach is prescriptive with regards to team size (seven people is ideal) and composition and calls for a “decider” to be dedicated to the Sprint.
Every organization and every project demands rigorous pre-work to think about what approach make sense (and it’s probably more than one).
Those three principles provide a great starting point to move development faster. Aside from those foundations and the methodologies they support, there are a few other key principles and behaviors that help teams go fast:
Use communication as a driving force
Good communication is like WD40 for new product development. Teams need to invest in communication early, often and after an initiative is in the works to achieve and keep momentum. It also requires communication to be different – beyond PowerPoints and Skype calls to immersive, memorable and decision-driving experiences.
Have a Design mindset
Design (with a capital D) can mean so many things but there are two parts of a Design mindset that help teams go fast:
- Deep human understanding – falling in love with the customer, even. The more understanding there is for the person beyond just a solution or a problem, the more room there is to pivot and to pivot quickly. When we understand why people do what they do, we make decisions faster.
- Pushing design beyond “minimal” or “functional.” Sometimes design suffers because it’s assumed to be only about aesthetics. It’s not, but aesthetics and usability are correlated and a well-designed experience is more likely to be accepted faster.
Be disciplined, but forgiving
This is also twofold:
- Realize that if you try a new method for your next project you probably won’t get it right the first time. Try it on a small project. It will probably be rough. Do it again. And again. Now you’ve got it!
- Once you learn the ins and outs of one of these methodologies and its associated tools, it is easy to get bogged down in the specifics (I plead guilty to this!). While it’s critically important that the terms are understood (what do we mean by “fast” or MVP? Is this Agile or agile?), try not to get so bogged down in the vocabulary that it slows you down. Find a balance.
That last point leads to one of the most important things to keep in mind: There is not a one-size-fits all approach. Every organization and every project demands rigorous pre-work to think about what approach make sense (and it’s probably more than one). That means not just thinking about which approach is right for the problem or the project but which approach is the best fit for your organization, the decision makers and the team that will work on it.
So, as much as this post is about going fast and all the ways you can get there, it’s also about realizing that sometimes you need to “go slow to go fast.”
To watch the presentation, please click the image below.
Contact us today to start a discussion.