In this two-part series, Jay Dawkins, co-founder at PublicInput.comtakes a practical, local government-focused look at the design and development process for organizational innovation.
It’s a challenge familiar to everyone who cares about innovation and improvement in the government and civic space:
How can I make my organization more nimble and ready for the ever-changing demands we face?
But despite near-universal support for innovation, the friction inherent in large organizations can be difficult to overcome.
The high cost of iterating slowly
At PublicInput.com, we recognized this ‘slow = expensive’ problem early in our development of community engagement software. We’d uncover dozens of new customer needs each month, many of which didn’t have an obvious solution.
The times that we relied on intuition to pick a solution, then spent weeks building it, often led to solutions that only partly resolved the problem. What’s worse, sometimes we’d learn software development wasn’t even needed.
We realized, as many organizations have, that pursuing a solution that hasn’t been tested means betting hundreds of hours and thousands of dollars on already knowing the right answer.
Sometimes, we’re right. But other times we don’t see the full picture until months down the road, when we’re shorter on budget and facing a pile of unforeseen challenges.
Sound familiar?
Borrowing lessons from the private sector
Thankfully, this isn’t a problem limited to the public sector. Minds from every corner of the working world are wrestling with how organizations can adapt and iterate more quickly.
From Clayton Christianson’s “The Innovator’s Dilemma” to Eric Ries “The Lean Startup,” many entrepreneur fan favorites speak directly to the challenges inherent in solving hard problems through organizations.
The core lesson? Apply a more rigorous process that mirrors the scientific method: Define the problem you’re addressing, hypothesize solutions, and test solutions before throwing increasing time and money at them.
Oh, well that’s easy to do, right?
What sounds simple at first glance – let’s test new ideas! – can actually become very difficult if there are more than a handful of people involved.
Brainstorming isn’t the answer
Most leaders are smart enough to realize that solutions are not limited to the domain of the geeks. Intuitively, they look to convene the staff members from the various departments to discuss the problem and identify potential solutions.
But somehow, this well-meaning gathering tends to lead to more complexity. During the discussion, multiple new issues are uncovered, strong personalities drive the conversation, and little gets accomplished.
Weeks go by, ideas lose momentum, and the problem remains unsolved.
Agile development isn’t the answer
I know, I know. A software developer speaking against agile development? Before anyone jumps to conclusions, it’s not the process that is flawed – it’s the fact that software development is often not the answer.
In the words of Dan Markovitz:
If you have a broken process and you add technology, all you get is a faster broken process.
At the core of many problems we try to solve is an underlying non-technical problem. One needs look no further than America’s healthcare situation to see systemic problems that persist despite heroic technical efforts.
In the local government space, the trend towards Unified Development Ordinances arose to overhaul planning policies rather than streamline old ones.
Even if your problem is purely technical, software development is still a very expensive way to test ideas and arrive at insights.
So how do we move more quickly?
Jake Knapp, the creator of Google Ventures’ Sprint framework, is no stranger to agile development or brainstorming. As part of a strategy to drive innovation and new ideas, he set up numerous ‘structured brainstorming’ exercises at Google in the late 2000s.
Through that experience, he saw that brainstorming missed the mark when it came to driving new ideas forward and delivering solutions. So Jake set out to study and test over 300 different design thinking and strategy exercises from places like IDEO and Stanford d.school.
Introducing the Design Sprint
What emerged from his team’s research and testing is a process called the ‘Design Sprint’. It’s meant to help teams answer critical business questions through rapid prototyping and user testing.
It is not to be confused with the Agile Development ‘Sprint’, which is primarily focused on actual software development. A ‘Design Sprint’ involves little to no actual development or implementation of new tech or tools – it’s made to skip those steps altogether to arrive at new insights.
(Graphic courtesy GV)
The Sprint is typically a 5-day process, but can be shortened once you’ve gone through it and familiarized your team with the core concepts.
Five days?!
Sounds expensive right? Not if you consider the implications of building and deploying solutions or ideas that miss the mark completely.
But it’s important to ask a few questions before launching into a sprint:
Does this challenge require a cross-functional team to solve?
Is this a problem worth investing a week of time to solve?
Are potential solutions to this problem resource intensive?
If you answered yes to each of these, a Design Sprint is a great way to address your challenge.
The Design Sprint Process
The Design Sprint has five key phases:
– Understand the problem
– Sketch solutions (Diverge)
– Decide on solutions to test (Converge)
– Build a prototype
– Test the prototype
Eager to learn more about the Design Sprint Process? In our next post, we’ll review these steps, and the specific elements of the design sprint you can apply in your organization.