Why the Government Needs More Product Owners

As a former Analyst and Federal Government Project Manager, I can tell you it took me 5 few years to move from Business Analyst to my first Product Owner role. Finding my way to Chief Product Owner required a lot of training, some trial and error, and adoption of government Agile best practices. In sharing my story, I hope you can gain a deeper understanding of the value of product ownership in government, learn from my experiences, and potentially land your dream job as a Product Owner!

The chicken or the egg?

Government leaders have struggled with the roles they need to create successful outcomes with the shifts to Agile and iterative approaches. This makes sense, because Agile development in government is still a relatively new approach, and the career development pathways for Agile roles are not widely accepted or adopted. Through one lens, career growth includes adding greater responsibilities and qualifications to help Business Analysts mature into Product Owners, and eventually into Project Managers on top of their previous roles.  This evolution looks like an “Egg”:

This rationale aligns with the hierarchies at most agencies and traditional project management, where the Project Manager oversees the work done by all other team members. However, when seen through a different lens, these three roles are distinct, complimentary, and overlap only in certain areas. In this way, the relationships between these roles looks like the “Chicken”:

In this view, Agile employees can progress in their careers within one role from junior to senior, or by transitioning between roles from BA to PM, PM to PO, or BA to PO. Acknowledging the importance of these distinct roles leads to extended teams that contain all these roles. This will create checks and balances and a culture of equality, where team members have equal standing to work toward a solution.

Why it is the Chicken and not the Egg

The “chicken” model creates balance on a team that Project Managers cannot achieve alone. Business Analysts focus on quality and building something right the first time, while Product Owners focus on delivering value or ROI for the customer. Project Managers, on the other hand, generally focus on speed to deliver a product on schedule. While these positions overlap, product teams benefit from unique expertise when government staff pursue depth in one role versus striving to be generalists in all three. Here are some examples of the functional overlap between these roles:

Why it is not the Egg – or, “Don’t Get Egg on Your Face”

The “egg” view of these three important roles oversimplifies professionals and their roles into a false hierarchy of junior and senior skills. When we assume the responsibilities and qualifications of each role seamlessly subsume into the next “higher” role, this results in a lack of understanding of real collaboration and value from all team members. For example, the skills and abilities of a senior BA and a junior PM are not comparable. In my first days as a government PM, I learned the hard way about what PMI calls friction between Business Analysts and Project Managers. PMI suggests ways to move away from this traditional thinking, such as “Tip #1: See the business analyst as a leader, just as you are a leader.” All team members should view the other roles as peers, not subordinates or superiors.

Why the government needs more Product Owners

In my experience, most government BAs will follow a standard career path and grow into a PM role – leaving agencies with lots of PMs and too few trained Product Owners. While working at the IRS, I transitioned from BA to PM. I worked on several Agile projects that did not have a named Product Owner, so I had to work closely with BAs and business leaders. One major, mission-critical system project failed while we worked in this arrangement. The reason? No one liked the product we ultimately delivered. As a Project Manager, I was expected and driven to build something on time. My collaboration with Business Analysts resulted in quality work. But at the end of the day, the customers didn’t like the product because we didn’t have a Product Owner advocating for the interests of end users and making sure the product delivered value in context of the organization’s evolving mission.

 

Shifting to Government Product Owner Mindset

After several years as a PM, I eventually moved in a business role, where I was able to get into the trenches of understanding the business needs at the Federal Reserve Banks. I spent time learning to understand and appreciate why and how people use products. On my growth journey from Project Manager to Product Owner, my perspective and focus changed from projects to people. Once you make that shift, everything you do is driven by delivering value to the people you serve. You realize the key to successful delivery is to build and communicate vision and roadmaps for products – not projects. To support that shift in thinking, training is critical: Agile training and product training were just two that held “ah ha!” lessons for me.

Now What?

While there are commonalities between Product Owners and BAs and PMs, government teams need all three roles to be truly successful. Government leaders on both the IT and Business sides must recognize this need and create opportunities for Product Owners. A career path option to grow from a Business Analyst directly to a Product Owner provides you the opportunity to drive the mission and ensure value for your agency, those you serve, and taxpayers by building more products that people like – or even love!

Don’t know where to start? Contact us about Proxy Product Ownership.  Send an email to Laura Stash, lstash@citizant.com.

If you like this post, use one of the buttons below to share with your social networks.  Thanks!