Internal or External Product Owner: Things You Should Know

Development is a beast — things invariably start off hot, and the temperature only rises as feature requests pile up, deadlines tighten, and resources dwindle.

Then add a product owner (particularly an external product owner) to the mix, and it may seem like – well, pick your metaphor: A bridge too far. The straw that broke the camel’s back. There are any number of clichés that describe the dilemma, if not the precise degree of frustration.

Why do you need product owners?

But consider the bigger picture. Product owners are necessary. Developers create, but a good product owner will ensure that all that creativity meets the requisite need.

Product owners speak for the customer, emphasizing the necessity of tailoring the product to user needs and aspirations.

They formulate essential strategies and track the product through critical milestones while simultaneously accommodating customer priorities. And ultimately, the buck stops with them: they’re usually invested with the authority to oversee all major product issues and order significant product changes.

What are the typical responsibilities of a product owner?

• Stay focused on the product
• Establishing the guiding product vision
• Prioritizing requirements
• Managing product development at all stages
• Addressing product backlogs
• Serving as the lead liaison
• Anticipating and highlighting client concerns and needs
• Evaluating progress throughout the project
• Contributing to the daily scrums
• Overseeing and terminating sprints

Choosing between an internal or external product owner

Product owners typically can be categorized into: internal, external, representatives of the business domain, and erstwhile business analysts.

Development teams most often work with an internal or external product owner (sometimes both). The main difference: internal product owners are employees. External product owners are outsourced by (or are new to) the company. Each brings a suite of strengths and deficits to the position. Some positive qualities associated with internal product owners include:

• Familiarity with company culture
• Understanding of the company’s priorities and needs
• An established network of allies and mentors

On the other hand, internal product owners may be somewhat set in their ways and slow to react to shifting circumstances. They may instinctively default to “favored players” rather than supporting the team’s most competent members.

Most critically: they’re likely unfamiliar with the project’s business domain.

How can an external product owner help?

In many if not most development projects, external product owners are designated. It’s often an issue of logistics: talent is at a premium these days, and the job must go to whoever is both qualified and available. The good news is that external product owners bring an overriding asset to any product development effort – a fresh point of view. They’re also:

• More likely committed to “getting it done” rather than relying on “…this is how it’s always been done…” protocols
• More open to change generally, with an emphasis on development team flexibility and responsiveness to market and customer feedback
• Less likely to promote favorites

On the other hand:

• They’re more likely to run afoul of company politics and policies
• They’re unlikely to know the power players who can expedite workflow and resolve problems
• They usually lack a strong network of allies

Mutual understanding can reap long-term benefits

Good communication is essential to working successfully with an external product owner – but that can also be an elusive goal. External product owners ask a lot of questions, and that can raise tensions within a development team.

But there are legitimate reasons for such inquisitiveness.

First, as noted, external product owners typically don’t know company culture and processes; they have to ask to find out things. Second, they need to do their basic job: ensure the product under development meets customer requirements. So, they must ask questions about product market fit, market share, money flow, and everything else remotely germane to a project.

Yes, that can be daunting for development team members. The constant questions may seem like a distraction from the important work of creating the product. But again, the product owner is essential to defining and refining the optimal product – and that’s in everyone’s interest.

Take your product owner’s questions and efforts seriously. Don’t resist them. Don’t hinder them. Help them – and your team in the process. Establish and employ clear communication channels and effective protocols between the external product owner and the development team.

There are a couple of good ways to augment productive communication:

• Provide BI tool data – e.g., percentages without precise numbers
• Support your external product owner with an internal product owner. An internal product owner will bring qualities to the table that your external one lacks. They can also address many of the external product owner’s questions upfront, reducing much of the pressure on the development team.

Ground rules for working with an external product owner

That said, it’s essential to lay down a few ground rules with any external product owner:

Availability: The external product owner must be available for regular check-ins, sprint planning, and demos to ensure the development team is aligned with the project’s goals and milestones.

Contractual Obligations: Contract responsibilities that include deliverables, timelines, and payment terms must be clearly defined, accepted, and honored by all parties; confidentiality must likewise be defined and observed.

Integration: The external product owner must integrate with the processes and tools of both the development team and the business team.

And finally: trust. Of all the elements necessary for a productive working relationship between a development team and an external product owner, trust is paramount.

Without mutual trust, concluding a successful development project is exceedingly difficult – and sometimes impossible. But don’t despair if things don’t quite jibe in the beginning. Acknowledge the problem candidly, and actively work to improve communication. Try alternative protocols or even a two-or-three-month trial period. Sometimes trust – like the product itself – must be built over time.