My product will be very technical. I cannot answer nor understand fully the business requirements, are they are complex mix of finance logic, actuarial mathematics, legacy software architecture etc.

When I try to write and explain user stories developers will start to ask many (legitimate) questions I cannot answer. I facilitate and support the contact with subject experts, but in a matter of nothing, I'm cutout from conversations.

The experts, the endless network of experts that the developers can reach out independently in the company, is starting to drive all the features and milestone of the project.

I tried to be the "proxy", but developers will see me like an obstacle: I cannot substitute several people with many years of experience in many areas. The direct communication between developers and expert will be always more precise and faster.

In some cases I tried to limit he scope of stories and avoid feature creeps, just to hear: "we have to do this because the expert X said it's absolutely necessary". I have no authority to say that's not true, nor the time to deep dive and understand if that's really true.

Conclusion: my role is between impossible and useless. Any suggestion

  • "nor the time to deep dive and understand if that's really true" - if your role is "useless", then how do you not have the time to do something you think might be useful? If your role isn't currently useful, then you would presumably be short of tasks, or have large discretion about the tasks you choose to involve yourself in?
    – Steve
    Commented Dec 23, 2023 at 17:40

3 Answers 3


Although having domain knowledge and expertise is helpful for a Product Owner, it's not a requirement to carry out the role as it's defined in the Scrum Guide. The problem in this scenario is that certain stakeholders - the "endless network of experts" in the company - are driving the work done by the development team. The key role of the Product Owner is to be the single voice that makes the ultimate decisions on how to evolve the product.

Within the organization, there are probably competing groups of stakeholders. These different groups have different priorities and concerns. Not only do you have your various domain experts, but you also have the end users of the software and you probably have other internal groups like security or regulatory compliance. The most important thing that a Product Owner can do is understand what all these different groups want and need and deconflict their requests. When two groups are both saying that their need is the most important, someone needs to make the decision that the team needs to focus on one particular group's needs first. Or when two groups have requirements that are in conflict with each other. someone needs to deconflict those requirements. The person who does these things is the Product Owner.

In this type of scenario, my recommendation is for you, as the Product Owner, to take on more of a facilitation role. Facilitate the discussions between the various stakeholder groups. Build the bridge between these stakeholder groups and the developers to make sure that the developers know the right people to talk to when they start designing and building solutions. Deconflict requirements early. Get the right stakeholders involved in refinement and Sprint Review activities.

If you do not have the respect or the authority to make the final decisions in times of conflict, even if you need to have conversations with affected stakeholders first, then you are right that your role is useless. But that's not necessarily your fault. No one should be saying that you need to do everything on your own. That's not a reasonable expectation. But it can be reasonable to expect the Product Owner to own the key decisions and make the tough calls that need to be made to make sure that the rest of the team is maximizing value.


It's not unusual to encounter business scenarios that are too complex for any one person to understand all the details. As PO, don't try to become a conduit for all the answers. Instead, aim to be a facilitator, in particular for the feedback loop (sprint reviews) and measuring success. Tracking success metrics and listening to stakeholder feedback are ultimately the best ways of seeing whether you and the rest of the team are doing a good job.

Maybe you could also benefit from talking to other POs in your organization about how they tackle challenging pieces of work.


You are describing a typical scenario where the one that shouts the loudest will get the resources - not the topic that has the most value for the company. And this is also the reason why methodologies like SCRUM were invented, so that there is consistency in how software is developed and what gets priority etc.

It cannot be the expectation from a Product Owner to know everything. This does not make sense. Usually the stakeholders always have the most knowledge about a specific domain - which is why they are "stakeholders". The role of the Product Owner is to facilitate the whole process of product development - from ideas and requirements-engineering to the actual development.

In your organisation you could come up with a proposal how the collaboration in your area should work and then discuss that with everyone involved. The proposal should include the responsibilities for each role (stakeholder, developer, PO, ...) and how they interact with each other. This way you avoid situations where informal communication is driving the development.

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.