How to Think Like an Agile Product Owner

According to Agile framework, the development team owns the build, or HOW software advances from idea to iteration. But, the Agile product owner role determines WHAT is completed in the first place.

If the software development lifecycle was a ship’s crew, the development team fires the engine, drops the rigging and minds the boom, and the product owner steers the ship.

The sole goal of a product owner is to empathize completely with the target users of the solution to inform the purpose and vision for the software being built. The product owner must understand the customer problem to set a course in creating the answer.

Project Focus vs. Product Focus

There’s a meaningful difference between the function of the Agile product owner and roles more oriented toward project management. Ideally, the product owner will be involved in the software development process to lead, guide, answer questions, validate and assist minimally in organizational tasks. Time must be set aside in the Agile product owner’s day to think holistically about future improvements and advancements to the solution. They must continually remain connected to the users of the product, interviewing them and adopting their mindset during testing and validation.

Product owners ask weighty questions to assess what users need and how the solution under development can help them satisfy it.

5 Questions Agile Product Owners Ask Before a Project

1. Who will use the product?

2. What needs will the solution satisfy?

3. Which attributes are critical to users and how can they be parlayed into features?

4. What will differentiate the product from other market offerings?

5. What is the target timeframe and budget to launch and land the product?

The questions a product owner asks differ as the project matures. As time passes, they become more tactical and focused on information and team management to accomplish the objectives at hand.

4 Questions Agile Product Owners Ask During a Project

1. How should the product development team be held accountable if the scope or schedule of the project was late enough to have a significant impact on the business?

2. How can enough meaningful information be provided to the feature development teams to ensure they generally understand the development asks before they begin working on them?

3. How involved should PO’s be in product testing and acceptance testing?

4. Is it possible to shift the direction of the team if the market shifts significantly?

How to Think Like an Agile Product Owner

Product owners are tasked with being in sync with the voice of the user and making product development decisions that prioritize and serve the audience the most critical features first. That said, it’s important for all roles to adopt this consumer-centric mindset and walk a mile in the shoes of the users.

1. Keep the Market, Your Customers and Users Top of Mind

Encourage your product owners and team members to talk with users on a regular basis. It’s particularly important for product owners to observe their movements and process to become intimately familiar with their frustrations so they can be reflected as priority items in the development roadmap.

Take for instance a nurse. Reading a brief detailing the trouble nurses have navigating a number of technologies while interacting with the patient presents one layer of understanding. But seeing real-time how a nurse struggles to input data into a computer and read an iPad while soothing a patient in pain, presents a more vivid picture, crystalline understanding and adding new meaning to the solution under development.

By empowering your development team to intimately understand the customers and zero in on existing challenges, product owners can feel confident providing crude sketches to the team knowing they will be able to execute. Investing time to educate the team on the front end provides the team the license and perspective to come up with creative, time-saving solutions.

If errors are made, they can be corrected in follow-up iterations or iteration reviews. In this way, answering “questions” by means of review saves churn in the long-run. In our experience, time spent correcting or offering the extra insight needed to re-direct development and head off misunderstandings generally consumes 5-10 hours per week.

2. Call Out Issues Immediately

Product owners have learned to voice concerns right away when reviewing the development. That way, if the time to fix is minimal, the issue can be adjusted without adding to the scope of future development.

Sometimes the adjustments aren’t so easy. Those can be “purchased” in the next sprint, never more than two weeks away. When it comes time to reprioritize for the next sprint, keep users top of mind. You may realize there are other more important stories “to buy.”

Product owners record these asks in the product backlog. Much like the other process-oriented documentation in Agile, look at the record keeping as a way to maintain visibility and control, rather than an obligation.

3. Prioritize Quality and Foster Accountability

Building software in waterfall development is akin to charting a hike, drawing it on the map and following the chosen route exactly. Agile development is more goal-oriented, like hikers who say, “I’d like to see a waterfall during sunset.” With a task and time set, the hikers are free to “go off trail” to accomplish the objective.

Along the hike, decisions were made to rest, accelerate or redirect. Missing the sunset at the waterfall is much like failing to launch 100% of features agreed upon on a given date.

Rather than accusing, lead active discussions about decisions that impacted the outcome. Most teams in this situation will release the partially completed development and work toward the other features in priority order over the course of the next sprint.

4. Focus on the Product Before the Project

Product owners are responsible for the complete depth of a solution — from the vision to the roadmap to release, sprint and daily planning. Despite the level of detail product owners help manage, they continue to keep their sights focused on the big picture.

Focusing on the product means crafting clearly defined personas and communicating them to the team, everyone more clearly understands the product vision and how the prioritization decisions made are helping to realize it.

How Can Enterprise Businesses Support the Evolving Role of Agile Product Owners?

Accept that Agile Doesn’t Create an Initial Blueprint

Certain aspects of the Agile process can render adopting and running Agile in large enterprises more difficult. In particular, the lack of an upfront “design and planning effort” makes it hard to provide the basic information a business needs before stakeholders can agree to fund a program. How much will it cost, and how long will it take? Business owners need to sell ROI to their boards and other constituencies and typically the worthiness of a project idea can only be judged in the context of time and money.
Because Agile doesn’t provide explicit cost and time upfront, it also doesn’t provide explicit requirements — these may change as the solution develops.

This leads to a lot of anxiety on the part of their internal/external customers because they don’t see the PO making a “commitment” to build what they need, or they don’t see enough detail to feel comfortable that what was committed to is going to meet their needs.

In both these cases, we know that pretending that you have all these answers up front only results in a “shared fiction”. It’s best if you can acknowledge the shared risks you are taking with loose parameters on cost and schedule that bracket viable alternatives and then let the team use the Agile process to manage to those goals.

This is when the concept of Minimum Viable Product really starts to matter. But with that, there has to be a commitment to future releases beyond the MVP or everyone will lobby hard to make sure their favorite features are in the MVP.

Make Time for Collaboration

With the widespread adoption of Agile framework, new process-oriented demands are being asked of the PO role further constraining time and leading to the transformation of a once 40-hour per week role into one that stretches into the 50-60 hour-work week range.

Before Agile, product owners analyzed revenue goals, supported sales implementation and even assisted when issues with customers arose. Beyond this, product owners managed development, communicated the vision, gathered input and created a roadmap for the evolution of the product.

Serving as an Agile product owner requires product owners to take on a new set of responsibilities — feeding ideas and artifacts through the Agile lifecycle. Product owners are asked to join sprint planning and review sessions along with accepting/rejecting deliverables created by the team. Many also participate in daily standups.

Because product owners are being asked to look at enhancements in the backlog, maximize the value of the product and order the backlog, they are highly familiar with the scope of the product and capacity of the team.

If the team loses its scrum master, there is often a temptation to assign the role to the existing product owner. Avoid this. Overburdening an already full role puts the project at risk, pulling the product owner away from exploring challenges, raising the right questions with users and prioritizing business value and instead focusing their time on managing the bandwidth and organization of the team.

1. Spread development projects out over more groups to focus the PO’s attention and increase the time the need to work with Scrum teams.

2. Encourage product owners managing enterprise solutions to allow development teams the space to create solutions and review them rather than micro-managing the process. In this way, the team may come up with creative ideas the PO hasn’t thought of.

3. Create a test environment where all builds are promoted where POs can test at will.

4. Communicate the acceptance criteria to testers. Empower your quality team to serve as proxies for the product owner alleviating some of the burden of communication.