RACI Chart, Roles and Goals, Product Development, New Product Development, Product Owner, Product Manager, Subscription Business, Product Management, Product Strategy, Strategic Planning … it can all get very confusing trying to understand who does what as it related to product development

This second of six serialized sections of Getting Your Product out the Door: Product Development Basics dives into the role of the product owner, how it relates to others involved in the product development process and how to work effectively with IT.

Introduction

Sometimes, the challenges to new product development are as much about internal friction and confusion as they are finding and meeting a market need.  Successful product development is a delicate balance of encouraging input and choosing a direction, of creating a collaborative environment while keeping progress on track.  Doing this can be difficult when the people involved communicate and process information in different ways, or are unclear about how they are expected to contribute to the effort. As the product owner, it is your responsibility to help clarify the roles and bridge communications gaps to ensure success. And make no mistake – companies that are good at product management will win over companies who aren’t, every time.

Getting Your Product out the Door: Who Does What in Product Development? is the second article in a six-part series compiled by product owners with decades of experience in creating and launching successful subscription products.  The series is full of specific tips, checklists, examples and tools as well as best practices and foundational knowledge that will help you clarify the roles within your

This series is written with the beginner in mind.  The content is explanatory and foundational, designed to give someone new to product leadership the practical tools necessary to help an engineering team build the product in a timely and efficient manner.  

Getting Your Product out the Door: Product Development Basics

Part 2: Who Does What in Product Development?

Who Is the Product Owner?

While product decisions are sometimes made directly by the CEO, or shared between sales, technical engineers and editorial or operations teams, most high-growth organizations increase effectiveness by establishing a function specifically responsible for it – a product management team. 

Sometimes this function is split between a product marketing manager (who assesses the market need through interaction with customers, sales and other outward-facing stakeholders) and a product owner (who takes the broad market mandate and works with the technical engineers to deliver a product that meets the need). Even when the role is performed by a single person, you may hear “product manager,” “product leader” or other title used to describe the role. For the purposes of this article, the term “product owner” will be used.

The product owner is often responsible for analyzing market conditions and defining features or functions of a product in response to those conditions. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company. To maximize the impact and benefits to an organization, Product management must be an independent function, separate from sales, editorial or IT.

Product Owner versus Product Manager

You will often hear “product owner” and “product manager” used interchangeably, and in many organizations it’s correct to do so.  But, strictly speaking, there is a difference.

The “product owner” is used specifically in Scrum (the framework of Agile product development, discussed further in our third article in the series: Working with IT) to describe the individual accountable for maximizing the value of a product by identifying, describing and prioritizing new features.

The “product manager” role existed prior to Agile/Scrum, and most generally refers to the person who represents the target market of the product during the development process, and is the person who defines overall product development direction as well as ensuring tactical delivery milestones are met.

For our purposes, the two roles are conflated in order to provide a broad overview of the responsibilities that may apply in your organization.

“The specific duties – or even the existence of – the product manager, product owner, product lead and product marketing manager are based on the needs, culture and staffing levels of each organization.  When you’re asked to come in to a company as a ‘product owner,’ get specifics on what that means to that company.” VP Product, legal information publisher

Common Responsibilities of the Product Owner

1. Represents the market within the company.  The product owner gathers information about the market from many sources including your own customer service and sales teams, online behavior or product-use patterns, industry journals, regulatory and legislative events and of course the market itself.
2. Understands the competitive environment. As a result of this research and investigation of other companies who seek to meet the need, you are the one who knows what motivates a customer to subscribe to your product, what alternatives they have and how your product is better (and not as good).
3. Creates the justification to move forward. Working with finance and engineering, the product owner sizes the market opportunity for a product as well the expenses to build it, to provide a justification for senior leadership to move ahead.  Defending the forecast and working to get resources is one of the most critical activities of a product owner.
4. Defines the “what.”  The product owner describes what the product should do through the creation of business requirements, epics, user stories or other method of detailing the “what is to be built.”  The engineering team will be responsible for figuring out the “how,” including the technical platform on which the product will be built, and integrating the product with other software, databases or applications. Defining the “what” also includes prioritizing which features are built first, and when a group of features is worthy of a formal announcement to the market, or is rolled out without fanfare as a “software update.”
5. Brings the teams together. The product owner ensures that team members’ ideas are heard and their activities coordinated to ensure timely product delivery and successful launch.  For example, the product owner will ensure that marketing materials and sales campaigns are ready to go while the product is in its final stages of development, and make sure that sales gets a chance to offer its ideas on what customers want. Even when there is a project manager keeping track of the schedule, it’s still the product owner’s responsibility to help move everything along.

Product management is, in many ways, an inter-disciplinary role, bridging gaps within the company between teams of different expertise, especially between engineering/IT teams and Sales and Marketing. Sometimes it’s even called the “mini-CEO” role, as successful product owners must listen carefully to many constituencies, leverage what they learn to create a clear vision of the future product, and effectively lead a team to deliver it. 

Why is Product Ownership Important?

Your organization may have never had product owners as such.  You may have had Publishers, or Editorial Directors focused on your subscription content, leaving the “technical stuff” to the IT team.  If you’re a newer business, your entire org structure may still be evolving, or you may have been small enough that you didn’t need a product owner – everyone worked on everything together.

However, as a business grows, functional units are formed and the company is just too big for every good mind to be involved in making every business decision.  A product management team both clarifies what the market wants and speeds up the delivery of that solution.  When you create a product management team, you free up sales, marketing and engineering to focus on what they do best while still ensuring that their expertise is tapped to create the best possible product.

Product ownership is important to improve customer focus, build awareness to competitive threats and get products out the door faster (to bring sales in the door faster). Unfortunately, the titles and terminology that surround product management aren’t uniform from company to company, causing both confusion and friction among teams.  Even in established businesses, roles change as teams grow and individuals begin to specialize in one or another part of the product management spectrum of activities.  So, clarifying roles is crucial to effective new product development. 

Clarifying the Roles

How can you clarify roles? The process itself is simple, and can be accomplished in four steps:

1. Identify the actions to be taken in your product development process.
2. List the people/functional roles involved.
3. Match actions to people, detailing the level of responsibility each has for completing the action.
4. Communicate the results clearly and consistently throughout the organization.

Matching individuals to responsibilities in this straightforward way creates the clarity that all team members need to understand and execute on product development, so performing this step is critical to successful product creation going forward.  Thinking through each step is a strategic exercise, completed by the executive leadership of your business.

RACI Chart

R = RESPONSIBLE. This is the person (or people) who actually complete the task. The degree of responsibility this person has is determined by the Approver. 

A = APPROVES or ACCOUNTABLE. The accountable person is ultimately answerable for the activity, deliverable or decision. This includes “yes” or “no” authority and veto power. Sometimes this person is referred to as the Decider. Only one “A” can be assigned to an action – this rule is the one most frequently broken in the RACI method, but the most critical to adhere to.

C = CONSULTED. These are subject matter experts (SMEs) who provide some type of specific insight or opinion in the product development process. Input from the designated position is required.

I = INFORMED. These may be people who will carry out specific activities pertinent to the product rollout, and must be informed after a decision or action is taken. While this is, strictly speaking, a one-way communication, listening for signs of uncertainty, stress or disagreement from those Informed is only logical.

Sample Roles

Again, as long as there’s clarity, “who does what” can be assigned in any way you feel is logical for your organization.  That said, the following example of a RACI chart for a subscription business is a good place to start if you’re looking for some guidance:

While there are no right or wrong functional areas or actions in a product development workflow, there are some guidelines to assigning the roles via a RACI document that help to create a clear, effective process:

• Use “action verbs” to create Actions above, such as: Write, Test, Schedule, Identify, Quantify, Monitor, Collect, Conduct, Code, Train, Publish.

• Assign only one “Approver” to each action/decision. If it seems critical to get multiple approvals on an action, break it into parts (e.g., “Gain Marketing-level approval on business requirements.” AND “Get IT approval on business requirements.”)

• Push decision-making authority as far down into the organization as possible.  You can also push decisions farther down over time.

• Many individuals or functional areas may be indicated as Responsible in the RACI Chart; often many contribute something to a deliverable.  Make sure each person with an “R” next to their name knows exactly what it is they’re responsible for.

• Add an asterisk to the Responsible person who will be coordinating the elements of the deliverable. For example, if Joe in Marketing is working on the brochure for the new product and Laura from Sales is helping out with some customer quotes, put an asterisk by Joe’s name if he’s the one who will actually prompt Laura for her deliverables and deliver the completed brochure.

• Review the RACI Chart with the team at the outset of the project to make sure there are no questions.

Insight: The steps are easy to execute, but sometimes difficult to communicate.  You may discover that team members expect more – or less – decision authority than they actually have, and that there will be surprises, and a need for discussion. Some team members mistake role clarity for an excuse to say “that’s not my job” or assume because they are the Approver that it’s appropriate to make unilateral decisions without getting the input of the group.  Neither are true, but in order for product development to proceed smoothly, the team must be clear on who does what. In other words, the more difficult you anticipate this conversation will be, the more necessary it is. 

Pitfalls to Avoid

While it’s important to focus on the positive behaviors above, it is equally important to identify and remedy the warning signs that the product development effort is headed for disaster.  The following scenarios should be red flags that you resolve as quickly as possible after you realize they’re occurring, or that they’re part of “business as usual” processes within your teams:

• The team isn’t clear why they’re building the product or why someone would want it.
• The entire project is already laid out in great detail before any engineering work begins.
• Sign-off from all teams is required before work even starts.
• Engineers don’t know when requirements have been updated.
• Engineers (or other team members) don’t participate in the product development process or, worse, allow you to request something that could be more easily accomplished if executed a different way – i.e., creating “gotcha” code.
• The product owner writes requirements without the participation of the team.
• The product owner will not prioritize features and functionality, but rather insists that “everything in the requirements is a top priority.”

As the product owner, you “own” most of the decisions about what the product will look like, the features it will have and how and when it will launch.  What’s important is that you remember that you’re speaking for the customer, not yourself, and that your team members have an advisory role because they have something to add.  Make sure you get the best product you can be leveraging teamwork in the following ways:

• Bring developers in to customer interviews.

• Meet regularly with customer service to understand what is frustrating customers today. 

• Attribute features and other good ideas to the person who brought them to the table; share credit liberally!

• Ask the developers their opinions on how best to create an online workflow. What are the best practices for forgotten password resets?  How about customer feedback? 

• When you work together throughout the process, you’ll find that your written requirements, wireframes and other documentation can be less detailed, and that development goes faster and launches smoother because everyone is invested around a common goal.

Why Is Product Development So Challenging?

Clarifying roles in the product development process is a critical step to eliminate roadblocks to success. But it’s only a first step. Because product development is not only a company-wide effort, but also a company-wide dependency, the stakes are high.  The good news is that most product development pitfalls are widely recognized, and can be mitigated with awareness and planning.

Summary: 

Product development requires an understanding and awareness of every function of the business.  You need to know the motivations, responsibilities and communication preferences of creative, quantitative, analytical and emotional individuals and cultures, and must mix them together against a looming deadline played out in a public spotlight.  Product development is not for the faint of heart!

But still – relax.  If you plan ahead, ask for and reward input, and communicate clearly, you can do this.  Keep in mind that the roles of product owner, product marketer and product marketing manager can, in practice, be performed differently from company to company.  There is no absolutely correct methodology, so use what works best in your own environment.  If there’s a system already in place in your company, ask specific questions until you clearly understand what you should expect of others, and to do yourself.

Defining team member roles can seem time-consuming and pointless (“we all know what we’re supposed to do”). Then, you realize too late that teams are working at cross purposes and that nobody has de-bugged the product because the person you thought was doing it says “that’s not my job.”

So, spend enough time on role definition to enable success.  Use these tools to help your team work more quickly, and to better effect. The time you devote to this clarification will give you the focus you need to bring the team together around your solutions.

Up next – a deeper dive into working with IT.  See you then!