Thoughts on Product Owner interviews a Developer

Last week, a Product Owner I worked with in the past tagged me with an interesting proposition. She was trying to develop some training material for Product Owners. She noticed a lackof content on working well with developers. Moreover, she thought it would be prudent to gather that information from a developer’s perspective. So she asked if I’d be willing to take a survey. I enjoyed the chance to share my experience and perspective. I sincerely hope that it might help future Product Owners. But I wanted to expand on the answers to some of her survey questions, so I suggested we have a call. That call turning into a bit of an interview, which I shared earlier this week.

I stand by the content in that interview. And I enjoyed the conversation, but an hour is a bit short to cover everything in her survey. I want to take a little time to expand on a handful of topics which weren’t in the interview.

What do most POs get wrong when they talk to you and your team?

I alluded to common miscommunication between Product Owners and Developers in the interview. I believe part of this issue comes from the nature of our respective roles. The Product Owner, in a manner of speaking, lives in a different world than the Developer. Our day to day usually revolves less around meetings and more around focused time generating code. From the part I have seen of a Product Owner’s average day, their day spins in the circle of various stakeholder meetings. Sometimes they have emails, and on occasion PowerPoint presentations or product demonstrations. These different worlds come with different world-views.

The Product Owner is exposed to, and deals in customer needs and wants. That is their bread and butter. Sometimes they even have dedicated metrics which allow them to express progress in the things which matter to them. Developers are exposed to the minutia of code, and design. They deal in systems, and needs of systems. That’s our bread and butter. And just like POs we can have dedicated metrics which allow us to express improvement in the things which matter to us.

And it’s that last phrase which carries all the weight: ‘what matters to us’. For Product Owners, what matters to you isn’t always known to the Developer. I had never even heard of base points until that fateful meeting when the Product Owner had explain how the code we were writing would affect the sales in those units. If my Product Owner had started talking about the affect to Base Points before that time, I would have been lost.

So the nature of our work has us spinning in different spheres. Our eyes are on different parts of what matters to the business. Developers need to translate for both humans and machines. Effective conversations between Product Owners and Developers need some translation as well.

What do PMs usually get wrong when writing stories?

I have several strong opinions on this topic, but I’ll constrain myself to User Stories for this post. In my opinion user stories go wrong when they try to answer ‘how’ in any level of detail. When a Product Owner writes a user story, the most valuable piece of information that can be included is the Why. Why are we be asked to write this? What business value or potential value are we seeking? In the interview, I touch on the idea of Bets or Experiments with regard to User stories, so I won’t dive on that here.

But in this area, I can recommend some tools which can help Product Owners avoid answering the wrong questions during user story writing. Try the ‘So that… as a … I want to …’ format. This starts your very focus in a story with that Why. Then you fill in the necessary scenario information with the ‘Who’ performing a ‘What’. That allows the Developer to do their job of answering ‘How’ your Who can perform that What to meet your Why.

When you’re writing the user story, don’t be afraid to involve a handful of developers in the writing the AC. Now don’t get me wrong, AC is wholly the purview of the Product Owner. Your word is law there. But even when writing the Law, we write it in a certain way for to be understood by the parties who have to use it, right?

So when you are writing the AC, work with the developers on the wording so that it is clear. I expect that the involvement will reveal some other ways the team can improve. You’ll need to set expectations properly for this to work well. But I also expect that involvement, can also improve the Team’s buy-in on that story, which can improve your effectiveness. Consider the Given-When-Then Format as a possible tool. But please keep those GWT short, sweet and focused. Too many Ands usually is a sign that the format wasn’t applied properly.

How has a PM misrepresented you or your team?

I believe Product Owners and Developers can only form effective team units if Trust and Respect are present from both groups to both groups. If respect is missing, the group is setup for pain. If trust is missing the group will be less than effective. But both of these attributes are created by actions beyond ‘just the work’. How the work is conducted affects them. And the spirit in which you deliver the work colors them. These attributed are only maintained by intentional actions by both groups.

In saying that, the deepest cut I ever received from a Product Owner was a single remark in a meeting. That single remark then spun into a web of new difficulties, dropped expectations, and missed promises.

In the interview I alluded to the role of the Product owner in Sprint Planning. Specifically I believe the role calls for the Product Owner to own prioritization. Meanwhile the team provides input on Complexity, and Cost, and Dependency. But all the input from the team can be unintentionally diminished by misplaced words.

‘It’s easy’. Dangerous words.

The Product Owner, in full confidence of the team’s ability, bit off more for us than we could chew. As a result, promises were made for aggressive timelines. And we later found out we could not reach due to an unforeseen complication. The team had warned that there was some uncertainty in the area we were developing. But, truthfully, we didn’t know it would be that bad.

The result of those words made it very difficult for the team to adjust expectations to the discovered reality. The affects on Respect and Trust were worse. The Team’s trust in the Product owner plummeted, and the team’s perceived Respect from the Product Owner also took a hit. Both hits negatively impacted the team’s effectiveness for months after.

Product Owners, you occupy a special position between the Business and your development team. The nature of that position give your words out-sized weight in how the business perceive the team. I will be the first to admit, that we developers might have somewhat fragile egos. But everyone wants to be well-thought-of. When you represent the work of your development team, please pick your words carefully. It’s our reputation which suffers, or improves all hanging on your words.

I hope the deeper dives on these three topics fill in some additional gaps or offer some additional tools. I’d encourage you to give the interview a listen, since this post was written as a companion to it. And in all your work, godspeed, and God Bless.