Six lessons from my time as a government product manager

This is my last sprint working as a product manager for the Office of Natural Resources Revenue (ONRR), so I’ve been reflecting on everything I’ve learned. As the first product manager at ONRR, I was lucky to have many people to teach and guide me. As I move on, I’ll be bringing with me many things I’ve learned from those people and my experience on this team. Here are some of the lessons I’ll carry with me to my new position.

1. Understand the problem

A thorough understanding of the problem(s) (i.e., the “why” behind your work) is core to the role of product manager. When people have a desire to solve a specific problem, rather than an attachment to a specific process or tool, they look for ways to improve. To find the right solution, you must have a deep understanding of the problem before you explore options to solve it.

Someone selling a product or idea without an understanding of the problem it’s solving is likely to fail. In government, there are ample real problems to choose from, so there’s no need develop a solution before finding a problem. Likewise, we shouldn’t try do or buy the new, shiny thing for the sake of being frontrunners. If it solves a problem we know exists, we should use modern practices and technologies, but the right solution may not be something new. Sometimes tweaking or eliminating something you’re already doing is enough. We need to be open to that.

Our team went through an extensive process of defining our problem, and a vision of how to solve it, in our product framing document. We also reviewed and updated the documentation as we learned more from user research and analytics. The understanding we’ve developed through our focus on the problem and vision has helped guide us in our most important decisions.

2. Set and measure the right goals

You won’t improve processes or experiences without first knowing the problem. Defining what it means to improve is next. This can be difficult in government because we don’t have common private-sector success metrics like transactions, sales, and profit.

We often should consider both business value and customer/user value in our goals. Goals like “increased users” for a digital product can work but don’t always make sense. For example, increasing users for a troubleshooting website could mean that trouble is increasing. Instead, it might be a better goal that the site solves users’ issues so that they don’t have to call the help desk. In that case, a goal for the site might be decreasing help desk calls.

Even if an increase in users makes sense as a goal, as it did for us, there are other business and user needs to consider. Sometimes there are legal or technical requirements that we should incorporate into our metrics as well.

Take the time to define the goals that fit your problem and situation, and really get at the core of the problem you’re trying to solve. Deciding how to measure your progress before you start will lead to a better solution because it will allow you to see if things are working and make changes when they are not. Metrics also can help a team demonstrate the value of their work.

3. You can’t do everything

Like most people, product managers must contend with resource constraints. Quantitative and qualitative data can help you understand the tradeoffs of product features. You can’t—and shouldn’t—build everything. You also may not be able to fix every problem you observe a user have with your product. That’s why data (such as analytics and user research) and a thorough understanding of your product’s vision and goals are so important. They help you make the right decisions about how the product team should spend their valuable time. This results in a valuable product that meets the business’ and the users’ needs.

4. But, the “small stuff” matters

While you shouldn’t do everything, you should do what you’re doing well. Most people who’ve interacted with a sub-par product understand this. It’s fresh on my mind after I spent a late night building two assembly-required dressers.

The first dresser took me much longer than the second because I had to figure it out along the way. I like the dressers in the end, but the quality of the instructions made a big difference in my impression of the product and the company. A simple label on bags of screws could have saved me at least an hour. Sometimes the small details add up to make a big difference in the customer experience.

It’s the same with the websites our team has been working on over the last few years. It’s not always easy to convey government business in a simple, concise way, but it’s worth the effort. It means we care about the public we serve.

Building trust in government is one of the fundamental goals of our open data, open source, open code site. Still, openness is not enough. Publishing spreadsheets and government reports won’t build trust if they aren’t understandable. That is why every sentence and every graph on every page of our sites matter.

And, we need to observe actual users to make sure we’re not missing important details. Doing usability testing helps identify little things that cause big frustrations. I sure wish the dresser company had tested their instructions on some novice builders like me.

5. Don’t blame the people

Some people might hear about my problems assembling dressers and conclude that I’m not very handy. That might be right, but it’s really not about me. A small tweak to the way the company labeled or packaged their screws could have saved me at least an hour. I was not the problem. People are not the problem.

Inexperienced users may struggle to use something you’ve designed or built. Nonetheless, if they want to use your product (which I assume is the point), they matter. So, you should consider inexperienced or non-tech-savvy users as much as possible in design. This doesn’t mean that you need to give your users more training or a bigger manual. Instead, it should be your number one goal to produce simple, clear products or processes that work for the people who use them.

There’s another area where we can make it too much about people. In work environments, it is too common to look for someone to blame when something goes wrong. Instead, when we look at failures as opportunities to improve the way we work, the end result is better products and happier, more productive and collaborative people. Of course, no process or control will ever end errors. That’s ok. To get the best from people and produce great products, we need to allow ourselves the freedom to always be learning. That’s why agile, iterative development helps you identify and adjust to issues along the way. It’s much easier and cheaper to adjust a process or a design when you’re a month into a project than 3-years down the line.

6. But, it’s really all about the people (or, at least, it should be)

The people are not the problem, but they are the solution. We need to fix products and processes—not people. But, how do we do that? We have to work with people, collaborate with people, and especially listen to people. Anything successful will have people at the center. That includes the users of a product and the team building it.

The success of a product depends on understanding the users and their needs. It also depends on the product team members, and I am so grateful that my first experience as product manager happened with this team at ONRR. It is full of people who care about delivering a valuable, high-quality product to the public.

We’ve accomplished a lot over the last few years because of the talent, dedication, collaboration, and openness of the team. While I am moving on to work on new problems and learn new things, I will always be proud of the time I spent as part of this team. It is a group of people who always strive to understand the people we serve and deliver them products that solve their problems. I will miss them!