RASCI: definition and a worked matrix example for a product team

RASCI: the definition

RASCI is a matrix that assigns, for each activity or decision, a role to every person involved. The acronym stands for the five roles:

• R, Responsible: the person or people who do the work.
• A, Accountable: the person who answers for the outcome and makes the call. Only one per activity.
• S, Support: the people who provide help or resources to whoever is responsible.
• C, Consulted: the people whose opinion is sought before the decision.
• I, Informed: the people kept up to date after the decision.

The better-known RACI matrix is the same thing without the S. The Support role is useful in small teams, where one person helps on many topics without owning any of them.

The value of the method comes down to one word: clarity. Everyone knows what they have to do and, just as importantly, what they are not responsible for.

RACI or RASCI?

Choose RACI if side contributions are rare and the matrix needs to stay very easy to read. Choose RASCI as soon as one person or team helps on many topics without owning any of them: a shared designer, a cross-functional data team, a lawyer brought in occasionally. Without the S, these people end up marked as R by default, and you can no longer tell who is actually doing the work.

The problem it solves

A familiar scene: a salesperson chats with a developer about a feature a customer keeps asking for. The conversation is healthy; nobody wants silos. But without clear roles, it turns into an official request that the developer prioritizes at the expense of the roadmap. The product manager then has to explain why it is not the priority. The salesperson feels ignored, and the developer feels like a mere order-taker.

The same scene plays out when an executive pushes a request straight onto the tech team. Each time, the roadmap loses credibility.

I came across RASCI at TIAO, when a fuzzy definition of my role as product manager was creating friction. We used it to clarify the roles of the CEO, the CTO, the product manager and the developers. The friction does not disappear, but it gets resolved quickly, because everyone knows who makes the call.

Example matrix for a product team

How to read it

The roadmap: the product manager builds it and answers for it. They must consult the developers, and can ask them for support in describing the technical side. It is public, so everyone is informed.

Development: the developers do the work; the product manager answers for the outcome. The product manager frames the request and prioritizes it. They can be called on for support, for instance for mock-ups, and consulted when there is doubt about the implementation.

Technical matters: stack choices and maintenance belong to the CTO. The product manager is consulted if the user experience could be affected. I will never tell developers how to run their stack; they will rarely try to prioritize the roadmap in my place.

Building the matrix in one workshop

A matrix can be built in an hour to an hour and a half, with the people who appear in it. The sequence I use:

1. List the activities that cause friction today, not every activity in the company. Ten to fifteen rows are enough.
2. Assign the As first, row by row. That is where disagreements concentrate, and that is where the time should go.
3. Then the Rs, checking that each R actually has the capacity to do the work.
4. Then the Cs and Ss, asking each time whether this person’s opinion can change the decision.
5. The Is last, often by team rather than by person.
6. Read every contentious row aloud against a recent case: “last week, who should have made the call?”

The last step is the most useful. A matrix that does not survive a real case will not survive the next one.

Rules that make it useful

1. One A per row. Two people answering for the outcome means nobody does.
2. Concrete activities, not vague areas such as “the product”.
3. Few Cs. Consulting everyone slows everything down. Keep this role for people whose opinion changes the decision.
4. Built together, not imposed: the discussion is as useful as the table.
5. Reviewed when the organization changes: a new hire, a new product, a funding round.

In a young company, everyone wears several hats, and that is normal. That is exactly why the matrix helps: it makes the hats visible and stops them from overlapping.

Small team or large organization

In a team of fewer than fifteen people, one matrix is enough, on one page, reviewed twice a year. Names go straight into it. In a larger organization, think in roles rather than names (“product lead”, “data team”), and keep one matrix per scope: a product, a process, a system. A single matrix for the whole company becomes unreadable and nobody looks at it.

Common mistakes, and how to spot them

• Cascading As. The same director is A on every row. Warning sign: they become the bottleneck for every decision, and projects wait on their calendar.
• Rows with no A. Warning sign: the question “who decides?” gets a plural answer, or the name of a body (“the committee”).
• Cs everywhere. Warning sign: every decision needs a meeting, and lead times grow without quality improving.
• Rs without capacity. Warning sign: the same person is R on a dozen rows and delivers nothing on time.
• A frozen matrix. Warning sign: it names someone who left six months ago.

A matrix for an AI system in production

An AI system in production raises the question of roles in its sharpest form. Who answers for a wrong answer given to a customer? Who decides to change the model? Who keeps the inventory needed for AI Act compliance? In projects that stall, the answer is often “nobody in particular”.

A fictional example, built on the case of an AI assistant that answers customer requests for a support department, with handover to a human agent when it does not know.

How to read it

The model’s outputs have a business A. The head of customer service answers for answer quality, not the data team. They bear the consequences of a wrong answer, so they set the acceptable threshold and can ask for a shutdown.

The data has a named S. The subject-matter experts who write the knowledge base content provide Support: without them, the data team cannot fix a wrong answer, only hide it.

Compliance is consulted, not bypassed. Legal and the DPO are C on the rows that touch personal data and classification. Their opinion can change the decision, which is the very definition of C.

Frontline teams are informed of changes. A prompt change that alters the tone or scope of answers must be known to agents before customers discover it.

Notice that no A is ever assigned to a tool or an automated agent. A system can execute; it cannot answer for the outcome. This is one of the most concrete expressions of the thesis I stand by: a successful AI transformation is, 70% of the way, an organizational transformation. I come back to this in from AI POC to production, and the metrics that let the A judge quality are set out in measuring an AI support assistant.

Keeping the matrix alive

An AI matrix goes stale faster than a product matrix, because the system changes often. Five rules:

1. An owner for the matrix, usually the product lead, in charge of keeping it up to date.
2. Written review triggers: a change of model or vendor, a new use case, a new data source, a reorganization.
3. A standing question in every incident review: who was A, and were they alerted in time? If the answer hesitates, the matrix needs revisiting.
4. A visible last-reviewed date at the top of the document.
5. A link to the AI Act register: every inventoried system points to its matrix, and vice versa.

In hindsight

When I wrote this article in 2022, I saw RASCI as a startup tool for settling friction between a handful of people. Today I see it as one of the most useful tools in an AI project, and by far the cheapest.

What I would keep

One A per row, and a matrix built together. On a system that answers customers directly, like the one we deployed for the contact center at Home Partners of America, the question “who answers for the answer given?” is never secondary. It gets settled before going live, not after the first incident.

What I would nuance

I wrote that C should be kept to a few people. That is still true, with one exception: on an AI system, compliance and data protection must be consulted early, even if it slows things down. Discovering them late costs far more than one extra meeting.

I would also nuance the idea that one person can easily hold both R and A. On a product topic, yes. On the quality of an AI system, I prefer to separate them: the team that builds it is not best placed to judge alone whether the result is acceptable for customers.

What AI assistants have changed

Assistants speed up the work of the Rs: drafting, summarizing, prototyping. They take no role in the matrix. A summary produced by an assistant always has a human R who reviewed it, and an A who answers for it. That is the rule I pass on in training: check the outputs, and know who signs them off. To get started with a team, the guide on a team’s first AI use cases follows the same logic.

The rest has not changed. Friction rarely comes from the technology; it comes from blurred roles. That is the heart of the 70% that is organizational.

Frequently asked questions

What is the difference between Responsible and Accountable?

The Responsible person does the work; the Accountable person answers for the outcome and makes the call when people disagree. One person can hold both roles, but there is never more than one Accountable per activity.

Can an activity have several Responsible people?

Yes, several people can do the work. It is the Accountable role that must stay unique, so that there is always someone who decides.

Where should the RASCI matrix live?

Wherever the team already works: in the project management tool or the shared documentation, next to the roadmap. A matrix filed away in a forgotten folder settles no conflicts.

Who should be Accountable for an AI system in production?

The business owner who bears the consequences of the system’s answers, for example the head of customer service for a support assistant. The technical team is Responsible for building it, not for the outcome for customers.

How often should the matrix be reviewed?

Whenever the organization, the model or the use case changes, and at least twice a year. An incident review where nobody knows who was Accountable is the sign that it has gone stale.