In the agile/scrum framework, product owners (POs) are key team members. But what happens when more than one product owner is in charge of the same product?
For example, the Far Reach team has an internal product owner on every software project. Each client also brings their own product owner to the table. The two POs work closely together throughout the project.
How can the two POs complement each other instead of stepping on each other’s toes? What’s the difference between their roles? What are the best practices for client-appointed product owners? How can they add even more value to any project?
We’ll answer all these questions and more. But first, let’s start with the basics.
Display Your Agile/Scrum Pride
Download these agile/scrum posters to display around your office or use as digital backgrounds.
What Is a Product Owner in Agile/Scrum?
A product owner is someone responsible for: “maximizing the value of the product resulting from the work of the scrum team,” according to Scrum.org.
Of course, the exact responsibilities of the PO vary widely across industries and companies.
The most common responsibilities of product owners include managing the product backlog, clearly communicating the value of what is being developed, defining stories, prioritizing features, and many more.
Product Owners in Consulting Environments
Most of the documentation around agile/scrum best practices is focused on internal product teams. In that situation, there’s one product owner. But we’re a third-party development partner, so we’ve adapted to have two POs: One from
Far Reach and one from the client.
The Far Reach product owner is the person who works with the team to keep everything about a project on track. They serve as a liaison between the client and Far Reach and work closely with the PO on the client’s side. The communication between
the Far Reach PO and the client PO has to be seamless—we are, after all, on the same team.
Here’s a breakdown of who does what in our process:
Far Reach | Client PO |
Technical expert | Subject matter expert |
Business analysis | End-user advocate |
User experience / user interface design | Timely communication |
Minimal Viable Product advocate | Feature/functionality prioritization |
Iterative development and demos | Timely feedback for deliverables |
Quality assurance | Verification of needs met via end-user testing |
During our years of working with client product owners, we’ve found there are a few best practices that help improve communication, streamline product development, and, ultimately, result in better products.
Best Practices for Client POs
For many of our clients, working with us is their first foray into software development. When you’ve never been behind the scenes of a software project, it’s hard to know what to expect and how to make sure you make the most of the software
development process.
Being a first-time PO on a large software project can be intimidating. You’re expected to live up to the name and really “own” everything that happens with the project. Here are some best practices for client POs, whether you’re
working with Far Reach or another development partner.
Hold Decision-making Power
The fact that I started this article by saying that the PO is a very important team member was not an accident. The person holding this position has to own the product; they have to be responsible for anything related to it.
This role is nearly impossible without empowering POs with decision-making power. The client PO isn’t simply a middle-person between the development company PO and the CTO or another C-level executive who insists on having a say in decisions.
Decisions happen quickly in agile/scrum software projects. The team can’t wait until the client PO goes back to get committee buy-in on every little decision. The client PO needs to work with stakeholders (users, leadership, etc.) to understand
the vision and goals of the system, and then be trusted to handle the day-to-day direction.
In our experience, having a client PO without full trust to make decisions can slow down the development process unnecessarily. When the PO is empowered to make decisions, communication, and the project overall, is smoother and faster, and, ultimately,
less expensive.
Understand the Time Investment
One of the biggest misconceptions we see from clients coming in to a custom software project is the amount of their time required. It’s tempting to think you can create a backlog, hand it off to the development team, and walk away. That’s
how it used to be done in the waterfall methodology, which didn’t exactly lead to the best software.
Client POs are in consistent communication with the Far Reach PO and team. Client POs are expected at a meeting every week or every two weeks (once or twice per sprint) to review work completed, prioritize upcoming work, and more.
Between meetings, both POs communicate by email, phone, and on Basecamp to keep work in the sprint moving forward.
While the client PO is responsible for making day-to-day decisions, sometimes input from others on the client side is required. In those cases, the PO is expected to organize any resources at their organization that are needed for the project
(e.g., users for feedback, images and files, testing, etc.).
As a software development partner, we work hard to be efficient with everyone’s time—yours included. But we also know that most things turn out better when the client and the Far Reach team work together. It’s easy to underestimate
the amount of time required from the client PO, so it’s important to plan ahead and account for plenty of time in the POs workload.
Advocate for the Product
The Far Reach team will provide options and recommend solutions throughout a project. However, we’re not inside the day-to-day operations of your organization. The client PO knows the organization best and is responsible for taking the team’s
recommendations and approving, denying, adjusting, or reprioritizing.
We always keep clients’ best interests in mind, but we’re humble enough (#FRCV11) to
admit that we don’t always know best. The client PO should be an advocate for the product and for the organization―bringing ideas to the table, asking questions, and hashing out solutions as a team.
Advocating for a product can mean making hard decisions, collaborating with Far Reach, and even pushing back on others at your organization. In the end, the product is your priority.
Stay Engaged
Developing a custom software system takes months (in the best-case scenario). Most development processes take years or continue indefinitely.
It’s easy for the initial enthusiasm to slip away and to lose focus. But product owners need to remember that all the phases of the development process are important. After all, we are building a product that could be critical to the organization
for many years to come.
Have the Hard Conversations
When you’re collaborating on a software project, there needs to be a strong level of trust between the client PO and the Far Reach team. That trust takes time to build, but it’s important. This is ideally a relationship that will go
on for years, so the foundation must be strong. We’re all working toward the same goal and want the best outcome. To get there, sometimes we have to have hard conversations. There has to be trust and transparency on both sides.
We’re a Team
Client POs work so closely with the Far Reach PO and team because we know that’s an important ingredient for custom software success. We see ourselves as one big project team. We might operate from different locations, but ultimately
we want the same thing: To build the best possible custom software.
Is your organization looking to work with a custom development partner like Far Reach? Now that you know the best practices of being a client PO,
reach out!