Project management vs. product management

Search USAJobs under the keyword “project management” and you will find hundreds of postings, Chris Johnston and Kelly O’Connor of the U.S. Digital Service write in a new blog post. But search under “product management,” they note, and you will come up empty.

The post landed on my reading list thanks to my friend and colleague Nick Sinai, a venture capitalist and former deputy CTO in the White House. It should be read by every government manager in the IT/digital space.

I want to give kudos to the authors for how they begin their post. They write: “The U.S. Government builds and maintains thousands of digital products: prospective students apply for loans, Veterans refill prescriptions, travelers get passports, and citizens file taxes. The list goes on. The U.S. Government has delivered much of the ubiquitous technology we use today. The Internet, microchip and GPS were developed by the U.S. Department of Defense, the electronic health record, pacemaker, nicotine patch were products of the U.S. Department of Veterans Affairs, and fire resistant clothing and infant formula were invented at NASA. These are just a few examples of government innovation.”

In an age when some suggest the government is incapable of doing IT right or of innovating, it is really useful to have non-career civil servants present a more balanced picture.

Most of the article, however, is about how government could do better.

That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” -- such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O'Connor note.

Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”

Most government managers, and most government vendors, have extensive project management training and Project Management Professional certifications. But they have little or no training in concepts from the world of product management “such as design thinking, iterative releases, product funnels and analytics, and user research.”

Key to product management is the involvement of users for getting ideas for product features, and product look and feel. The authors note that “[u]nderstanding your customers and their problems comes from user research: speaking directly with users; watching them, in context, trying to solve a problem on their own; asking them in many different ways what problem they need to solve and how they feel about a given solution.”

In product design jargon, this is referred to as user-centered design or design thinking. “Involving a human perspective throughout the product design process helps ensure that the resulting product is usable, effective, efficient, and enjoyable,” they note.

To be fair, none of these concepts is completely foreign to the world of federal IT. I have personally heard references to the need to involve users in application development for at least a decade and probably more.

However, I think it is fair to say that this idea has been more at the periphery of government IT, and I’m guessing even today it is usually ignored when thinking about software development. Product design moves this concept front and center.

User involvement, the authors write, continues during product implementation -- indeed, they say, this is a central concept behind agile development. Typically in traditional government IT project management, they note, customers don’t get to try out a product until the end of development, after years have passed and millions of dollars have been spent. With agile, you put out a minimum viable product and have customers use it. “With the feedback from your users," they write, "you can then make changes to the requirements and build and release the next iteration of the product.”

Raising a topic near and dear to my heart, the USDS post emphasizes the importance of developing performance metrics to see how the new application, once fielded, is working. Giving an example from their own work at the VA, the authors discussed usage metrics of various sorts. I was particularly struck by a “user funnel” metric that defined key steps in an application process to see where during the process veterans were dropping out because they were confused or felt the process was too complicated. With such data, the wrote, “you can conduct further in-person research to understand” why failure is occurring “and devise an even better solution.”

The USDS article also has a second purpose: to advocate for a new “national model of service” that makes it easier for people from the private sector to do time-limited stints in public service.

“In the legal industry,” the post notes, “lawyers fiercely compete to clerk for a U.S. Supreme Court Justice. What if we could replicate this model for technology?”

A big barrier to developing product management in the government is that the government has a very difficult time recruiting talented people with these skills as career feds. The time-limited stint model may be the only practical way for the government to get talent with those skills. (The same goes for skills as software developers.)

The post notes, a bit gingerly, that “many people in today’s technology workforce aren’t drawn to a long-term career service role in government. ” The authors added that “they do want to have an impact and work on something they care about. And what better place to do that than in government?”

Part of the reason for this reluctance to take a long-term government career relates to general trends among younger people, who assume they will have five or more jobs in their careers and can’t imagine the traditional government model of joining the government at the entry level and staying there for life. But the post glides over another important problem the government has, which is salaries that are much lower than in the private tech industry.

This is an issue I have blogged about many times over the past decade, as early as 2006. The time-limited stint is central to the recruitment models of both USDS and 18F, though 18F seems to be generally limited to one or two two-year stints while USDS is more flexible.

Let’s set a goal that USAJobs word searches for “product management” will start getting more hits.