PO and development team, the importance of good collaboration

This article will showcase the importance of the relationship between the Product Owner (PO) and the development team, especially when the PO is an external client. The differences between working with an internal PO and an external PO are numerous, but sometimes subtle. Note that I’ll make no distinction between internal and external end-users (internal tools vs software products) in order to avoid muddying the issue.

Full disclosure: for almost a decade before co-founding Spiria, in 2003, I worked on software products with internal POs, except that back then, we just called them “product manager” or “boss”. I’ve therefore experienced both situations, and can offer some perspective.

Playing for the Same Team

Generally speaking, a significant difference between an internal and an external PO is the feeling that everyone’s playing on the same team: it’s us, the product team, versus them, the barbarian hordes beating down the door. The smaller the company, the greater the feeling, especially for software products. With an external PO, there’s the risk of developing an us versus them mentality, with “us” being the PO-Client and “them”, the development team-Vendor.

In my experience working with external clients, the most successful projects always had the PO and development teams working closely together, with virtually no client/vendor separation. The product team, the us, made concerted efforts to improve the final product, including postponing features to concentrate on reducing the technical debt, or taking shortcuts when necessary.

On the other hand, when the PO and development teams do not work together seamlessly, there’s a constant tug of war between the two. In time, the development team will become less engaged in the project’s success and will start simply following the PO’s orders. On long-term projects, quality will suffer, and project members may request to be moved to other projects, creating project waste.

Opinions Matter

One of the biggest misconceptions I’ve heard about working with an internal PO is that you get to work on whatever you wish. Want to switch from PHP to Node? Why not. Add a new widget? Sure! We really need admin reporting before user logins? You got it.

If the PO says yes to everything, it means they’re not doing a very good job. They should be steering the project in the right direction, truly prioritizing ideas and keeping a tight rein on the budget. Some people may find it easier to influence an internal PO because they are on the same team, but in well-managed companies, even internal POs have budgets and deadlines.

On the other hand, if the PO says no to every suggestion, they may also be doing a poor job. Of course, sometimes you need to keep the MVP’s features under strict control, for example when a trade show is coming up. But that is the exception. Listening to the development team’s ideas goes a long way towards meshing everyone into a functioning product team.

No Technical Debt

I’ll admit that a younger me would have had a fit reading what follows. I used to believe that all technical debt was bad. Everything had to be engineered to be future-proof, everything had to be optimised just right, and everything had to be handcrafted just so.

In an ideal world, that may be possible. But we sure spent a lot of time refactoring code on seldom-used features! With time, I’ve come to realize that sometimes it’s okay to take shortcuts to test a feature out. It may not be as pretty as it could be, but it’s safe and won’t give you cancer – so let it go, add a refactoring story to the backlog and move on.

Once again, it’s a balancing act. In my experience, external POs tend to be a lot less forgiving about technical debt than internal POs: “Why did you create this debt in the first place?” I can’t stress it enough: this is near-sighted, and can result in every feature taking an inordinate amount of time to complete. If you only get one chance to code something, then you’ll want to make it squeaky-clean from the outset. Which can create waste if all you needed to do was test a feature.

Flexible Budgets and Deadlines

With an external PO, there’s this sense of having a finite budget, whereas when the PO and the development team are on the same payroll, there’s the feeling that the budget can somehow be more elastic. Likewise, with an external PO, arbitrary deadlines magically turn into hard dates.

It’s sad, but true. It may stem from the fact that external POs, when receiving a copy of the invoice from the development team, track projects against dollar amounts, whereas internal POs track projects against time. And because internal (arbitrary) deadlines can be changed, internal budgets appear to be more flexible than external ones.

This may have been true in the past, but nowadays, there’s increased pressure on internal POs to manage their projects with greater rigor.

In Conclusion

Regardless of the project, a key factor to ensure success is to have the product team (PO and development team) work together, as a single unit. Everyone needs to be aware of the deadlines, the constraints and the goals of the project.

When product teams collaborate well, technical debt is kept at a reasonable level, features are prioritized appropriately, deadlines are met, and the budget is kept in check. And this holds true whether the PO is internal or external.