The Lean Start Up for Government Innovation
So after a very shy presence in the Internet, I was assigned to start a blog thinking in retrospect about a project where I could have learned faster, and design an experiment based on principles from the Lean Start up, a very famous methodology in the world of start-ups, that develops businesses and products under conditions of uncertainty.
But first, what is The Lean Start up and why do Governments care?
The Lean Startup model is designed to teach you how to drive a startup. This methodology can be used on any organization of any size (including governments) and basically uses the scientific method to discover and build products that people value.
The methodology insists that a team should not make complex plans (based on assumptions), but make constant adjustment with a steering wheel called the “build-measure-learn feedback loop.” (I will try to summarize this idea)
Here are some few principles that according to me can be adapted to Government Innovation: (Obvious disclaimer: These are all based on Eric Ries´ book)
- Extreme Uncertainty: Entrepreneurship/Start-ups/Government Innovation entails the creation of a new product or service under conditions of extreme uncertainty. The challenge is to overcome the traditional management thinking such as planning, since tools like that only work in the presence of stability. Start-ups, and thus innovative government projects are made under conditions of uncertainty. They simply cannot adapt to traditional tools.
2. Learn: The most vital function of innovating is LEARNING. The first question any lean manufacturing adherent is trained to ask is: which of our efforts are value-creating and which are wasteful? Learning is then the unit of progress for start-ups. Productivity in the start-up is not about deadlines, but about how much validated learning you are getting for your efforts. The concept of “Validated learning” is introduced as the progress made when important assumptions have been confirmed or refuted empirically, by one or more user validation tests. In sum, a team project should focus in what is it that users really want and adjusting the product and strategy to meet those desires. To work smarter, you have to work aligned with your user´s real needs, and focus on learning continually, with less effort.
3. Experiment with the Scientific Method but start small: Experiments have to follow the scientific method, beginning with a clear hypothesis to make a prediction of what is supposed to happen, and then test them empirically. An experiment is a first product tested with real users.
Think big, but start small. Build a product and run experiments to know the user´s demand, interact with real customers to learn their needs, and observe the user´s unexpected behavior. (Zappo Case). By experimenting, you can establish a baseline behavior that would be far more accurate than market research. An early product or service can also serve as a “seed that could germinate” into a much more elaborate service.
Figure out your value hypothesis and growth hypothesis. The value hypothesis tests whether a product or service really delivers value to users once they are using it, and the growth hypothesis tests how new users will discover your product or service.
4. Don´t be afraid to Steer toward new ideas: The beta product or services you are building are experiments. The information you receive from your tests are valuable because it can influence and reshape your next set of ideas, ideas that will eventually guide you into a sustainable business.
This part can be summarized into a three-step process: (This is the Build-Measure-Learn- feedback loop)
· BUILD a product: Ries says you should start with a minimum viable product, one that lacks many features of the final product, but that can enable you to do a full turn to the loop. A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.
· MEASURE data (from user´s feedbacks)
· LEARN and develop new ideas
· BUILD again.
An important part of this process is to PIVOT, whether to pivot the original strategy or persevere. The lean startup method “builds capital-efficient companies because it allows the team to recognize that it´s time to pivot sooner, creating less waste time and money.” The essence of steering a startup then, is to minimize the total time through this feedback loop.
Here is where the value and growth hypothesis become important, you have to figure out if your new product or service is value-creating or value-destroying, and understand the reasons behind your project´s growth.
5. Leap: Enter the Build phase as quickly as possible with a minimum viable product (MVP). A lot of successful start ups, experimented in a small scale. Zappos started posting pictures on the web and personally shopping the product after it was bought; and Dropbox used a video to demonstrate the value of their service and show people how they have a problem they didn’t know they had. By starting with an MVP they were able to test the fundamental value of their hypothesis.
6. Measure: Ries introduces the idea of innovation accounting, to establish a baseline and measuring performance to tune the engine, and pivot or persevere. Here, he expects the team to test their value and growth hypothesis. Based on the data, persevere with the product you know to be correct, or pivot and test your next assumption. Here is where the team has to ask themselves a question: “are we making sufficient progress to believe that our original strategic hypothesis is correct, or do we need to make a major change?”
As already mentioned, that change is called a PIVOT: “a structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth”. The team has to conduct regular ‘pivot or persevere’ meetings, to know where they are ging next. A Pivot, is a special kind of “structured change” designed to test a new fundamental hypothesis about the product, business model, and engine of growth. There are different kinds of pivots that can happen in a determined project. A single feature can become a whole product (zoom-in), the whole product becomes only a feature of a bigger one (zoom-out), the product can solve a problem for customers that were not on their first range (customer segment pivot), and among others, customers may guide you towards a different problem to be solved (customer need pivot).
7. Accelerate and Grow: The engine of growth is the mechanism that startups use to achieve sustainable growth. Sustainable growth is characterized by new users that come from the actions of past users, either because of word of mouth, as a side effect of product use, funded advertising or repeat purchase.
8. Incentives for Innovation: Startup teams need complete autonomy to develop and market new products within their limited mandate. They have to be able to conceive and execute experiments without having to gain an excessive number of approvals. Ries also mentions that entrepreneurs need a personal stake in the outcome of their creations, through stock options, equity ownership or simply a bonus system.
My personal FIASCO: “El expediente judicial electrónico” (Disclaimer: Since this is an on-going project, the FIASCO part is entirely the opinion of the author)
So now, I have to tell a story, and travel in my own time machine to re-design the project based on the Lean Start up principles mentioned before.
Once upon a time, there was this GREAT IDEA in a country´s Judiciary. The idea was to digitalize every case file and create a software that will permit a lawyer to manage their cases at home through the Internet. The assumption was that lawyers will value a product like that, because they will stop going to Court to check their cases, saving time and money. Similarly, the Supreme Court would have value this innovative product because it would have saved them a lot of money in human resources and paper. It was great for the environment they said…It will revolutionize the way we go to Court they said…
The idea is not bad and to be honest I still believe that this project has a future and would have been entirely different with a different approach.
Although the Lean Startup can be applied to government projects, we have to understand that such endeavors in the public sector are not only made under a condition of uncertainty, but also under the condition of bureaucracy. The problem with innovation in government is that you have to adapt survive or overcome the defects of your own public office, knowing that this can sometimes push you backwards rather than forward.
Here is what we did wrong:
OUTSOURCING YOUR IDEA…BAD IDEA:
So, the first thing we did wrong was subcontracting software developers. The IT Department of the Court did not hire developers, and ended up signing a contract (I don´t know the exact terms of it) that was either for a certain time frame or for a certain product. The wrong thing about this is that you lose full control of your product, and even your team. If innovative products and services are made under conditions of uncertainty, a team of developers working under a static contract will hardly ever be able to enter the Build-Measure-Learn- feedback loop. The subcontracted company will probably just make the product and leave, without much pivoting. Pivoting the idea will give grounds to renegotiate the contract, and we all know how evil and unproductive can be the renegotiation of government contracts. With all the talent out there, I would have never outsourced this project.
PUBLIC OFFICES DON´T KNOW HOW TO DETECT INTRAPRENEURS.
Ries talked about how entrepreneurs are everywhere waiting to solve a problem, and how they are called “intrapreneurs” in big organizations. This is definitely true, but the problem is that governments don´t know how to detect them. In organizations that are that big, there is no mechanism to detect talent. You end up subcontracting certain services, and wasting human talent, because you don´t even know it´s there.
A PROJECT WITHOUT A CHAMP:
Outsourcing the product development was bad, but I think that with a good team, one will still be able to work it out. Not us. This project was lead by the IT Department of the Supreme Court, an office that was made of 1 Director, and no more than 20 employees, who were in charge of supporting the IT network and infrastructure of the entire Court System, nation-wide. Neither the Director, nor the employees were dedicating 100% of their time to it. (no wonder: they didn´t have any time to give). The moral of this story is that INNOVATION is not something you can do in your spare time. I will definitely form a team that will work for the project exclusively (you don´t even need a big one). This is common sense. But common sense is not always part of the rationale of public offices.
STRATIFICATION OF TEAMS:
So they were basically trying to build a “legal” product and yes… you need lawyers for that. This is where my work mates and me lawyered up. Ironically, we were called the “technical team” of the project. This team was led by my boss, who was also a Judge of a Court of Appeals. The same thing happened here, we were given roles and responsabilities (in a very very hard project) while having a full time job. Our first task was to make the flowcharts of all the civil procedures so that the tech guys could adapt it to the program. We imagined every possible process and outcome out of every civil trial we could have imagined. We did this for at least a year. We then passed it to the IT guys who later passed it to the developers, who never used it. They eventually made a system that was based in an older system (entirely obsolete by that time) becuase they didn't understand how the civil procedures worked and how to translate that into a software. They spent almost three years developing a program without a strict supervision of the IT Department, or the “technical team”. And of course, this is not the outsourced guys´ fault, this is what happens when you have no champ leading a project, two champs that don´t know who´s the champ, or two champs with no time.
NO COMMUNICATION:
As you can guess, there was a tremendous amount of wasted time. The developers had no clue what exactly they were hired to do, what was the Court´s vision and which way to go forward. So they were in autopilot mode, with some sporadic directions.
NO EXPERIMENTATION:
We never entered into the quick building phase. There was no minimum viable project. In fact, the project is still in its beta phase, and the Teams are still not working with real users. Some clerks are experimenting with the software and giving some feedback, but there is no interaction with people who will end up using it (clerks will never have the perspective of a litigating lawyer). Their vision is vital for the project, and without it, they will hardly enter into the dynamics of the build-measure-feedback loop. Worse, we still don´t know if this is what users really want and if we are on the right path.
TOO AMBITIOUS:
The project was definitely too ambitious: Digitalize the entire court proceedings in a country with one of the lowest and most expensive internet connections in Latin America and with a very deep digital divide. After they realized this (and after not meeting deadlines) they made the decision to launch smaller digital applications. This was a smart move (finally!) because people will gradually get use to the digital world. But again, we did not take advantage of this opportunity. The “oficio electrónico” (electronic communication from a judge to another public office) was launched quickly, and the Court did not enter into the feedback loop. The assumption was that the product had its typical flaws but was functioning correctly, but in reality it was a mess. Some court users were provided with a quick one hour training, while other public offices were not (like the Public Registry). A lot of complaints were received, but the complaint did not reached the higher champs, and what could have been used as feedbacks to re-build and adapt the product, was wasted and kept in silence in the mind of shy employees.
We could have made up a small team of people that would have spend exclusive time on the project, but we didn´t.
We could have made regular meetings with users and with team members to talk about the direction of the project, but we didn´t.
We could have started early with the small apps, but we didn´t.
We could have listen to users, but we didn´t.
I could have stepped up and lead, but I didn´t.
We could have learned in so many occasions, we could have pivot the project sooner, but no one was working together and no one was listening. No one was directing the orchestra, so no one felt part of a team. The project couldn´t even enter the Lean phase because the team had no organizational infrastructure. We had a goal, an untested hypothesis, and no direction to get there. Logically, team members were not on board, they were just receiving uncoordinated orders.
My takeaway? First things first: LEADERSHIP. One must step up and lead. Someone must own the project to make it work. Make up a team and make them follow you. Lead, learn, direct, build, listen, pivot, persevere, and do it all over again. The problem with this project was a lack of ownership and leadership. The other problem, is that it was made in an environment (or a non-environment) that inhibits leadership: a public office. Even if someone would have wanted to assume that role, the organizational scheme of a government office would not have allowed it. There are infinite ways in which bureacracy can eat you alive. To innovate in government, you have to be insulated from the larger organizational scheme of your public office, and you have to be able to conceive and execute experiments freely without having to gain an excessive number of approvals.
I will definitely buy more copies of the Lean Start Up and take them back home.
Disclaimer: This work was done as part of a class assignment for HKS DPI-662: Technology, Policy, and Public Service Innovation — an Introduction. The opinions expressed here, if any, are solely those of the author and not of the Instructor.
