What I’ve Learned in my First Few Months in Government

Colorado Digital Service
6 min readFeb 2, 2023


A photo of the American flag and Colorado flag with snow-covered mountains in the background taken by dannyboy4125 via Unsplash.com
A photo of the American flag and Colorado flag with snow-covered mountains in the background taken by dannyboy4125 via Unsplash.com

I’ve been a product manager in the private sector for more than a decade, and in that time I’ve seen a lot: product launches, hockey-stick growth, expensive failures, company acquisitions, reorgs and more. So I thought — somewhat naively — that joining the Colorado Digital Service, a team within the Governor’s Office of Information Technology, as a product manager in September 2022 would be more of the same.

Not quite.

To be sure, the principles of working in a tech organization are consistent across the public and private sectors. For example, in both areas product teams must:

  • Fully understand a problem before jumping into solution mode.
  • Understand end users’ behaviors, pain points and motivations.
  • Understand stakeholders’ motivations to inform buy-in strategies.
  • Validate hypotheses through qualitative and quantitative testing before launching a product at scale.
  • Weigh technical feasibility against expected impact.

But after a few months, I came across a handful of divergences from what I was used to in the private sector.

Free code and info-sharing from other governments

In the private sector, I spent a lot of time developing competitive analysis matrices. That meant using a competitor’s product, creating an account for the purpose of seeing how it worked or posing as a customer with their sales team. It felt a little like spying.

In government, covert competitive analyses are not necessary. If I’m curious about how a product from another state, municipality, the federal government or even another country works, I can reach out to them and ask.

So far, I have spoken with a handful of local and international government technologists to learn about their digital properties. They have each willingly shared insights, including their discovery process, how much money they have invested, user behavior data, adoption rates and return on investment for their tech.

In many cases, governments make their technology open source, so if a product is already built, another government is even willing to hand over the entire code base to replicate — free of charge.

This level of openness blew my mind when I first learned it was an option. My manager explained that no government wants to use more taxpayer dollars than necessary. Whether it’s built in the U.S. or abroad, it is in the public’s best interest to leverage the technology that’s already been built rather than spending millions to reinvent the wheel.

Push and pull between agile and long-term budgeting

Budgets are predictably tight in government. When a product team needs more funds to build features or functionality, they often have to go through legislation first. The process takes at least a year, in part because it’s important to ensure taxpayer money is being spent appropriately. Once the budget is approved, the funds must be used exactly as they were described in the request. This is necessary to keep the government accountable to the public on how their taxpayer dollars are being spent.

This is at odds with agile product development, which demands flexibility so that teams can adjust their roadmap based on ongoing testing, research and behavioral analytics.

We are starting to see non-technical people in government appreciate the value of agile development by focusing the planning on outcomes instead of features, and incorporating frequent updates to stakeholders.

In a recent win for my teammates who launched the technology for Colorado’s Universal Preschool program, Colorado State Sen. Jeff Bridges recalled a milestone check-in when the team admitted that their initial plan and assumptions were proven wrong and course-corrected. Sen. Bridges applauded the team for their flexibility:

“I think that was exactly what we’re supposed to see in agile. We’re supposed to make mistakes quickly, not come into January and find out when we turn that key the ignition didn’t work.”

Not all government officials are on board yet, but by pointing to case study wins like this one we can bring them over.

The target audience is an entire state

I used to work at a company that built much of its success by targeting an audience within a narrow demographic. The branding team at the time was deliberate about not designing for people outside that demographic, lest the brand and its messaging become diluted, and we alienate our target audience.

Working in digital government is drastically different. Creating experiences for the broad population means taking everyone’s needs into account. As part of Colorado’s commitment and accountability to serving everyone, a law will soon go into effect that requires all government entities in the State of Colorado to be accessible to people with disabilities by July 1, 2024, or risk a $3,500 fine per violation.

Colorado has 64 counties and among them are a range of demographics, social characteristics (e.g., support systems, languages spoken or read, literacy), physical characteristics (e.g., vision, auditory, mobile, dexterity), technology access and levels of trust in government, to name a few.

How do we approach building experiences for a broad and diverse population? It starts with building diverse teams that represent a range of lived experience. Next, we study demographic data to unpack who we are serving, what language those individuals speak, their income brackets, where they live, how large their households are, and so on. Then, we go a layer deeper by talking with people whose experiences are different from our own.

For example, this fall a human-centered designer and I completed an eight-week discovery sprint in which we spoke with over 40 people inside and outside of government. We used quantitative government data to get a picture of who we need to serve, and then recruited interview subjects with a diverse range of perspectives, including across various income levels, on different benefits, and with different physical abilities (e.g., people who are blind).

I went into the project with some appreciation for challenges people are going through across the state, and understanding that we need to meet people where they are when we provide product solutions. But actually hearing their stories in real time changes the game.

I knew at a surface level that navigating through life as a visually impaired person would come with challenges. But hearing from people in that community gave me a much deeper understanding.

One person mentioned that when she boards a flight, she fears her guide dog could be forced to go to cargo if the dog doesn’t fit under the seat in front of her. I observed the same person using her text-to-speech transcription as she scrolled through her phone, which provided insight into how that sounds.

The more we know about Coloradans’ specific lived experiences, the better chance we have at meeting them where they are to provide the services that make their lives easier.

What motivates me every day

As a product manager, I have always found it fulfilling that doing right by the end user results in happy customers. That, in turn, grows the business. But what happens when growing a business isn’t the goal of the work? For me, for now, it feels right to be able to work for an organization that is trying to improve people’s lives without the backdrop of doing it to win market share.

I’m in good company with that perspective. One of the CDS team mottos is “Culture eats strategy for breakfast.” To be sure, my teammates are strategic, thoughtful, process-oriented technologists, but they also bring to every interaction deep empathy and care for the mission. The end result is the ability to build trust across employees and constituents who are uncomfortable with change. Then they leverage that trust to bring about deep and lasting change. It’s really great to watch and, I hope, to be a part of.

It’s hard work. There are many products built on legacy code and disconnected backend systems. With that comes so much runway to make things better. My teammates and I have spoken to agency partners that are handling some operations by hand that are so ripe for automation and technology upgrades that will make employees’ and constituents’ lives easier.

Plus, I am gaining exposure to so many areas I feel passionately about. In a single week, I had meetings about Colorado’s transition to clean energy, ways to improve government communication and improving the public benefits process. Meanwhile, my Colorado Digital Service teammates have created technology programs from the ground up in the behavioral health space and universal preschool program. If and when I do decide to return to the private sector, my government perspective across a breadth of verticals will make me a stronger candidate.

Want to join us?
We’re hiring at

This article was written by Debra Alban.

Interested in following along with the work of the Colorado Digital Service? Submit an interest form to stay connected. You can also check out our work at our Colorado Digital Service website, GitHub, Linkedin, or Twitter.



Colorado Digital Service

A team of engineers, designers, product managers, and procurement specialists serving limited tours of service in government. colorado.gov/digitalservice