0

In the Scrum framework, the Product Owner is the person responsible for preparing the backlog, refining it, and prioritizing it. He/she is expected to be a domain expert and somebody with enough technical knowledge to make meaningful decisions on what to prioritize first (with the involvement of the dev team, of course).

DDD advocates for a technique of sharing domain knowledge by making developers and domain experts talk together to build and refine the domain model through several iterations.

In my experience, both cases rarely happen in real life scenarios. The time commitment and the interests of the people involved in projects rarely fits those two ideal scenarios. In my experience, the Product Owner has the tendency to care more for the user/customer point of view, rather than the technical/architectural design. The Domain-Driven Design approach of iterating over the domain model to improve it also rarely happens, mostly because domain experts, at some point, don't have time/interest to follow the iterations.

Is there an approach that tries to solve these inconsistencies that I found? I came up with something artificial for my projects: a team of product owners, a "technical product owner" that cares about the technological and architectural part, and a "user/Customer product owner" that instead advocates for the customer/user/workflow point of view.

1
  • 2
    In your vision of Scrum, the Product Owner leans more technical than the other stakeholders (who are not particularly interested in the technical details), but still has broad depth of knowledge of the product domain. In my last two jobs, we had such a person (who also acted as gatekeeper for new feature suggestions from the other stakeholders); that arrangement proved very effective. The technical product owner doesn't "lose interest;" they are committed to continuous iteration, because that's the nature of good software design. Commented Aug 29, 2023 at 11:58

4 Answers 4

3

The situations are so diverse that there's a whole book to be written about this - Patterns of Product Ownership maybe? (*)

Sometimes the Product Owner is a catalyst of multiple business experts' ideas and synthesizes/prioritizes/greenlights them.

Sometimes they are more of a product line manager and give direction and meaning to the software product, maybe with a special emphasis on branding/marketing/user friendliness and an eye on the market and competitors.

Sometimes the Product Owner is the prominent domain expert.

I could see any combination of PO/Domain expert roles working, depending on your context - although one I would advise against is the "technical product owner" you mention. They can be as tech-savvy as needed, actually it is a requirement in a lot of cases, but not to the point of having a say in the technical architecture and implementation. Eric Evans has a great example of dev-domain expert dialogue in the DDD book and the kind of language it uses. It is one thing to understand application use-case level terms such as strategy, policy, mapping, process, maybe CRUD, but another to talk about architecture, code and implementation details.

Of course, involvement of domain experts remains key and I don't think there's a good alternative to business experts spending some time with the devs if that's your problem.

( *) The book Agile Product Management was a reference back in the day but I'm not sure it explores the different combinations of product owner and business expert in a lot of depth.

3

Your understanding of Scrum's Product Owner isn't correct.

Instead of being responsible, the Product Owner is accountable for the Product Backlog. Responsibility is about performing tasks, while accountability is about the outcome produced by completing those tasks. The Product Owner is indeed accountable for "preparing the backlog", with respect to crafting and communicating the Product Goal, creating and communicating Product Backlog Items to stakeholders, and ordering (not prioritizing) the Product Backlog Items. However, the whole team participates equally in refinement.

There's no requirement that a Product Owner has "enough technical knowledge to make meaningful decisions on what to prioritize first". Technical knowledge, although likely to be extremely beneficial, is not an inherent requirement for the Product Owner role. If they do not have the necessary knowledge to carry out a task, they may delegate the work to others or collaborate with (or facilitate collaboration between) various stakeholder groups to make sure the necessary work gets done. The only rule is that, regardless of the correctness of the decision, the organization and stakeholders respect the decisions of the Product Owner. If the decisions fail to maximize the value of the product or if Product Backlog management is not effective, then the Product Owner can be held accountable.

What you describe as the Product Owner is closer to the role of the Chief Engineer in the Toyota Product Development System. Although the Product Owner was, supposedly, modeled after Toyota's Chief Engineer, there are plenty of differences between the two roles. Over time, I'd continue to expect the definitions of both roles to evolve.

Since the Product Owner doesn't necessarily require deep domain knowledge, then the domain expert that the developers should be talking to may not be the Product Owner. However, making sure that a domain expert is available (or even on) the team can be helpful. One of the principles of not only Scrum, but agility in general, is having a cross-functional team. Domain expertise is one of those functional areas that needs coverage, regardless of who provides it.

Lack of time commitment is also a real problem in many organizations. You can see this in organizations that have one Product Owner trying to own two or more products, or a Scrum Team trying to work on multiple products in active development at once. Coupled with the complexities inherent in product management and software engineering, you see a lot of wasted time in context switching and other types of overhead work.

There are several solutions to these problems, though.

Your solution - to have a team of product managers - is viable. Although I would be careful with the term "Product Owner". The Scrum framework is explicit - "the Product Owner is one person, not a committee". You may find that a pair or small group works well for you and your organization, but the Scrum framework, as it's defined in the Scrum Guide, is immutable. If you don't have a singular Product Owner who is accountable for the defined outcomes, then you should not use the term Scrum to define your process.

A solution that would be more consistent with Scrum would be to ensure that you have the right domain expertise on the team as a Developer. Since Developers are responsible for instilling quality into the product and Domain-Driven Design is, at least partly, about quality of the domain model, you need someone to be able to validate the domain model in near-real-time with the team. If the team doesn't have domain knowledge on the team, then this is an impediment that the Scrum Master can assist in removing, perhaps by working with people outside the team.

Personally, I like the idea of Toyota's Chief Engineer and I've felt that a Product Owner that has a much deeper technical knowledge, but also an understanding of the customers and users and can work with support, sales, marketing, and other externally facing groups to understand the state of the world can be extremely powerful. However, the pool of people with not only the knowledge and skills but interests to do this kind of work doesn't seem to be large.

Like most things, when designing an organization and a development process, there's no right or wrong answer. You would have to find what works for you in your context, and it looks like you have, at least for now. If problems arise, you can rethink the decisions and make the right adjustments.

4
  • 1
    Thanks for the detailed answer. In my experience what I saw is that this: "The only rule is that, regardless of the correctness of the decision, the organization and stakeholders respect the decisions of the Product Owner" is frequently broken. This can be broken by the technical side, if the product owner takes decisions that prove to be technically wrong, or on the Domain/user side, if the decisions result in workflow/features that are not well perceived by the market. Maybe the answer here is that the PO should learn from his/her mistakes, but this is easier said than done
    – BiA
    Commented Aug 29, 2023 at 13:20
  • 1
    @BiA, I would not call it "disrespecting a decision" if you challenge a decision based on your expertise telling you it is a wrong decision. It would be disrespectful if you quietly disregarded the decision and went in another direction. Commented Aug 30, 2023 at 8:09
  • @BartvanIngenSchenau What I meant is the former. There are several ways to not respect a decision, you can quietly go into another direction or decide to not invest time in following a decision you believe is not right. Anyhow the result is the same, the PO took a decision, but there is no follow up on it, no action.
    – BiA
    Commented Aug 30, 2023 at 9:08
  • @BiA The expectation, in my experience, is disagree and commit. There are certain decisions that are left to the sole discretion of the Product Owner. Once the decision has been made, the organization is expected to commit to it and execute on it. The Sprint Retrospective could be a good place to talk about how decisions are made. And the organization that the Product Owner works for can decide to replace the Product Owner if the decisions are not sound. Going quietly in another direction or ignoring the decision entirely is unprofessional.
    – Thomas Owens
    Commented Aug 30, 2023 at 12:03
3

This is mostly a people problem.

First, in Scrum, it is clearly not the responsibility of the PO to develop and evolve the domain model. That's the responsibility of the developers. Have a strong architect or senior dev in the team who says "PO, for implementing this next backlog item you gave us, we first have to evolve this specific part of our domain model, and discuss if that really reflects the requirements", then domain modeling will take place. But if noone is there in the developer team who feels to be responsible for maintaining a consistent domain model, it won't happen.

Second, though a domain model can help your dev team, your domain experts and the PO to communicate with each other, this is not the only possible or correct way for discussing and analyzing things. When your "domain experts at some point don't have time/interest to follow the iterations", as you wrote, then the domain model might have become a too technical artifact at that point. You can still bring it into discussions with the domain experts whenever and whereever it helps to clarify things. But you can also decide to use it only among the developers, as an implementation of certain domain knowledge gathered through the discussions with the experts. For lots of teams, that is a viable decision.

1
  • yes I agree it is mostly a people problem, and I agree with both your points. What I saw in practice is that, especially in smaller teams, the role of the PO only is effective if there investment from his/her side on the domain model and the technical part.
    – BiA
    Commented Aug 29, 2023 at 13:18
0

The Product Owner main responsibility is to define a clear priority for the team direction. But they're not the owners of the Domain Expertise. They can of course be experts in the field, but being the middleman between business stakeholders and the team can provide second-hand knowledge that can negatively impact the team outcome.

Put in another way:

  • the PO must mediate between the stakeholders' conflicting priorities -> priority conflicts should not affect the team;
  • the PO should not put themselves between the team and the domain experts -> conflicts and inconsistencies in terminology and goals should be visible to the team and resolved accordingly.

Domain knowledge that gets flattened before being served to the team dramatically increases the probability of design coupling.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.