Skip to main content
U.S. flag

An official website of the United States government

Back to Blog

So, you’re a Product Owner...

At 18F, a primary goal we have when working with agency partners to build or buy great digital products is to make sure the agency partner has full ownership over the product and its outcomes by the time we leave the project. This is how we realize our mission of transforming how government approaches technology projects.

One of the ways we build this sense of ownership is by identifying a Product Owner early on. A Product Owner is someone from within the agency who works with our 18F team to shepherd the product from the initial idea through to delivery and beyond. The Product Owner, or PO, is ultimately going to be responsible for the product after the 18F engagement is done.

What is the role of “Product Owner” on an 18F project?

As described in our Partnership Principles, an empowered PO “is someone who understands your organization, the problem we’re solving, and can advocate for the product we ultimately build together. They’ll be responsible for establishing and carrying the long-term vision of the product, implementing a strategy, and guiding its progress, as informed by user research.”

The time commitment for POs depends on the nature of the product and changes over time. POs initially share responsibility for the product with 18F team members, but 18F works to transfer full responsibility to the PO during the course of our engagements. For a complex product, such as a data-rich website or an application with many interactive features, this might eventually be a full-time role.

We ask our agency POs to operate in both strategic and tactical ways. POs own the vision for the product, which is derived from a deep understanding of the problem to solve. Working with the 18F team, they use a user-centric approach to create a strategy for the product that serves both user and program needs. They also position the product for success both inside and outside of their organization.

On a tactical level, the PO will participate in, and in many cases, lead, all of the meetings and touchpoints typical in a software development project, from “backlog refinement” to “sprint planning”. If those terms are unfamiliar — as they are to many first-time POs — just know that they are the regular, frequent (often daily!) opportunities to define and plan the specific, tactical work to be done on a software project.

Do Product Owners need to have technical backgrounds?

Even though the PO is a key member of the software development team, it’s not necessary that they have a technical background. In most cases, having a deep understanding of the potential users and their problems and a willingness to approach the problem incrementally is far more critical than any technical knowledge. Navigating complicated stakeholder relationships, understanding business and program goals, and making difficult decisions and trade-offs are also all more central to the job of Product Owner than having technical chops.

If you think of the Product Owner as representing the voice of the customer or user, in many cases it’s preferable that the PO does not have a technical background. Unless your target audience is highly technical, the “non-technical” PO will be well-positioned to represent their users’ needs.

Making a big impact

So how do Product Owners make a big impact in the software development process? Here are some tips for engaging in the process and bringing your specific skills and experiences to bear:

  • Keep the user’s needs in the forefront, and ask others to do the same. It’s pretty common for teams and stakeholders to revert to describing their work in terms of “features.” You can remind people that you’re not here to deliver working features or bug-free code, but rather to solve specific problems that people have. Measure your success against that yardstick.
  • Connect with the people using your product as often as possible. Whether it’s through structured research activities (such as user interviews or contextual inquiries), usability testing (when you observe people using your product), sprint reviews (regular opportunities to demo progress to stakeholders), or co-creation activities (such as design studios), take every opportunity you can to get to know your users’ needs. Take note of the language they use and the things that frustrate, confuse, surprise, or delight them.
  • Inform and engage other stakeholders. This could mean inviting them to participate in regular demos of the latest updates, engaging them as subject matter experts on various components of the product, or arranging specific times to talk through the product vision and strategy.
  • Remain flexible. As Amber Sprinkle, who recently served as the PO on a project with 18F says, “While the PO’s vision helps guide the team, it’s important for them to keep an open mind about the path taken to get to the vision, and know that the vision may change along the way.”
  • Use plain language, and ask others to do the same. Plain language makes it easier for the public to read, understand, and use government communications. Watch out for jargon, and advocate for simple, straightforward language.
  • Make difficult decisions. POs can contribute significantly to a team’s success by simply being able to strategically choose between competing priorities. POs are responsible for maintaining an ordered “product backlog” detailing the work to be done. The ordering should always reflect the current thinking about relative priority.
  • Boost the team’s momentum and morale. Help your teammates stay focused on solving problems and delivering results. Celebrate successes. Lead the way in learning from challenges and stumbling points. It’s easy to get lost in the development process and part of the PO’s main job is to keep the team moving.

If you’re considering taking on the Product Owner role, you might want to also check out this interview with Aaron Burk, the PO on the United States Forest Service online permitting project. Aaron gets at something critical about the role of the PO — he says it’s not just about technology; it’s about solving problems and providing value. If you share this mindset, you’ll likely find the role of PO very rewarding.

Related posts