Roles and Responsibilities
Using the DACI Framework with your PoR Can Improve Decision-Making
Once your PoR is up and running, decision-making will be front and center—especially around how to prioritize tickets and allocate resources. Because the product management lifecycle includes contributors from many teams, it’s essential to use a clear framework to assign decision-making roles.
I recommend the DACI framework. While its origins trace back to Intuit, a helpful reference is Atlassian’s DACI guide. DACI stands for Driver, Approver, Contributors, and Informed. It’s a powerful tool to clarify who’s responsible for what.
For every project or ticket, assign these roles:
Driver: Defines the decision to be made and drives the process to reach that decision by a set deadline. (Only one Driver.)
Approver: The single decision-maker with authority to make the final call.
Contributors: Team members who provide input to shape the decision.
Informed: Stakeholders who need to be updated on the outcome.
In R&D teams, there will be many situations where an engineering lead is both the Driver and Approver—especially for urgent decisions like outages or bug prioritization. For roadmap work and feature refinement, the product manager often plays the Driver role, with engineering and UX leads as Contributors. The Approver may be a more senior product leader, such as a director or VP.
When goals are clear and relatively stable, most prioritization decisions can be made by the product and engineering leaders within the teams. A typical example: the product manager drives, engineering and UX contribute, and a senior product leader approves.
But when goals shift—or the trade-offs are too large—decisions need to escalate.
Here are common examples where Approvers and Drivers need to be at a higher level, potentially including the CPTO, CPO, CTO, CEO, or even the board:
Reprioritizing in response to a competitive threat
Responding to reductions in team size or budgets
Integrating teams and roadmaps following an acquisition
Kicking off a major modernization effort
In these cases, the PoR itself becomes the operating system that Drivers use to bring decisions to the right people. Once those decisions are made, they cascade down with renewed clarity—allowing the PoR to resume functioning effectively at the team level. This is what enables your process to scale: low-level autonomy combined with high-level alignment.
Up Next: Many startups don’t think they need a PoR – until they do. In the next post, we’ll explore the question of whether start-ups need a PoR.