Skip to content

How to Cooperate with External and Internal Product Owners?

Project Management

Nov 24, 2020 - 7 minute read

Blog Post Successful Cooperation Between Bas And Pos 416X300
Sandra Samor Business Analyst

Sandra is a Business Analyst with more than 3 years of professional experience working with both internal and external product owners. She loves books and Italian food. She spends her free time traveling.

See all Sandra's posts

HC NHS Survey Blog Ad


Responsibilities of a Business Analyst may differ significantly, depending on the organisation they work for, but they always involve participating in meetings and talking to people. Business Analysts are particularly involved in conducting workshops, discovering the business needs, building and refining project backlogs, and then passing them on to the development teams in the proper way. BAs perform these tasks in various projects, both in-house and external. Every project is one of a kind challenge, but in general, we always work with numerous people who fulfil a very wide range of project roles.

However, we cooperate most closely with Product Owners. They represent groups of stakeholders and make decisions regarding the overall shape of the solution and the order in which functionalities will be delivered. Since this role is extremely important in the project delivery process, this article will focus on working specifically with them. How does working with a Product Owner differ in in-house and external projects? What if the Product Owner is inexperienced and it’s the first time they find themselves in this role?

For the purpose of this article, we can try to build a simple definition of the Product Owner role, working in in-house and Client’s projects. In an external project, the Product Owner is a person outside of your company. They work for their own organisation—the Client who ordered the software solution from your company. On the other hand, a Product Owner in an in-house project is a person within the same organisation as you, and together you’re delivering software to satisfy internal needs. In this case, the entire project is run without any involvement from the outside.

In both scenarios, cooperation with Product Owners is associated with certain challenges that are relevant to many areas, such as creating a business case, dealing with stakeholders, communication, and domain knowledge.

Business Case

In all types of projects, a business case is a very important element. You need to encourage the Product Owner to calculate costs and revenues, to present the business value of each solution. In the case of the projects run within your organisation, as a BA, you have a big impact on the approach and way of preparing the business case. You’ll often be a member of the project team. It’s extremely important to never lose sight of cost. The lack of proper overview and justification can result in making decisions on the spur of the moment. If at a certain point the change seems to be important, it often gets implemented. However, much depends on consciousness. As Product Owners gain more awareness and project experience, they start to understand the importance of the business case.

In an external project, the business case is often prepared by the Client and you don’t have the opportunity to review it. That said, you should always try to get more details about business value. There are some methods that you can use to discover the business purpose (i.e. 5Why, interview or an analysis of the project documentation). You should always be familiar with the business goal because you’ll often be the person who has to explain it to the development team. People who deliver the software are usually interested in the value that their work brings.


As for in-house projects, you’ll usually know who the Product Owner is and what are their roles in the organisation. Moreover, you’ll likely receive some information from other people who have experience working with this person. Keep in mind that it may cause some prejudices or result in relations that are too friendly. On one hand, it can make cooperation easier, but on the other, it can sometimes undermine the true objectives of the project. The relative ease of entry is a great aspect of the in-house projects. You might not be an expert in this specific area, but you already know the environment. It makes it much easier to understand dependencies and identify stakeholders.

In the case of Product Owners on the Client’s side, you will rarely know what’s happening in the company outside the project, both in terms of financing and the interpersonal relations within the organisation. Especially when it’s a new Client with whom your company is just starting the cooperation. The relationship is the most formal at the beginning. Your access to the sponsor is often very limited or entirely non-existent. You’ll be aware of their existence, but you’re unlikely to meet them due to the fact that they often are a high-ranking person within the organisation. However, you need to watch out for the "hidden" stakeholders, because they can be a big threat to your project’s success, especially when they’re above your PO in the organisation’s hierarchy.

Try to keep your Product Owner as close as possible, it may help you discover the dependencies, affected areas and hidden stakeholders. Ask multiple questions and try to find out if there are any other parties involved in the project. In both cases, you should always prepare a Stakeholder Analysis and keep it up to date.


Communication in internal and external projects also differs significantly. You’ll often know the person who plays the role of PO in an in-house project before the work even starts. This results in the use of informal language. Moreover, industry knowledge shouldn’t be an obstacle. You’ll often meet face to face and potentially know each other from earlier informal integration meetings. Moreover, there should be no problem with understanding each other, as you’ll usually speak the same language. However, working with a close friend can introduce some risks. Namely, there may be a tendency to favour this person and their ideas. At the same time, there’s a definite advantage in form of the proximity to the decision-makers (e.g. the opportunity to talk to the Director, Sponsor and end user directly).

In the case of a Product Owner on the Client’s side, you’ll have to meet them at the beginning of the project. Face to face meetings are rare, especially know when the number of business trips is limited and companies prefer communicating online. Currently, creating a communication plan and scheduling regular meetings are becoming even more important than before. It applies to both the short daily meetings, and the longer ones that allow for discussing specific topics in detail. It’s not possible to predict everything, that’s why many meetings may be organised ad hoc.

You have to ensure the availability of the Product Owner at the beginning of the project. Apart from the regular meetings, it’s good to have the opportunity to get in touch with that person when it’s necessary. The plan is always created at the beginning, remember to stick to it. You might need to learn a new domain, so at the start, the industry-specific vocabulary may be unknown to you. There often is a need to develop a “dictionary” of the basic terms to eliminate the inconsistencies. You should always aim to build trust and establish a strong relation, but in short projects, there may simply be no time for that. You barely get to know each other and the project is already ending.

Domain Knowledge

In my experience, when it comes to domain knowledge, the Product Owner oftentimes is an expert in a specific area, but they’re not adept at the role of the PO. There are many common features of Product Owners in internal and external projects. They usually have a technical background, but they’re still gaining knowledge and experience in the product ownership area. They’re experts in their field, which isn’t necessarily software delivery. When we consider a non-product company, the role of a Product Owner is very often just an "addition" to the regular duties. Everyday responsibilities are rarely taken away from a person to help them transition into the PO role.

Here’s a list of best practices that I try to follow when working with both external and internal Product Owners in non-product companies:

  • Business Case is a must—always try to challenge your Product Owner regarding the value of the developed solution,
  • Listening to your Product Owner is essential, you have to let them talk and always have your eyes and ears wide open to identify important issues,
  • Educate your Product Owner. Send them materials, suggest interesting techniques, tools and articles. Try to help them develop their skills in this role,
  • Assist your Product Owner in finding the right approach. Take over some duties and support them in the decision-making process.
  • Be patient if the Product Owner doesn’t understand certain issues. Always try to explain them as well as you can,
  • Build a bridge between the Product Owner and the technical team,
  • And above all, remember that their success is your success.


This article certainly doesn’t exhaust the topic and it’s just my subjective look at the experience of working with various Product Owners. Every Business Analyst had different experiences. It also heavily depends on what industry you come from and how proficient the Product Owner is. But remember, not every company operates in the Product Ownership model and not everyone who holds the role of a Product Owner is practised in this position, aware and capable of leading the team to achieve specific goals. However, an inexperienced Product Owner who’s willing to learn is a real treasure. You can watch them spread their wings and feel that you are part of their success.

Having experience working with both types of Product Owners is really valuable because it broadens your horizons. It can help you understand the perspective of a person who plays the role of a Product Owner. It can show you why they sometimes lack an understanding of the intricacies of software development, as well as agile and continuous communication. Remember that as a Business Analyst you can help them understand the development environment and break into this world.

HC NHS Survey Blog Ad
Sandra Samor Business Analyst

Sandra is a Business Analyst with more than 3 years of professional experience working with both internal and external product owners. She loves books and Italian food. She spends her free time traveling.

See all Sandra's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.