Areas of responsibility are assigned to people so that when someone asks ‘Can anyone tell me what X is supposed to do?’, there is someone who can give a clear answer.
It enforces accountability. As product people, we control the horizontal and the vertical.
The accountability mindset extends down the ranks. At Apple there is never any confusion as to who is responsible for what. Internal Applespeak even has a name for it, the “DRI,” or directly responsible individual. Often the DRI’s name will appear on an agenda for a meeting, so everybody knows who is responsible. “Any effective meeting at Apple will have an action list,” says a former employee. “Next to each action item will be the DRI.” A common phrase heard around Apple when someone is trying to learn the right contact on a project: “Who’s the DRI on that?”1
By designating accountability across the product organisation, we ensure the things that need to happen do happen – and only what needs to be done. If we have a gap, we hire for it.
As people develop deep knowledge around an important area, they also become the best person to triage those problems. When someone else needs to take over, we encourage transparent distribution of knowledge.
Product people should be empowered to delegate and decrease operational work and change aspects of the process or environment.
Typically, each AoR comes with reactive responsibilities and proactive improvements.
An incomplete list, to give an idea of areas of responsibility.
- Branding & positioning
- Costs & benefits model
- Customer development and partnerships
- Customer success
- Account management
- Developer operations
- Accessibility and web performance
- Payments landscape and competition
- Payments regulation
- Contracts and cost-efficiencies
- Quality of integrations with suppliers
- Direct Debit
- Strong Customer Authentication
- Open Banking
- Enterprise resource planning
How to share areas
- Make a spreadsheet with areas of responsibility as rows in the first column. Add responsible owners as columns to the side.
- Get each person to mark how much they know about an area, e.g. 0–5: 0 for Nothing; 1 for Little; 5 for Lots, etc.
- Try to share the responsibility equally, noting where a transfer of knowledge can take place. For example, where a person who marked 0–2 can be taught by a person who marked 3–5.
- Finally, have a conversation about whether there are too many areas to be owned by the current number of owners, or whether some areas aren’t pertinent to the current strategy.
Got comments? Contact me, let’s talk.
The two roles overlap, which can lead to head-butting and duplicated effort. But how might service designers and product managers best collaborate?
Some roles share similar skills. Let’s stop pigeonholing people.
Accessibility, digital exclusion and barriers, plus some thoughts on distributing areas of responsibility amongst a team.