‍

Want to get in touch?  Email sam@opentent.com

In Part One of our Product Owner series we explored what a Product Owner actually is and what they do. In this article, we’ll present a powerful framework that you can use to think like a Product Owner.

The Product Owner functions as the system manager and the champion of ROI. The Salesforce Product Owner has the practical responsibility of understanding the system and ensuring that all system elements are managed properly while meeting actual business needs. This requires a holistic view that considers larger business processes and objectives as well as Salesforce system architecture. This includes overseeing things like workflows, change management, strategic priorities and logistical considerations.

You may be wondering whether there is a difference between a Product Owner and other roles, like Salesforce admins.  You may even question whether your organization need a dedicated Product Owner at all.   Remember that regardless of job title, anyone can think like a Product Owner. Oftentimes scale will determine whether a specialized role is required. Within smaller or simpler organizations, an admin may be the de facto Product Owner.

Larger organizations with multiple business units may require a specialized Product Owner role. In order to know when a dedicated Product Owner may be necessary, it’s important to consider the Product Owner mindset, the Product Owner’s perspective and access to organizational priorities, as well as organizational budget constraints. Whether your organization has recognized a dedicated Product Owner or you just see it as a gap to fill, the following framework can help you think like a Product Owner.

Fundamentally, Product Owners must be mindful of impacts on the larger system, including downstream training and change management projects. The framework for thinking like a Product Owner can be expressed as a series of questions you will frequently need to ask yourself and the teams that are requesting changes to Salesforce. These key questions are:

1. Why do you need this? 
2. What is your issue?
3. What are you asking for?
4. When do you need this?  I.e. what contexts or circumstances create the need?
5. Is this a nice-to-have, or is something broken?
6. What is the “return on value” - is this a temporary band-aid, or built for long-term growth?
7. What are the downstream effects of the change we are contemplating making now? What is the full impact of this (potentially minor) request?
8. What’s the use case? Who needs this new functionality? What’s the business purpose of this request?
9. When should we release this? Does it require a full development cycle with testing or can we make a small change right in the sandbox without a full acceptance test? Consider the context of monthly releases and a standard release cycle.
10. What is the desired timeline for a specific request?
11. What resources do we need to achieve this - people, skills, tools, information? If we don’t have these resources in house, and we decide we need them, how should we go about acquiring them?
12. What is the larger context and reasoning when I have to decline a specific request? If I have to say ‘no’, how can I frame this response in a way that makes the decision clear within a system-wide context?

Product ownership thinking is always useful regardless of your position. A formal Product Owner role might be necessary if your organization is concerned with long term system development and evolution, the question of future growth possibilities, and the impact of change. But whether or not you’re the Product Owner, you can add value by following these guidelines for effective prioritization, communication and delivery.

Want to learn more?  Check out these amazing resources:

Salesforce Admins Podcast featuring Sam Dorman

Sam Dorman and The Build Tank

Salesforce Trailheads on Scrum and Kanban