RACI: Who does what when building a product
Building a product is a team sport. So, people start asking “who does what tasks” to define, build, and deliver the product. That breaks down into:
- “who are these people?”
- “what are these tasks?”
A clear path to answering these questions is with a responsibility and accountability matrix or RACI (more on that in a moment).
What tasks: To define a product, the team’s tasks are items like:
- What’s the experience?
- What’s the market?
- How do we make money?
- And so much more
Who’s involved: The teams include these disciplines:
- Product Management: Technical, Go-To-Market, Strategy
- Customer Support
- Design
- Development
- Finance, Pricing, Legal
- Marketing
- Professional Services
- Sales
- Maybe even more depending on the product
About the RACI
Typically, you think of a RACI as a shared responsibility model between a client and a service provider. But you can apply the RACI model for many other team-based collaborations. This article will show how to use a RACI to clearly communicate roles and responsibilities.
Tip! Don’t be surprised that team members might ask for team definitions and an org chart when you introduce a RACI for product. Each organization draws the boundaries across roles differently. Be ready to explain that.
Applying a RACI to the product lifecycle
What I’m showing you in the below image is the classic RACI model of responsible, accountable, consulted, and informed — who is on point through the product life cycle. This blog gives you a taste who’s doing what and then your team can adapt with discussions like, “hey, I want more participation” or “why am I signed up for this?”
So if we dig into stages in the product lifecycle, you can see the Exploration Playback, where the Strategy team is saying that the team has this cool idea. And so, the Strategy team’s bringing a playback of what that business idea is. If we then look at the Market Playback, the primary owner accountable for the market point-of-view (POV) is the Strategy team, and the Technical Product Managers are responsible. Similarly, reading on down in the image above, Design is responsible for Playback 0, and Technical Product Management is accountable at that stage.
Colleague’s insight about the Exploration Playback: Any one of us can come up with the business idea, something worth exploring. But the key is to bring it to the Strategy team, under their governance, so the idea has a champion. Any idea, we’ll take them. All ideas come from all sorts of great places.
I’m going to use the Market Playback as an example, just so you can get a feel of how to read the details in the above RACI table. This RACI indicates that overall responsibility for the market playback is the Technical Product Manager. And then you’ll see that the many of the market items come from the Strategy team, who’s accountable too. Also, you can see in the RACI that the Technical Product Manager is deeply collaborating with the Strategy team to define what the market is. By the way, these items and checkpoints are not an exhaustive list. This image is just a broad swathe to give you a feel of how this RACI works.
As you read down in the above Market Playback details image, you can see the Concept Car is wholly owned by Design with lots of help from the rest of the disciplines. The same thing is true where the Technical Product Manager owns the Business Model.
You know, there’s a few ways to look at this RACI. For some of these consulted’s and informed’s, Sales is highly consulted on several aspects of how we define the prospective market. Also, you can see Development is more or less informed at this point.
Let me show you a Commitment Playback, where Product Management is saying “let’s spend money and development resources and go after this idea”:
There you start seeing a bit different assignment of who’s informed and who’s starting to participate more. You see, for example, that Go To Market (GTM) gets a lot more active at the Commitment Pitch. Even Finance starts having less informed’s and more responsible’s and consulted’s.
Tip: Be ready to iterate on and evolve the RACI through feedback and reflection. There’s always opportunity to refine over time.
Recap: Why Use a RACI
Understanding where responsibilities and ownership reside provides the courtesy of knowing who needs to be informed and consulted. Because by doing that, the communication flow strengthens across the teams. I promise without a responsibility and accountability matrix, people will ask “who does what?”
To see how the User Experience discipline defines and applies a RACI to their work, check out this excellent RACI overview and then how it applies to UX work: https://www.nngroup.com/articles/ux-roles-responsibilities/
