The product launch kickoff meeting felt promising. Twenty people from product, marketing, sales, customer success, and legal all agreed on the goal: successful launch of the new enterprise features by Q3. Everyone committed to collaborate. The energy was high. The Slack channel was created.
Three weeks later, the launch was behind schedule and the team was paralyzed. Sales and marketing couldn't agree on the target audience—enterprise or mid-market? Product and PMM were stuck on messaging—technical deep-dive or business value? Legal, security, and product were debating a compliance requirement with no clear path to resolution. Nobody knew who could make the final call, so decisions got escalated to the VP level or simply delayed week after week.
The problem wasn't bad intentions or poor communication. It was unclear ownership. Too many stakeholders had input, consultation rights, and strong opinions. But nobody had final decision-making authority. The launch was design-by-committee, which is another way of saying it was designed by no one.
The fix is simple in concept, hard in execution: Directly Responsible Individual framework. One person owns the outcome and has authority to make final decisions when stakeholders disagree. Here's how to actually implement it for product launches.
What DRI Actually Means (It's Not a Do-Everything Role)
The DRI concept gets misunderstood constantly, so let's be explicit about what it is and isn't.
DRI does mean one specific person is accountable for the outcome. They have authority to make final decisions when stakeholders disagree after input has been gathered. They have an obligation to seek input from relevant teams before making decisions. They have a clear escalation path when decisions exceed their scope or authority.
DRI doesn't mean they do all the work themselves—that's impossible and defeats the purpose. It doesn't mean they make decisions in a vacuum without input. It doesn't mean they override expertise from legal, security, or compliance without proper escalation. It doesn't mean they can ignore legitimate stakeholder concerns.
Think of the DRI as the editor-in-chief of the launch. They don't write every article themselves, but they decide what gets published, how it's positioned, and when it ships. They gather input from writers, fact-checkers, and subject matter experts. But when there's disagreement about direction, the editor-in-chief makes the call.
How to Assign DRIs for Different Launch Tiers
Not every launch needs the same level of DRI structure, but every launch needs clarity about who decides.
For Tier 1 launches introducing new products or major platform shifts, the executive sponsor—typically VP Product or VP Marketing—is the overall DRI. They're accountable to the CEO for the outcome. But they delegate functional decisions to domain-specific DRIs. PMM is DRI for messaging and positioning. Product is DRI for roadmap and feature scope. Demand Gen is DRI for campaign execution and lead generation. Sales Enablement is DRI for sales readiness and training.
For Tier 2 launches covering major features that aren't standalone products, PMM is typically the overall DRI with close partnership from the product manager who built the feature.
For Tier 3 launches introducing incremental enhancements or minor features, the Product Manager is DRI with PMM supporting on positioning and enablement.
The critical rule: declare one person the overall DRI at the launch kickoff. Not "PMM and Product are co-DRIs" which sounds collaborative but creates decision paralysis. One person. Their name is in the launch brief.
The Launch Decision Matrix (Who Actually Decides What)
For each major decision area in a launch, you need clarity on four roles: who has input and should be consulted, who makes the decision, who must approve it if it's high-stakes, and who gets informed after the decision.
Here's the framework that works.
Launch date: Product is the DRI who decides. They must consult PMM, Sales, and Engineering to understand readiness and market timing. The Exec Sponsor must approve because it's a company commitment. Marketing gets informed to plan campaigns.
Target segment: PMM is the DRI. They must consult Product on capability fit, Sales on ICP alignment, and Exec Sponsor on strategic priorities. Marketing gets informed to tailor campaigns.
Core messaging: PMM decides. They must consult Product for technical accuracy and Sales for field validation. Exec Sponsor approves if it's a major positioning shift. Marketing gets informed.
Pricing and packaging: Product decides with heavy input from PMM on market positioning, Sales on competitiveness, and Finance on margin targets. Exec Sponsor and Legal must approve.
Campaign budget: Demand Gen decides. They must consult PMM on launch goals and Exec Sponsor on available budget. CFO approves anything above threshold. Sales gets informed on expected pipeline.
Sales enablement approach: Sales Enablement decides. They must consult PMM for messaging and Sales Leadership for training needs. Product gets informed on what's being taught.
Beta program design: PMM decides. They consult Product on technical readiness and CS on customer selection. No approval needed unless it involves pricing or SLAs.
The key rule: only one person in the "DRI" column per decision. If you have two people, you don't have clarity. Split the decision into smaller sub-decisions with clear individual owners.
How DRIs Actually Make Decisions (The Four-Step Process)
DRIs aren't dictators. They follow a structured process that balances input with decisiveness.
Step 1 is gathering input. The DRI must actively seek input from "must consult" stakeholders. This isn't optional—it's their responsibility to create informed decisions. Don't just email asking for "thoughts" which yields vague responses. Run structured working sessions: "We need to decide the target segment for this launch. Here are three options based on product capabilities, sales feedback, and market research. What are the pros and cons of each from your perspective? What am I missing?"
Step 2 is making the decision. After gathering input, the DRI decides. They don't need consensus—they need informed judgment based on available information and strategic priorities. Document the decision and rationale in writing: "Decision: We're targeting mid-market SaaS companies with 50 to 500 employees for this launch. Rationale: Higher willingness to pay than SMB segment, shorter sales cycles than enterprise, best product-market fit for current feature set. Consulted: Sales (confirmed ICP alignment and deal size expectations), Product (confirmed roadmap supports this segment), Exec Sponsor (aligned with Q3 revenue targets)."
Step 3 is getting approval if required. For high-stakes decisions with company-level implications, the DRI must get formal approval from the exec sponsor or specialized teams. What requires approval: launch date changes that affect external commitments or revenue forecasts, pricing changes that impact business model, marketing claims that could create legal or compliance risk, budget requests that exceed the DRI's delegated authority. What doesn't require approval: messaging and positioning choices, channel mix for marketing campaigns, format and delivery of sales enablement, tactical execution decisions within approved strategy.
Step 4 is informing stakeholders. Once the decision is made and approved if necessary, inform everyone who's affected so they can plan accordingly. Post in the launch Slack channel or send a summary email: "Decision made: Targeting mid-market SaaS companies (50-500 employees) for Q3 launch. Rationale: Best product-market fit and revenue potential. Next steps: Demand Gen building mid-market campaign by June 15, Sales updating ICP targeting, Product prioritizing mid-market feature requests for H2. Questions or concerns, reply by Friday."
What Happens When Stakeholders Disagree (Why DRI Matters Most)
This is where the DRI framework earns its value. When stakeholders have competing perspectives and preferences, decisions don't get stuck in endless debate.
Here's a real-world scenario. Sales wants to target enterprise accounts for the launch because that's where the big deals are. Demand Gen wants to target SMB for faster pipeline generation and shorter sales cycles. Product thinks mid-market is the best fit for current product capabilities and the features they can realistically ship.
Without DRI, this debate goes in circles for weeks. Or it gets escalated to the CEO who doesn't have detailed context and makes a decision based on incomplete information. Or someone gives up and the team defaults to trying to target everyone, which means they effectively target no one.
With DRI—let's say PMM owns this decision—here's what happens:
PMM gathers input from all three teams over two days. Sales provides evidence: enterprise deals average $150K but take six months to close and require features we don't have. Demand Gen shares data: SMB deals average $15K, close in six weeks, but have 40% annual churn. Product explains: mid-market fits current roadmap, average deal $50K, three-month sales cycle, manageable feature requests.
PMM makes the decision based on evidence and strategic priorities: "We're targeting mid-market companies with 50 to 500 employees. Rationale: current product capabilities best serve this segment, deal size and sales cycle balance revenue and velocity, lower churn than SMB and fewer unshippable feature requests than enterprise. Sales and Demand Gen, here's the mid-market ICP profile and campaign plan. If you have blocking concerns—not preferences, but blocking concerns with evidence—flag them by Friday."
If Sales or Demand Gen have blocking concerns backed by evidence, they can escalate to the exec sponsor. The exec sponsor reviews the decision, the evidence, and the concerns. They make a final ruling that same day or next day.
If there's no escalation with evidence, the decision stands and everyone executes.
Timeline: three to five days from debate to decision to execution. Not three weeks of circular meetings. That's the value of DRI.
When and How to Escalate (The Safety Valve)
DRIs make most decisions, but some decisions exceed their scope or authority. That's when escalation happens.
Escalate when the decision has company-level risk around legal, compliance, or brand reputation. Escalate when a stakeholder has a blocking concern backed by clear evidence, not just preference. Escalate when the decision conflicts with existing company priorities or strategic direction.
Don't escalate when a stakeholder simply disagrees with the decision. Don't escalate when the decision is clearly within the DRI's scope and authority. Don't escalate preference disagreements without evidence of material negative impact.
How to escalate properly: the DRI summarizes the decision, the stakeholder's concern, and asks the exec sponsor for a ruling with a deadline. "I decided to target mid-market for launch based on product fit and revenue potential. Sales is concerned we're missing enterprise revenue opportunity this quarter. Here's my rationale: [X]. Here's Sales' concern with supporting data: [Y]. I need your call by EOD Wednesday to stay on track for our launch timeline."
The exec sponsor reviews the information and decides within 24 hours. Their decision is final. Everyone executes.
Common DRI Mistakes (What Breaks the System)
The DRI framework is simple but breaks when people don't follow it.
Mistake 1: DRI tries to get consensus instead of making decisions. The DRI seeks input from eight stakeholders, tries to make everyone happy, and creates a compromised plan nobody loves. The fix: gather input, make an informed decision based on priorities and evidence, document it. You don't need everyone to agree—you need everyone to commit to executing once the decision is made.
Mistake 2: stakeholders ignore the DRI and escalate every disagreement. Sales doesn't like the decision, so they go straight to the VP or CEO instead of working with the DRI or providing evidence for a blocking concern. The fix: the exec sponsor must reinforce the DRI framework. "I've assigned [Name] as DRI for this launch. Work with them. Provide evidence if you have a blocking concern. I'll only override if there's clear evidence the decision creates unacceptable risk or misses a major opportunity."
Mistake 3: DRI makes decisions without gathering input. The DRI decides in a vacuum because gathering input takes time and slows things down. Stakeholders feel blindsided and resist execution. The fix: input gathering is non-negotiable for any meaningful decision. Build time for it into the timeline. Better to delay by three days to gather input than lose three weeks fixing broken stakeholder relationships and resistance.
Mistake 4: no clear DRI assigned at kickoff. The launch starts with "we're all collaborating!" and everyone assumes someone else is driving. When disagreements arise, nobody knows who decides. The fix: assign a DRI by name in the launch kickoff meeting. Write it in the launch brief document. Make it completely explicit who owns the outcome and has decision authority.
The Success Metrics: How to Know If DRI Is Working
You know the DRI framework is working if decisions get made within three to five days, not three weeks. Escalations are rare, less than 10% of decisions, because DRIs are making good calls within their scope. Teams execute without confusion about who owns what or what the priorities are. Post-launch retrospectives don't cite "unclear ownership" or "decision paralysis" as problems.
If launches are still slow, unclear, and full of conflict, the DRI framework isn't being followed. Either DRIs aren't making decisions decisively, or stakeholders are ignoring the DRI and escalating everything, or exec sponsors aren't backing the DRI's authority.
The Uncomfortable Truth (Authority Must Be Real)
Most companies say they want clear ownership and accountability. Then they don't actually give DRIs authority. Stakeholders still expect consensus. Executives still override decisions without clear rationale. The DRI is accountable for the outcome but not empowered to make the decisions required to drive that outcome.
For DRI framework to work, leadership must enforce it consistently. "We assigned a DRI. Trust them to make the call based on their expertise and judgment." "If you disagree, provide evidence to the DRI. Don't just escalate to me because you don't like the decision." "I'll override only if there's clear evidence the decision creates unacceptable risk, not because I would have chosen differently."
Without that top-down support and enforcement, DRI becomes "the person we blame when the launch fails" instead of "the person empowered to drive outcomes." The title without the authority.
When DRI works properly—when one person has clear decision authority backed by leadership—launches move fast, decisions are clear, conflicts get resolved quickly, and teams execute confidently. When it doesn't work, you're back to design-by-committee and decision paralysis.
The framework is simple. The hard part is actually giving someone authority and letting them use it. Do that, and launches get dramatically faster and clearer.