The Role of a Product Owner in Transitioning Organizations

So you are a product owner in an organization that wants to be agile but doesn't have the organizational infrastructure to enable and empower you.   The primary role of a product owner is to ensure product is delivered with the highest business value first within the shortest release horizon with the highest quality code.  To do this, the product owner must have the ability to negotiate with customers and stakeholders while continuously prioritizing the work consumed by product delivery teams.  If you have practiced 'real' agile, you understand that the role of the product owner is the most challenging to adopt in an organization undergoing an agile transformation.

The roadmap to a mature product owner role can be correlated with the agile adoption transitional stages learning, improving, sharing and innovating.

Learning Stage

In this stage, teams are barely forming, receiving training and coaching.  If teams can't demonstrate that they can execute agile practices, the transformation will fail.  The role of the product owner will not scale past the project level and this person maybe formerly have been a project manager, product manager or business analyst.   Simply prioritize the team's work and limit work in progress. Stop starting and start finishing tasks.

Improving

In this stage, teams are practicing all the fundamental agile ceremonies.  The role of the product owner might reach the program level and you can influence all functional areas by keeping everyone aware of the product vision and the roadmap to get there.  You still may not get to influence the priority of work intake but you can make business value goals visible to all. Talk about it hang up posters about it, your job is to simply make aware and elaborate.

Sharing
In this stage, many agile teams are stoodup and the pilot teams are sharing templates, meeting logistics, process documentation, tool configurations and other lessons learned.  Typically this means leadership members are convinced for at least one business unit and are more willing to provide for environments and cultures that agile practices thrive in.  The role of the product owner may even be at a director, VP or even C Level depending on the size of your organization.  This product owner may be able to control the portfolio of work and investment models. 

Innovating
In this stage, agile roles are scaled from the team to leadership levels, thus providing alignment from top to bottom by default.  The role of the product owner is setup to reach maximum potential by delivering products that can change the world, wipe out the competition and attract the best talent.

So you see, the role of the product owner has a place in every organization we just need to be patient with immature organizations and coach anyone that presents teaching moments.  

When vertical user stories become not so vertical anymore

Vertical user stories imply that all necessary work in the database, service and UI layers will be testable and verified by the user.  In fact, any story written by an end-user is typically a perfect vertical story that will result in business value delivery.  So what is the big deal?  Most agile teams break their stories down into horizontal slices that independently provide no business value.  Vertical stories are keystone to reducing time market while tracing financial impact end to end, which is kind of the whole business case for investing in agile adoption in the first place.

So when do vertical stories become not so vertical anymore?  Top reasons include:
1. Organizational structures that have separated groups by each horizontal layer in their vertical story.
2. System architectures that are so complex and distributed, it takes months to get information from the right people and to coordinate an end to end testing effort.
3. Poor portfolio management where priorities are not aligned across groups and highly specialized skills are spread thin
4. When teams are unwilling or unable to change their mindset from big bang delivery to iterative delivery.

Example 1:
A financial services company has three separate business units that either support back office, middle office or front office.  The teams working in middle office never interact or have knowledge of the customer.  The business units only interact at the senior vice president and above levels.

Example 2:
The system architecture of a telecom company has not been able to automate their transactional processes.  Many different functional groups try to automate and the data gets stuck in one of the many third party applications without ever synchronize to a single customer record.  Manual processes must fill in the system gaps and the end user is not able to see the data.  Synchronization would require coordination with all internal and external partners.

Example 3:
A program of teams is working in a vertically structured organization, non-legacy systems, and the solutions technology portfolio is complimentary.  The only problem is leadership's inability to limit work in progress and spreading the talent too thin across initiatives.  Too many projects in a program eventually will cause their own impediments.  Teams get impeded, stories are put on hold and they start something new until an older story is unblocked.  No stories ever get done in a given timebox.

Example 4:
A team practicing waterfall is forced to adopt agile iterative delivery but they can't seem to get over the incremental development mindset.  They may not even have the skillset or information available to do anything but complete one of the layers.  The idea of re-work is a negative outcome so they work from their own task list without ever really working from the user stories.

If you relate to reasons 1-3 and you are not a decision making stakeholder, simply get as vertical as you can possible get for your business and system context; otherwise, you have the power to directly impact time to market.   If you fit into reason 4, identify what you think your constraints and limitations are and simply validate them as logical. Better yet, if your mindset is the problem, reach out to other previous non-believers and find some rationale to change that resonates with you.