Best Friends Forever – Product Owners and Software Developers

Agile teams are at their best when the team has a culture of collaboration and aligns on shared goals. One of the most important relationships within the team is between Product Owners and Software Developers.

When I say “Product Owner” in this discussion, I mean the person who is most responsible for making decisions around optimizing the delivery of business and user value. This includes developing or articulating the vision and goals of a project, deciding which features are critical, and deciding the best order to implement things. This person might have the title of Product Owner, Product Manager, Business Analyst, or something else.

“Software Developer” is anyone responsible for delivering the software that creates the optimal business and user value discussed above. This includes defining the technical direction for a project as well as anticipating and removing impediments. Software Developers help balance things like timeline, scope, and architectural purity.

The most important thing for positive interactions between the Product Owner and Software Developer is for both to always work with good intentions of delivering the most value. There are inevitably going to be disagreements and moments of tension, but those should be because the two parties see different routes to providing the most value. There is plenty of room for difference of opinion when one considers short-term value vs. long-term value and especially when weighing short-term business and user value vs. long-term maintainability of a platform. Believing that the other person is making a good faith effort toward the same goals makes it easier to work through differences.

That is why it is so important to make sure the team is in alignment on the business goals of the project. Understanding WHY they are building the solution and focusing on outcomes over output is needed before trying to improve the interactions between Product Owners and Software Developers.

Product Owner and Software Developer Interactions in Backlog Refinement

For some context around interactions between a Product Owner and Software Developer, let’s introduce a fictional company and project.

Midwest Sports runs adult recreational sports leagues. They are currently operating in 4 cities but are looking to be in 15 cities in 5 years. They have about 2500 teams right now. This project is to create a new platform to run their business. Today they are using a combination of free and paid tools along with spreadsheets. These disparate systems cause problems for both Midwest Sports and their users, and cutting over to an integrated solution will create a better experience and allow the business to scale.

Let’s now jump into a backlog refinement session in progress to see how the Product Owner and Software Developer interact.

“We can’t do that”

The Product Owner brings up a feature (or “Product Backlog Item” or “User Story”) for viewing all of the teams in a given league. The plan is to put this information in a paged table with columns that can be sorted and filtered. When the PO finishes describing this, the following exchange occurs:

Software Developer: “We can’t sort on Sponsor name.”
Product Owner: “We heard from our users that this is useful to the admin in charge of each league.”
SD: “Well we can’t do it.”
PO: “Why not?”
SD: “The Teams are in the Team Domain and the Sponsors are in the Sponsor Domain, so we can’t join from the Team table to the Sponsor table. And we do our sorting database-side because of the number of teams we have. To be able to sort on Sponsor when displaying a list of teams, we’d have to re-architect our domains or do something like sync all of our data to Elastic or similar for searching.”
PO: “I’m sorry, I don’t understand what any of that means.”

What went wrong?

There are two antipatterns to avoid in this exchange. The first is when developers say “we can’t” as a shortcut for “this is more complicated than it sounds and I suspect that the time required is not worth the value.” Directly addressing the cost vs. benefit can short-circuit a lot of back-and-forth. If possible, be sure to include a recommendation for solving the problem; don’t just explain what can’t be done.

The second antipattern is an overly technical explanation. Even if the Product Owner does have the technical background to be able to understand the architecture discussion, this conversation should happen in the context of the value provided, not architectural standards. Remember that architecture best practices weren’t created in a vacuum – they exist because they are proven ways to provide value.

What’s a better way to do this?

When the PO finishes describing the feature, the following exchange occurs:

SD: “How important is it that we sort on Sponsor Name? That is much more expensive than the rest of these. We can easily filter on Sponsor Name, but not sort.”
PO: “We heard from our users that this is useful to the admin in charge of each league. But I think we’re OK to release with just filtering, and we can always evaluate adding sorting later if we get a ton of requests.”

Backlog Prioritization

After that feature is sorted out, the PO asks about some items in the backlog that seem to be new. The Software Developer responds:

I created a spike for the data import functionality. We are hoping to forecast the rest of the project. The data import has a lot of uncertainty – we don’t know if that will take 2 days or 2 weeks. To reduce uncertainty in a forecast, we should spike on that sooner than later.‍

This approach is good, but make sure that you have established ground rules for interactions with the backlog. The Product Owner is the one who is ultimately tasked with owning the backlog and prioritizing the team’s work. Some POs may want to personally add items. Some may be fine with anyone adding and moving things. Others will be somewhere in between – ok with anyone adding to the backlog, but expecting enough detail on the item and a heads up when it happens. As a team, discuss this and make sure everyone knows the expectations! But don’t shy away from making recommendations that will make the project successful.

When Software Developers add something to the backlog or move something higher in priority they should expect to justify that in terms of business value. This is true for technical debt items; developers should feel empowered to make the case for tackling technical debt, but they should explain the benefit of the investment. This can be as simple as a 30-second explanation of “Why this item” and “Why now.” The developer prioritizing this item should have already made this calculation in their head, so it just needs to be articulated.

For example, maybe code has been copied and pasted in multiple areas and the team is spending an extra couple hours of a developer’s time and an extra couple of a quality engineer’s time every week. If fixing this would take 12-16 hours, then the team will break even on that investment in 3-4 weeks. The earlier it is made, the more the team and project will benefit. This is all information the developers have but the PO doesn’t, so it is important to make the case for prioritizing that investment.

A Focus on Goals

Next, the PO introduces a feature that discusses limiting access based on a user’s city. For example, an admin user in Milwaukee does not want to see all of the leagues in Chicago, and should not be able to edit anything in those leagues. The following exchange occurs:

SD: “I get why they want that feature, but it will be super complicated, and it’s not something they have today.”
PO: “We heard that it’s critical for the release. Before growing into other cities, they want to make sure that users’ access is locked to the city or cities they’re associated with.”
SD: “We agreed that the goal for the MVP was to replicate the functionality that they are using within Bracket Wizard and integrate it with their public site, then include functionality in later releases to eliminate the need for the other spreadsheets. Locking down user access by city does not fall into those goals.”
PO: “But can we do it?”
SD: “Yeah, I guess. But it’s going to be messy and expensive.”

What went wrong?

In this case, replicating functionality from the other tools was not the true business goal for the first release; the business goal was to iteratively allow Midwest Sports to scale. The team fell into a trap of thinking that because they had a clearly articulated goal, they understood the Why when in fact they were still focused on the What.

However, this is a great time to ask difficult questions about what is critical for the first release. One way of thinking about this is asking “If everything else was done and ready to be released, would we delay the release for this feature?” The Product Owner should work with Software Developers to understand the cost of a feature, then use that information to build a business case to take to stakeholders to argue for or against including the feature in the next release.

Getting major requirements after work is well underway can be frustrating and should get appropriate scrutiny, but cannot be avoided 100% of the time. When it does happen, it may be a good topic for a retrospective.

When to Compromise

The team has one last feature to chat through. Midwest Sports partners with a trivia organization and teams are used to seeing their trivia data on the Midwest Sports website. Today, downloading the data, manipulating it, and uploading it is a manual process for admin users. This feature is to partially automate the process, removing the need for the manipulation and simplifying the upload. After the PO describes this, the team has this conversation:

SD: “So users are OK with manually downloading the data from the trivia site and uploading it into their admin application?”
PO: “Yes, that will save 75% of their effort. So they could now do this twice a week instead of every couple of weeks, and still come out ahead.”
SD: “That makes sense. We’ll still need to break this one down a little, but I think it’s pretty straightforward.”

What’s wrong with that?

On the surface, that conversation seems pretty good! But did the team compromise on the ideal functionality too early? The PO came with a solution instead of a problem, removing the team from the process of generating the most value and making assumptions about complexity.

What’s a better way to do this?

Rather than coming with just the solution (partially automating the process and leaving part of it to be done manually), the PO could clearly articulate the problem — it takes admins too long to manually download, manipulate, and upload the trivia data, so they do it less frequently than users want.

The PO could also start with a more ideal solution – full automation and daily updates – then compromise only after learning that the benefit is not worth the cost. For example, if fully automating the process will only add 20% to the estimate, the PO may say that that is well worth the benefit. However, if it doubles the time, then the PO may choose to compromise and only automate the data manipulation.

This isn’t just the responsibility of the PO – the team should recognize this as well. The goal should not be to develop functionality, it should be to efficiently deliver value to the business and users.

Is it that simple?

There is a catch! Communication is very important here. If the PO always brings the ideal scenario and the team nearly always cuts pieces out, that can be demoralizing. The team can feel like they’re constantly cutting corners to rush the first release to production. This can make the team no longer feel proud of the work they’re doing.

When built on trust and good communication, waiting to compromise at the right time can help deliver massive value. When a PO comes with 10 bullet points, a developer can point out that two of them make up half of the total effort. If those aren’t truly necessary for the first release, the team can deliver 80% of the value in 50% of the time.

We reviewed some common scenarios that might come up in backlog refinement and how to best approach them. When things go well, Product Owners and Software Developers can reinforce each other’s strengths. Product Owners help the team understand what the customer wants and needs, both in the short term and long term. Software Developers help the team understand the cost of various features to provide the most short-term value, and can make recommendations for building a solution in a way that lets the team efficiently add value later. When they work together and establish trust, Product Owners and Software Developers will make the team more effective, make work more satisfying, and deliver the most value to the business.

 

About the Author

Paul Bemis is an Engineering Lead in our Milwaukee Development Center who’s passionate about helping development teams deliver more value more quickly. He has 12 years of development experience in a variety of industries and a variety of individual contributor and engineering leadership roles. Outside of work, Paul can be found watching or playing a variety of sports and is currently captaining his kickball team.