The Product Model in Government
By Marty Cagan and Stacey Langer
Marty’s Note:
This article continues the series probing the edges of the product model. In the last article we discussed what aspects of the product model apply to Traditional IT organizations. Here, we explore the product model as it applies to technology-efforts run by governments.
My co-author for this article is the transformation coach Stacey Langer. I profiled Stacey as an example of a strong product coach in the new book TRANSFORMED. Stacey has helped several different organizations over the years, including within government, either as their product leader, or as an external product coach.
Overview
Many people assume the product model is not applicable to governments because governments are not trying to make a profit. But the product model is all about creating value and achieving outcomes, and in fact aspects of the product model have been successfully applied in parts of at least several governments over the last decade. 1
Profit is just one way of measuring value, and the desired outcomes can vary based on the mission of the organization. If you can help people improve their lives – helping them to file claims after a natural disaster, or to access health care benefits, or to register to vote, or to renew their passport, or literally hundreds of other services – that is providing real value.
Similarly for businesses – helping to apply for small business loans or disaster relief, contributing to social security benefits and retirement plans for employees, and making it easy to do regulatory and compliance reporting – that is also providing real value.
While the government may not be trying to maximize profits, they do strive to maximize their positive impact – which requires a clear focus on outcomes. And with governments, output that doesn’t yield the desired outcomes is sometimes quite publicly criticized.
More generally, waste is bad everywhere (and all too common in large commercial enterprises), but it can be especially painful when that waste is funded by taxpayers, or when that waste impacts critical and urgent needs that people have, such as essential health care for a veteran.
Which is all to say that it’s no surprise that methods and techniques which hold the promise of improved outcomes and reduced waste would be very attractive to government agencies trying to carry out their missions.
Yet, just as with the discussion regarding Traditional IT, the product model came from product companies, and not government agencies.2 So there are some significant differences in context that need to be addressed in order to successfully apply the product model.
Government’s Advantages
When applying the product model, there are several factors that exist within government organizations that can help set the product operating model up for success.
Mission-Driven Organizations
While this is not true for every government employee or contractor, an advantage that most government agencies have is that they are typically staffed with people that genuinely care about their mission and those they serve – whether that’s defending the country, serving the community in times of need, providing health care, or helping small businesses.
When the leaders of government agencies and product teams tap into this passion for mission, especially with a compelling product vision, it can be truly inspiring to see what they can accomplish.
Public Focus on Outcomes and Avoiding Waste
As discussed above, there is a very public focus on outcomes, often under the watchful eyes of government oversight bodies, the press, or government watchdog groups.
Whether or not a particular service is something you personally care about, most people want their taxes to be well utilized in the delivery of meaningful benefits and services.
All of this contributes to the dynamic where, with government services, if we can meet or exceed the users needs, we make a better use of resources, and sponsors and stakeholders look good as well.
Captive Audience
In the vast majority of cases when it comes to government services, there is very little competition, other than choosing to simply not engage with the technology. In some cases, you can choose to visit an office and try to speak to a person, but in most cases, you don’t have to worry about being a better solution than the competition.
That said, just because you may not have competitors, does not mean that you don’t need marketing. In many cases, the government needs extensive and effective marketing to reach the intended audience, and inform them of new capabilities and services.
Government’s Challenges
While there are some significant advantages in government organizations, it’s no secret that there are also some very real challenges:
Viability Risk
Understanding what is necessary to meet the needs of those using the services is usually not the most complicated part of building government services. The hard part is doing this in a way that is viable.
Assessing for viability in government includes factors like legal, policy and privacy considerations, security constraints, costs, and especially ethical considerations. For each of these factors, there is generally a very high bar to meet, complicated by often varying perspectives on what is actually required in each to be viable. Understanding and determining how to handle all of the relevant constraints can often take significantly more time than defining the desired experience for users.
Assessing for viability can also be complicated by less experimentation or iteration in government delivery. There can be many reasons for this ranging from antiquated practices and policies, to big contracts with outsourced technology teams, to the real need to address all of the use cases, including edge cases.
Fraud Risks
Fraud risk is really part of viability risk, but it’s so important for many government services that we think it’s worth calling out:
Since government services apply to such a large percentage of the population, and because the government is generally considered a trusted entity, this creates strong incentives for scammers and other bad actors to try to mislead people and small businesses into thinking they are engaging with official government services.
This impacts not just the services that need to be designed and created, but also more generally the efforts to educate people about how to find and engage with official government services, and how to detect and protect themselves against fraud.
Project-Driven Procurement
Unlike the private sector, a surprising number of obstacles to the product model within government lead back to procurement processes. It can be helpful to realize that something like contracting with a construction firm to design and build a bridge, is very different from finding a partner to design and build (and run) technology-based services.
For many years (and in many cases, through today), governments managed procurement for technology in the same general way they managed procurement for physical goods like bridges or battleships. This was, in fact, the origin of the waterfall/stage gate/phase gate product development processes.
The vestiges of this legacy are everywhere, and are at the root of much of the waste and failure to deliver the necessary outcomes for government (and commercial) systems.
In many cases, to scale and deploy a system to potentially tens or hundreds of millions of people, it can make sense to work with a technology partner. This happens every day in the commercial sector, but it’s not hard to see the potential for corruption in the public sector, and the reason for many of the safeguards that are in place to prevent abuse.3
This same abuse can and does happen in the commercial sector, but the damage is usually limited to that company, and they end up suffering the consequences. This is a much more serious breach of trust in the public sector.
In the sections below we’ll discuss techniques for changing this dynamic for work built under the product model, but it’s essential to understand the legacy and reasons for the pressure to manage work as large projects.
Stakeholder Complexity
Because of the viability challenges alluded to above, in many government technology efforts there is an extensive list of key stakeholders. Lots of people that can say no, but few that can say yes.
While this is always a challenge, given the sheer number of stakeholders and the often complex and confusing constraints, sometimes encoded in law, sometimes in policy, and sometimes just in the heads of key people, it’s not unusual to find teams approaching exhaustion. This can be complicated by various stakeholders who may hold out-dated views on what a particular regulation or policy requires.
Several of the techniques highlighted below are intended to help mitigate this issue, but it’s fair to say that skills for partnering with stakeholders are especially important to succeed in government agencies.
Staffing Models
In most government agencies, there are three types of staff when it comes to the people that design and build the technology-powered products and services: government employees, government contractors, and third-party outsourcing firms.
This is always an important topic when applying the product model, but the impact is magnified on these systems, and it’s also important to realize that we need to pick our battles. Yes, we’d likely prefer to have our durable product teams fully staffed with government employees that are passionate about the mission.
We do want to point out that there are an increasing number of cases where this can actually happen, mainly because creating certain types of technology-based solutions can be done with very small teams of people (we discuss this below). But that is unfortunately not true with everything.
Our second choice is government contractors. These are typically long-term (greater than a year) staff that may work for a third-party staffing agency, or they may be independent contractors. These people can often make excellent product team members, especially when they are passionate about the mission.
Our last choice is third-party outsourcing firms. The main difference here is that you’re not contracting individual members, but instead you are handing over entire projects, or large pieces of projects, to another company.
This situation can be difficult to avoid, but makes the product model very difficult to apply – it’s tough enough to apply the model to your organization, but to try to insist it be used in a different organization is even more challenging. But even here there are techniques that can increase your likelihood of success.
Techniques for Success
The challenges described above are significant, but there are some powerful techniques that can help you deal with the challenges.
Centering on Users
One area of agreement that usually exists between product teams and stakeholders is a genuine interest in improving the lives of the people they serve.
Tapping into this shared mission can be a powerful way to gain alignment and create momentum. Start by spending time with users, understanding what is working – or not – in their current interactions. Bring in stakeholders to either engage with users with you, or show them what you are learning from users. The focus here is on creating shared advocacy for users, not in pointing out everything that is wrong.
If product teams and stakeholders can align on a shared purpose of helping the real people that depend on them, and continually point back to that shared purpose, it can be much easier to move the work forward.
Leadership Sponsorship
As discussed earlier, there are many complexities in determining whether a solution is viable. A large number of stakeholders can say “no” for a wide range of reasons. Much of the work is in determining when the “no” is grounded in a real constraint, versus an incorrect perception, or just outdated information.
One of the best ways to help with this is to find a sponsor within the leadership of the organization. You are looking for at least one key leader who is deeply invested in the mission, and is willing to try to work differently.
Their help in overcoming obstacles on behalf of the organization’s users can be key to removing obstacles, and accelerating the work of the product team.
The Persuasive Power of Prototypes
One dynamic that we haven’t mentioned yet is government bureaucracy. With all the various stakeholders and constituencies, policy and regulations, and with so many people with the ability to say “no,” perhaps the most important lesson is the power of prototypes.
In particular, high-fidelity user prototypes. Something realistic enough that your stakeholders and users can see how this could truly help people. There are many very powerful and effective prototyping tools out there today. Powerpoint decks won’t serve this need. Big documents won’t serve the need. If your goal is to win the hearts and minds of stakeholders and sponsors and approvers, then the realistic prototype is your best friend, as well as the key to avoiding waste.
A savvy product leader that teams up with a skilled product designer to show what is possible can have a truly remarkable impact. It is amazing to see how resources and assistance can suddenly materialize after a compelling demo of a prototype.
The Magic of Small, Skilled, Cross-Functional Product Teams
It is truly remarkable what a small but skilled product team can do. Yes, there are some efforts that truly need groups of hundreds, but most people are shocked to learn how many of their favorite apps have been completely designed, built and deployed by teams of fewer than ten people.
Realize that the infrastructure (the platform and the tools) that these teams are building on are more powerful than ever before, and the tools they use to discover and deliver their apps are more capable than ever before.
Also realize just how much faster a small, single team can make decisions when they’re not just one small piece of the puzzle.
You won’t be able to do everything with these small, autonomous, empowered product teams, but you can very likely do much more than you realize. And the successes these small teams can generate can provide support and momentum for the rest of the organization.
Reframing Projects
In the government context, it is very likely that project-based funding is not going away anytime soon. Realize this goes all the way to the appropriations process in Congress.
So the real question is how to take project-based funding, and turn it into a successful outcome?
Assume you have funding for a year to deliver a new and important project. Your job is to deliver the necessary outcome.
The reality is that in order to succeed, you are going to need dozens of iterations in discovery and delivery. What does this look like in practice?
For a 1-year project, plan on creating prototypes in discovery and doing iterations of the prototypes no less than weekly, beginning immediately, and going for at least two months before beginning your delivery work. Then, for delivery, plan on at least a dozen iterations (releases), no less than one every two weeks.
Within four months you should have weekly discovery prototype iterations for the work that’s coming up, and bi-weekly delivery iterations (launched to progressively wider groups of users).
The discovery prototypes are used to make sure what is being worked on will address the various viability concerns, and the delivery iterations are used to test that the product is providing the necessary value to users, and providing data on where the product is still falling short, which also informs the upcoming discovery work.
This of course is a highly abbreviated summary of the techniques used to discover and deliver a successful product, but it’s critical to reframe the 1-year project into this ongoing series of iterations for discovery and delivery.
The Critical Product Leadership Roles
If you’re trying to utilize the product model, while you can probably get away with a significant percentage of contractors on the product teams, one thing that’s absolutely essential is the three key product leadership roles – the head of product, the head of design, and the head of technology.
Systems integrator partners will want to take over these roles, but we see these three roles as essential. The heads of product, design and technology need to come up with the product vision and product strategy, and be deeply involved in every aspect of the various systems that contribute to this product vision.
Without these three key people, the chance of any kind of success is remote. But if these three people are strong, and working closely with the rest of the government agency’s leadership team, they can overcome considerable obstacles and still find success.
Continuously Evangelize Insights and Outcomes
Back to the dynamic of government bureaucracy for one final point: It’s absolutely essential to continuously evangelize the insights gained, and the outcomes achieved.
In the example we described of a project funded for a year, few great products are done in a year. Most go for many years, gaining more success and improved outcomes year after year.
This happens because the leaders make it very clear that the outcomes achieved are not an accident, and that this is what strong product teams do, and that they warrant continued enthusiasm and investment.
If the evangelizing stops, it’s only a matter of time before some other bright shiny thing comes along to capture the attention of the sponsors.
Conclusion
Hopefully it’s clear that at least conceptually the product model is not only a fit for government agencies, but we would argue that it’s the most responsible and effective way of providing the services the government needs to serve its users.
Hopefully it’s also clear that the nature of government agencies is such that there are inherent challenges that will need to be addressed in order to succeed. We’ve highlighted the techniques that we’ve found effective in overcoming these challenges.
In the next article, we’ll discuss the product model from the perspective of the third-party outsourcing agency. There are some truly impressive examples emerging of companies using the product model to provide technology-powered solutions for their clients.
Special thanks to long-time government technology advisor Erie Meyer for her review and feedback on early drafts of this article.
- See https://playbook.usds.gov/, https://www.gov.uk/government/organisations/government-digital-service, and https://www.dta.gov.au/ for a few examples we know personally. ↩︎
- Although it should be noted that government funding contributed significantly to several of the core technologies the technology industry has been built on – ARPANET, the precursor to the Internet, being one of the most famous examples.
↩︎ - In the US, the regulation that governs vendor selection is called FAR (Federal Acquisition Regulation), but it’s worth noting that in certain government agencies, the law permits something called “Other Transaction Authority” (OT), which can significantly ease the process of finding an appropriate partner. But keep in mind that this does not apply to all parts of government. ↩︎
