The product owner role is becoming increasingly common at government agencies implementing new software, such as government acquisition solutions. The product owner’s responsibilities include defining and prioritizing the product backlog—which includes a list of features, enhancements, and fixes—to make sure the product aligns with business goals.
The right person for the role of product owner for government applications is an empowered decision maker who represents stakeholders and champions the solution. They should work closely with stakeholders, development teams, and end users to gather requirements and create use cases. Ideally, they continuously communicate with the team, provide clarifications on requirements, and make crucial decisions to deliver a successful and valuable product.
[ See how 12 industry leaders accelerated their go-to-market processes and improved the customer experience by rolling out modern applications. Get the eBook. ]
3 must-have product owner skills.
Scope creep—the gradual and uncontrolled expansion of project scope beyond its original boundaries—is a danger in all software projects. Scope creep leads to timeline delays, budget overruns, and loss of focus on the project’s original objectives and goals. In many cases, scope creep leads to project failure when it becomes unmanageable or unsustainable, rendering project teams unable to deliver the intended value.
To mitigate scope creep, it's crucial to establish a minimum viable product, or initial operating capabilities (IOC), at the outset. Based on the Appian public sector team’s extensive experience implementing acquisition solutions at government agencies, we identified three vital product owner skills and qualities for leading a successful software rollout:
1. Understand the business processes.
It’s extremely important for the product owner to have a good understanding of business processes, an eye for improving them, and a vision of what the final product should look like. The product owner needs at least a high-level understanding of how the application should work to enable them to relay the necessary information to the development team.
In the example of government acquisitions, the product owner should ideally be someone that has worked in acquisitions for years or at least understands the acquisition process and current technology inefficiencies (e.g., siloed systems, unstructured data, etc.).
2. Build a support team.
No one person is going to know all the minute details of every single process. A good product owner builds a team with expertise across the areas the software will address. And the product owner should delegate to these subject matter experts (SMEs) the responsibility to meet milestones and perform testing.
In government acquisition, for example, the product owner should work with key stakeholders like policy, legal, IT, and acquisition professionals to ensure the solution is configured to the unique processes of the agency
The product owner also has to be able to identify any gaps in SME knowledge and decide how to bring in an expert to bridge the gaps. By way of illustration, in government acquisition, if the team does not have enough knowledge to enable the unliquidated obligations tracker, the product owner must decide what to do—perhaps bringing on a finance system resource to augment the team in the short term.
3. Listen to all stakeholders.
In general, people don’t want to change the way they do things. Therefore, the product owner needs to generate consensus and buy-in from everyone who will interact with the software. Beyond technical knowledge, the product owner must possess soft skills, such as the ability to strategically communicate and market the product to IT, users, partners, and leadership.
To drive adoption of the new software, the approach we’ve seen work best is to invite all stakeholders into the process and keep them informed. Make sure they are aware of the initial operating capabilities to ensure the software meets its IOC and doesn’t expand beyond the intended requirements to enable fast implementation. (Additional features can be added at a later date if you use an agile software development tool like a low-code platform.) Involve stakeholders in demos, proofs of concept, and all iterations of the product, and listen to their concerns and feedback. Users who have been part of the decision-making process will be invested in the product and will want it to succeed.
Low-code helps you bring your products to market faster. Get the in-depth Gartner® report about the future of low-code to see how it can transform your software strategy.
