Once upon a time, there was only product manager. Then the concept of product owner came in to the picture. It puzzled many, because we were creating software products before and there were people leading products.

However, it became impossible to keep up with the demand for increasing the frequency of impactful releases with sufficient quality while maintaining current roles and communication structures and tighter feedback loops. We can observe indirect impact of Kano Model on software products in terms of increased workload and expectations on product managers. Product owner definition helped standardizing role for certain parts of product leadership.

Over the years we have seen tons of organizational revamps and lots of confusion about product managers and product owners. Some happened out of necessity, some due to cargo cult phenomenon. Wrong decisions in this area can easily have catastrophic impact on products.

So many questions echoed in meeting rooms:

• Should we just rename product managers to product owners ?
• Or should be just rename our business analysts to product owners ?
• Should we have strictly one product owner per product ?
• How should product owner spend time ?
• Should we just copy what company xyz did ?
• Does product owner have to write all of the stories and epics ?
• Should all of the team report to the product owner ?
• Is it forbidden for the product owner to write code ?
• Should product owner understand the underlying technologies ?
• Can product owner make technical decisions ?
• To whom product owner should report ?

The list can grow. In most cases, the right answer depends on various factors whose combination will be unique to you. Although there are frameworks that try to force feed pills, finding right answer depens on asking the right questions focusing your situation.

The amount of work that needs to be done efficiently and with high quality by product leader/s will not change.

Scrum guide defines product owner’s purpose, accountability and responsibilities. Since it’s designed to be a framework, Scrum defines what and how regardless whether it fits for your case or not. Still, even the Scrum guide doesn’t define strict borders on how a product owner should do its job. It’s possible to find different frames for how should a product owner be like.

Following is my attempt to visualize some of the work product leadership should cover. Not all of the items are needed to happen in all products. (But it’s not rare as well)

Myths & Mistakes

Myth: Only product owner may write user stories

One of the most common myths. There is no such requirement. Accountability on user stories and prioritization doesn’t imply that product owner has to do them personally. If product owner is satisfied with the user stories written by team members and prioritization done by them, that’s also fine. Actually this enables sharing load and increasing cadence because product owner stops being a bottleneck. If product owner delegates those because having no time, we have a dangerous situation. Because this kind of delegation must happen based on mutual, earned trust.

Myth: Product owner is the single leader of the product

Also quite common and dangerous. Here, product owner is expected to do pretty much everything in the above picture. With this approach, success relies on one person having outstanding skills in all of the responsibility areas, and enough time to spend with all of the internal and external stakeholders + team. ``

Myth: Product owner’s job is to accept and deliver everyone’s feature requests

Some environments tend to see product owner like mailbox for wishlists. (Often those are traditional environments where software is seen like thing that you can just ask and get new things) This results in a product that makes noone happy, always late, and haunted by quality issues. One of the most important work of a product owner is to be able to say “no”, far more than rarely. Product owner is not a wishlist-to-user-story translator.

Myth: Product owner may not write code

No such rule exists. Product owner may contribute to the code as well, if there is time. Taking out product owner hat and putting on developer hat requires self discipline as well. It’s doable if fundamental responsibilities of being a product owner isn’t neglected.

Mistake: Choosing the most senior engineer in the team as product owner

One of the most common and deadly mistakes. The root cause is often misunderstanding of the product owner role as a person that just listens what stakeholders want, converts them to user stories and follows that up. In this scenario we also have the who knows most about the product technically. What could go wrong ?

Actually, that’s dangerous oversimplification of the role.

Being a product owner with technical background is a great asset but never enough. Product owner steers the direction which requires great understanding of the business domain, product vision, and having strong negotiation and communication skills. Being a great engineer doesn’t guarantee being a great product owner.

Mistake: Cost saving when recruiting product owner

Competency of product owner defines the upper limit of the product success. No matter how great engineering team is, they will be limited by the competency of the product owner. If accountability of steering the product needs to be split between a product manager and a product owner, both of them need to be highly competent.

While there is near certain disaster for the bottom left, the success isn’t guaranteed for the top right. Failure is still possible after doing everything in our control right.

Mistake: Disconnecting product manager from the team

Sometimes, since there is a product owner, product managers tend to spend much less time with the team, may be from quarter to quarter. Such disconnection prevents product manager from understanding team’s activities, dynamics, challenges, capabilities, problems, opinions etc.

When product manager lacks interest for mingling with the members of the team, a valley between product leadership and engineering opens. A product where engineers are alienated has hard time for success.

Mistake: Denying the need for product manager/owner split

Not every product will require deep activities mentioned in the picture above. When the amount of work grows beyond a product leader’s capacity and competency, overlooking this situation can become disasterous for the product. Keeping focus on what needs to be done for the product, works better than blindly following guides.

Mistake: Making the engineering teams report to product owner

While it may sound reasonable at first, this creates a serious conflict of interest. Product owner is best as an individual contributor role where the relationship with the engineering team is at collaboration and leadership level, not at people management level. The tension between product goals and engineering management is a healthy one to maintain.

Myth: No one other than product owner may speak with customers

Another common myth. In this one, engineering team is instructed to avoid communication with customers, stay out of feature discoveries and instead always refer to the product owner. In almost all cases, maintaining direct interaction between engineers and the customers, whether during problem solving or discovery, allows team members to listen from the first hand the views from the other side. Giving any sort of commitment is still an action only a product owner can do. But there should not be any artificial barriers for direct communication.

Myth: Product owner’s decisions are static commitments

Product owners prioritize and commit. First one very frequently, the second one as needed. Putting pressure on product owners to define detailed, exact roadmap and delivery months or year before, is against the empirical nature of software engineering and the world works. At any point in time, we are positioned worse in the cone of uncertainty compared to weeks, months later. Therefore pushing product owners to commit prematurely negatively impacts product and customers.

Myth: Product owner must approve every release

Another common myth and also bottleneck for the team. The software development lifecycle should be implemented in a way that team generates releases that have enough quality to go on production, if desired. Product owner may decide to promote a release to go on production, or may decide to delegate that decision for different levels of releases (Hot fixes, minor changes etc)

We can ask the same question about scaling: “I want product owner to approve every release. How will that work when there is 10 releases/month ? or 10 releases/week ? or 10 releases/day ?”

Teams should find their way of reducing gatekeeping in a safe manner. Time sensitive releases (Product launches etc) might always require explicit decision. But if product owner acts as a “quality gate” to approve a release, then that apparent lack of trust in quality is an engineering problem and needs to be solved there.

If we dig deeper, we will find more myths and mistakes that undermine organization’s product.

All kinds of transformation examples, frameworks, guidelines, models are vessels for inspirations, perspectives for designing our own way towards an evolutionary organization.

The work that needs to be done is out there regardless we have a product manager, owner, both or none. The goal should be evolving to a future state where those can be done properly and efficiently.

Falling in to the trap of myths and mistakes, copy-pasting approaches, walking around with a cookie-cutter at hand, aren’t the best ways towards that.