Building product management capacity in government part 1 – Our coaching philosophy

This is the kick-off post in a in a series of posts about building product management capacity in government agencies. The series explores the process of helping agency staff transition into product management roles, from both the 18F perspective and partner agency perspective (part two).

While standard practice in the private sector, product management is still in its infancy in the government. We believe that government needs product managers to bridge many disciplines and lead diverse teams to identify and deliver the right outcomes for stakeholders and end users. We believe that everyone in government has the capacity to become a product manager with the right training and coaching.

Product managers ensure the government’s mission is supported by the technology; ownership of the product vision, roadmap, and strategy should never be outsourced to a vendor. In an environment where a lot of technology work is done by outside vendors, in-house product managers help vendor teams understand the big picture and drive day-to-day trade-offs. Without someone managing both the strategy and execution, software development all too quickly turns into a game of telephone.

At 18F, we work with partners to develop product management capacity in their existing teams. This series is all about how we do that, from both our perspective and our partner’s point of view.

Finding our product managers

At the beginning of a project we ask our partners to play the role of a product owner. While we take on the bulk of the responsibility for managing software development, we need them to help us figure out what we should build. We don’t know enough to understand whether what we’re doing is good, and what good even means in their context. We also find that they can explain the value of the product far better than we ever could – because they’re living in the problem space.

In the long run, we need our partners to become full blown product managers. We’re going to leave at some point, so they need to be able to take care of the product on their own. After all, products are never truly done. They grow and shift as the context around them changes, and our partners are the best people to manage that evolution. Plus, it’s their mission! It makes sense for them to take complete ownership of the vision of their products.

In our experience, the best PMs generally come from the program side. They deeply understand the mission, and all of the context around it, which is key to making good decisions. It’s not hard for us to bring in people who know UX design and software development; finding someone who really understands the problem space is much more difficult. We’ve also seen that it’s often a lot easier for our partners to learn the basics of digital product development than for our team of designers and developers to learn the ins and outs of their agency.

Learning product management

Because most of our partners have never worked in product management before, and generally still have day jobs, we’re very intentional about teaching. We take an experiential learning approach to training product managers. We don’t believe that you can truly learn product management in a classroom – you have to build something.

That said, we don’t want to overwhelm people by asking them to run the entire product development process right out the gate. Instead, we start small and gradually increase responsibility as their skills and comfort grow. We call this process the Model - Pair - Coach cycle.

Model: In the beginning we focus on introducing new concepts and building comfort. We take the lead on all of the technical work and project management, modeling modern software development practices as we go. We help our partners set a vision and initial strategy, mainly by asking questions, and use our expertise to make sure that we arrive at a reasonable plan. We continuously explain our decision-making process so that our partners understand what we’re doing and why.

Pair: As our partners become more familiar with the process, we begin to involve them more directly in day-to-day work. We’ll start to divide work more evenly, splitting up tasks (like adding new work to our project management tool and taking notes during user research sessions) and working side-by-side on a single task (like drafting a vision document together). Our designer and developer teammates act as a test audience for our partners, and we give feedback (and reflect) regularly.

Coach: Eventually, we get to the point where our partners are confident enough to take sole responsibility for pieces of the project. We fall back into an observation and coaching role. We watch how our partners interact with the team, as well as talking directly to the designers and developers, in order to give constructive feedback. We also introduce more advanced topics, like user research methods or agile development frameworks, now that our partners have the hands-on experiences to make sense of this information.

Owning product management

Once our partners are able to fully own the software development process, we migrate the project to their agency and ramp down our involvement. After 18F’s departure, the partner product managers continue to grow and deepen their skills so they can best support the needs of their agencies and users.

Ultimately, our goal is to make sure they are empowered to evolve their product management practices to fit their agency so they can deliver great outcomes to their end users.