You’ve Been Made the Product Owner.

Now What?

You’ve been told you’re the Product Owner for Salesforce, your marketing platform, fundraising platform or another important business system.

So, what exactly have you just become responsible for?

Product Owner is one of those titles that sounds reasonably self-explanatory until you actually have to do the job. You might not administer the platform. You may not be particularly technical. There may already be an internal IT team, an implementation partner or a Managed Services partner responsible for much of the work. You probably don’t manage everyone who uses the product either.

Yet somehow, you’re now its owner.

At its simplest, a Product Owner is accountable for the direction, priorities and ongoing evolution of a product. Your job is to understand what the product is there to achieve, who it serves, where it needs to improve and what matters most next.

That doesn’t mean you need to know how to build everything. In fact, one of the most important distinctions in Product Ownership is between what and why and how. You should be able to explain what the business needs, why it matters, who it affects, how important it is and what a good outcome would look like. Your technical teams and delivery partners can then help determine how best to achieve it.

In practical terms, that means taking responsibility for a number of things:

• Own the product direction and priorities. Decide what matters most, where the product needs to go and what should happen next.
  
• Maintain and prioritise the product backlog. Balance strategy, business needs, user feedback, support insights, defects and opportunities rather than treating the backlog as a queue of requests.
  
• Triage support demand. Users should be able to report the pain, problem or opportunity they experience without diagnosing the underlying technology or prescribing the solution. You help determine whether the need is support, training, process change, a defect or a genuine product improvement.
  
• Protect the product from drift. User feedback and support demand should inform the roadmap, but the product shouldn’t be shaped by the loudest user, the most recent request or simply the greatest number of requests.
  
• Define what and why, not necessarily how. Articulate the problem, desired outcome, importance and what good looks like, then work with technical and delivery specialists to determine how best to achieve it.
  
• Understand the product ecosystem. Know the important upstream and downstream influences, integrations and hand-offs affecting your product. You don’t need to be the expert in all of them, but you need to know when your decisions have consequences beyond your product.
  
• Collaborate across product boundaries. When an issue or opportunity involves another platform, work with its Product Owner rather than expecting users to understand or navigate the underlying architecture.
  
• Own value, not just change. Consider adoption, training, usability and business outcomes, not simply whether functionality has been delivered.

Product Ownership is an important responsibility, but it doesn’t need to become your whole job. In many organisations, it is something you bring into the role you already have: a clearer responsibility for listening, setting direction, making priorities visible and helping shape how the product evolves. You don’t need to become the technical expert or spend every day managing a backlog. What you gain is the opportunity to influence how an important business product develops, make sure investment is focused where it can create the most value, and help turn the things you and your colleagues experience every day into meaningful improvement.

And you aren’t doing that alone. You bring your understanding of the business, its people and its priorities; your implementation or Managed Services partner brings their understanding of the technology and what it can do. Product Ownership is where those two perspectives come together.

You own the product, not the technology

For a business-facing platform such as Salesforce CRM, Product Ownership will often sit in the Business. That’s because most of the important decisions about its ongoing evolution are ultimately business decisions. How should we manage this relationship? Where is this process creating unnecessary effort? What information do our people need? What should we improve next? Which opportunity is more important?

That doesn’t mean every platform should be Business-owned. Enterprise-enabling products such as an integration platform or enterprise data platform may quite reasonably have IT or Data Product Owners because their primary responsibilities span multiple business products and include architecture, data, security, reliability and governance.

The important principle is that Product Ownership should sit close to where the product’s primary value can be understood and governed.

It can also change over time. During the very early stages of a major transformation, IT-led Product Ownership can make a lot of sense. When you’re replacing Dynamics with Salesforce, for example, the immediate risks may be migration, architecture, security, integration, data and establishing strong technical foundations. Once that platform moves into business requirement, however, the emphasis changes. The question becomes less about successfully establishing Salesforce and more about continually making Salesforce work better for the business.

The ownership model should be able to mature with the product.

Your backlog is not a list of requests

Once you’re the Product Owner, people are going to tell you what they want.

Some will have problems. Others will have ideas. Someone will want another field. Someone else will want a report. A team will have developed a workaround they want automated. A senior stakeholder will have seen something another organisation does and want the same thing. Support tickets will arrive. Your implementation or Managed Services partner will identify technical debt and opportunities. Vendors will release new capabilities.

All of these are signals. They are not automatically priorities.

One of the Product Owner’s most important responsibilities is turning those signals into a coherent product direction and prioritised backlog. That requires understanding the problem behind the request rather than simply accepting the requested solution.

But you’re not expected to do that alone. You know your business. Your implementation or Managed Services partner knows the technology. This is where the relationship between the two becomes really valuable.

As Product Owner, you should be able to have open and honest conversations about what you want for the business: what’s getting in the way, what you’re trying to improve, where people are struggling, what opportunities you can see and what outcomes matter most. You don’t need to translate all of that into a technical solution before bringing it to your partner. In fact, it’s often better if you don’t.

A good implementation or Managed Services partner can take that business context and bring their understanding of the platform, architecture and available capabilities to the conversation. Together, you can explore what is possible, challenge assumptions and find a better way to achieve the outcome. The Product

• Owner brings clarity about the business problem, the desired outcome and its priority;
• the partner brings clarity about how the systems can help achieve it.

This is where some of the best product decisions happen. Rather than the Business prescribing a solution and the partner simply building it, both sides bring their expertise to the problem. The result can be simpler, more sustainable and sometimes quite different from what either side would have proposed independently.

• Someone asking for another field may actually have a reporting problem.
• Someone requesting automation may have a broken process.
• A recurring support ticket may indicate a training problem rather than a technology problem.
• Something described as a defect may actually be the product behaving exactly as designed, but in a way users don’t understand.

The Product Owner needs to understand those differences, but they have a partner to help them do it.

This is why support should inform the product roadmap; it should not define it. The number of people asking for something matters, but Product Ownership isn’t product development by popular vote. Equally, the loudest person, most senior person or person who most recently raised an issue shouldn’t automatically determine what happens next.

Your job is to listen broadly, work with the people who understand the technology and decide deliberately.

Users should tell you what hurts

There is another important distinction when triaging demand: users shouldn’t be expected to diagnose the technology.

Modern platforms rarely operate independently. Salesforce might be connected to a fundraising platform, an integration platform, Data Cloud, a marketing platform, finance systems and a collection of other services. The person using Salesforce doesn’t need to understand any of that.

If they can’t see a donation they expect to see, that’s what they should tell you. They shouldn’t have to decide whether Salesforce is broken, Raisely hasn’t sent something, MuleSoft has failed or Data Cloud hasn’t resolved an identity correctly.

Users should report the pain, problem or opportunity in the product in front of them.

The Product Owner and supporting team can then triage that signal and determine what it means. It might require support, training, process change, defect resolution or a genuine product enhancement. Investigation might also determine that the underlying cause sits in another product.

That’s where another part of Product Ownership becomes important.

You own a product within an ecosystem

Having a Product Owner for Salesforce doesn’t mean that person owns every technology connected to Salesforce.

As we explored in our article, What Role Do Your Systems Play?, systems play different roles within an organisation. Some are systems of engagement, others provide identity and authority, integration, automation, knowledge or insight. Increasingly, the same platform may even play more than one of those roles. Understanding those roles helps us think about where Product Ownership should sit and, just as importantly, where the boundaries between products exist.

An organisation might have Salesforce CRM owned by Partnerships, Marketing Cloud and Raisely owned by Marketing, while Data Cloud and MuleSoft are owned by IT. Each has a different purpose, different users and different priorities, so separate Product Ownership can make good sense.

But those Product Owners cannot operate independently. The systems may have different roles and owners, but they are part of the same ecosystem. A change to Salesforce might affect an integration into MuleSoft, the data represented in Data Cloud or the audiences available to Marketing. A change in Raisely might alter what arrives in CRM. A new marketing requirement might depend upon data that originates somewhere else entirely.

A good Product Owner therefore understands the important upstream and downstream influences on their product. They don’t need to become an expert in every connected platform, but they need enough awareness of the ecosystem to recognise when a decision crosses a product boundary and when another Product Owner needs to be involved.

Ownership gives you authority within your product. It doesn’t give you authority over connected products.

The model works when there is clear ownership locally, cooperation at the boundaries and shared responsibility for the end-to-end outcome.

The Product Owner as the signal between Business and Delivery

All of this becomes even more important when an organisation is working with an implementation partner or Managed Services partner. In fact, I think Product Owner may be the most critical client-side role in making those engagements successful.

A delivery partner can bring architects, consultants, developers, administrators, analysts, testers and specialists. They can understand the technology, recommend approaches and deliver change. What they cannot independently determine is what matters most to your organisation.

Without effective Product Ownership, the partner is exposed directly to the noise of the business. Different stakeholders raise different priorities. Users submit enhancement requests. Someone escalates a support ticket. A meeting creates three new ideas. Another team wants something urgently. An executive asks whether a new feature can be implemented. Meanwhile there is technical debt to address, an existing backlog and strategic work already underway.

If all of those signals travel directly into delivery, the partner can become very busy without the product necessarily becoming much better.

Filter and focus

This is where the Product Owner creates enormous value. Their job isn’t to block the Business from the delivery team. It is to filter and focus what the Business is telling us into signals that delivery can respond to effectively.

That means listening to the noise and finding the patterns within it. It means separating symptoms from causes and problems from proposed solutions. It means identifying where several apparently different requests are actually manifestations of the same underlying issue. It means deciding when something is important enough to interrupt current priorities and when it belongs in the backlog.

Most importantly, it means providing delivery with clarity.

Instead of five users independently asking a Managed Services team for five slightly different Salesforce changes, the Product Owner might be able to say:

“We’re seeing a consistent problem with how our Partnerships team manages this part of the relationship lifecycle. Here are the users affected, here is what they’re trying to achieve, here is the business impact and this is now one of our priorities.”

That’s a very different signal. It gives the delivery team something they can investigate, design around and solve properly rather than simply implementing a collection of requests.

Protecting the product from drift

Most individual requests are reasonable. That’s what makes this difficult. Adding a field might genuinely help somebody. Changing a workflow might make one team’s job easier. Creating another automation might solve an immediate problem. None of these decisions necessarily looks damaging in isolation.

Over several years, however, hundreds of individually reasonable decisions can create a product nobody deliberately designed. Processes become inconsistent, fields proliferate, automations overlap and different teams solve similar problems differently. The underlying architecture becomes harder to understand and eventually the organisation begins describing the platform as complicated or difficult to use.

This isn’t necessarily the result of bad implementation. It can simply be the accumulated effect of change without strong Product Ownership.

The Product Owner protects against that drift by continually bringing decisions back to the product’s purpose, strategy and priorities. They don’t prevent change; they make change deliberate. Your implementation or Managed Services partner can challenge, advise and help you shape those decisions, but they shouldn’t become the de facto Product Owner. Ultimately, the decisions about what matters to the business and where the product should go need to remain with the organisation.

So, you’ve been made the Product Owner

Congratulations. You’ve been given the opportunity to shape a product that matters to your organisation and the people who use it. You have a voice in where it goes next, what gets better and where future investment and effort are focused.

Users will tell you what they’re experiencing. Stakeholders will tell you what they need. Support will show you where there is friction. Strategy will tell you where the organisation is going, and your technology partners will help you understand what is possible.

Your job is to bring those signals together and decide what they mean for the product.

That’s an important role — and a pretty exciting one to have.