Internet Explorer 11 is not supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Making City Hall Leaner

How can government build tools that people like?

Local government is learning to innovate. Over the past several years, many new approaches have been taken to bring local government into the 21st century. One of the more promising trends that we’ve been seeing is looking to startups as a source of new ways of working. This is a rich seam. Startups and entrepreneurs (or all stripes) have been challenging the status quo in industry after industry.

Now, looking to startups for inspiration is different than the older notion that “government should work more like the private sector.”This model typically compared large public sector institutions to large private sector institutions and revolved generally around operational efficiency. When one considers how slow large corporate actors have been to changes in their own industries, it becomes increasingly clear that this comparison doesn’t take us in a positive direction in terms of building a city hall (or town hall) that is innovative.

Instead, the models that have come out of the startup world have focused on creating value for customers. This is eminently useful for government where the focus has been on simply delivering services. Refocusing our efforts on adding value rather than simply getting things out the door could be the next revolution in government.

The question is, how do we do that? How do we create services that people actually want to use?

The first change is to start thinking about these services as products. What’s the difference? Well, this is where we can learn something from startups. Products are the tools that we build to deliver value to our users.

Products are typically managed by one or more product managers that watch very carefully how users interact with the product so  the startup can determine which features to keep and which to toss. We can contrast this with traditional government services which are developed at some point to solve a problem of some sort, but because they are typically not monitored in a way to understand whether these services are actually adding value, they quickly fall out of sync with the needs of people.

Consider government websites that allow people to access their benefits. These sites are typically clunky to use and hard to navigate. This isn’t a small issue. It can be the difference between people getting and not getting the resources they need to survive.

Case in point: CalFresh.

These are services.  

Compare this to a site such as Balance which was designed by watching how people use the CalFresh site, talking to these users about how they would like to access their benefits and then building a tool that actually responds to their needs.

This is a product.

So, we need to be thinking about not only what government is building (in terms of tools), but also how it builds them.

The approach to building high-value products used by startups (and other orgs looking to build better products) is called Agile.

There are many flavors of Agile, each with their own strengths and weaknesses. One of the more recent agile methodologies that has garnered support in the startup community is Lean developed by Eric Reiss in his book, "The Lean Startup."

Now, a word of caution. Any methodology that is used outside of the context in which it was intended runs the risk of simply not working. However, at its core, Lean is about learning what works and what doesn’t, so I’ll focus on the central elements of Lean since they have much to teach those of us who are working to overhaul local government about how to create value.

Lean can be boiled down to a simple three-part loop: 

This loop is driven by a process to create prototype products that are tested with users to see how they react. These prototypes, called the Minimum Viable Product (MVP), are designed to test the minimal set of elements of the product / service.

1. Build. Build a prototype to test your assumptions. This should be simpler than the full-blown service. This could mean the scope is reduced in terms of the number of people using the prototype, for example. 
2. Measure. Watch how people use the prototype and gather data about where they get stuck, what they  don’t seem to like and what they do.
3. Learn. Take the data and output from the Measure phase and tweak the prototype accordingly. Go to step 1. Repeat.

This iterative process enables the team to zero-in on tools that constituents like and will use.

This focus on usability and learning may seem like overkill, but it’s critical. For too long we in government have built portals, forms and processes for the people we serve that are hard to use and thus prevent people from doing the things they need to do. My suspicion is that this has greatly contributed to the general lack of trust in government that we see in this country. So, if we can begin to produce forms (yes even the lowly form), tools and processes that are well-designed and built in response to how people actually behave, we can begin to rebuild that lost trust.

From Our Partners