Product Management Terms for Decision-Making Methods

Product managers make dozens of decisions every week. Which feature ships first? Should we pivot the strategy? Who approves this change? Without clear decision-making frameworks, these choices become slow, political, or based on whoever argues loudest. Teams waste time in meetings that don't resolve anything. Important decisions get stuck waiting for clarity on who decides. Decision-making frameworks bring structure to these moments. DACI clarifies who drives decisions, who approves them, who contributes input, and who needs updates. Jobs-to-be-done helps you understand why customers hire your product, shifting focus from features to underlying needs. Opportunity solution trees map paths from business goals through customer problems to tested solutions. Impact mapping connects strategic objectives to user behaviors to specific features. Some frameworks focus on process clarity, others on understanding customer motivation, but all share a common goal of moving teams from endless debate to confident action. The right framework at the right moment transforms decision paralysis into progress.

DACI framework

DACI is a decision-making framework that assigns 4 specific roles to clarify who does what in group decisions. Developed at Intuit, the acronym stands for:

• The Driver leads the process, gathering information, scheduling meetings, and pushing the decision forward, but doesn't make the final call.
• The Approver has final authority and makes the ultimate decision, typically a senior leader or manager with decision-making power.
• Contributors provide expertise, input, and recommendations that inform the decision. They might be designers offering a UX perspective, engineers explaining technical constraints, or researchers sharing user insights.
• The Informed are stakeholders who need updates about the decision but don't participate in making it, like sales teams who need to know about upcoming features or support teams preparing for changes.

DACI solves a common problem where everyone feels responsible for decisions, but nobody has clear authority, leading to endless debate or decision paralysis. By explicitly naming one Driver and one Approver, the framework eliminates confusion about who's accountable. It works particularly well for complex cross-functional decisions involving multiple departments, high-stakes choices with significant consequences, or situations where teams struggle with slow decision-making.^[1]

Jobs-to-be-done framework

Jobs-to-be-done focuses on understanding why customers hire your product rather than what features they want. Developed by Tony Ulwick and popularized by Clayton Christensen, the framework treats products as tools customers hire to get a job done. If your product doesn't do the job well, it gets fired in favor of competing solutions. The classic example comes from a milkshake study. Researchers discovered people bought milkshakes in the morning not because they wanted a drink, but because they needed something to make their boring commute more interesting and keep them full until lunch. The job wasn't "drink a milkshake," it was "make my commute less boring while staying satisfied until lunch."

Understanding this job opened new innovation opportunities beyond just improving the milkshake flavor. Jobs remain stable over time even as solutions change. People have needed to get from point A to point B for centuries, but the products they hire for that job evolved from horses to cars to planes to ride-sharing apps. By focusing on the underlying job instead of current solutions, teams avoid building faster horses when customers actually need cars. The framework helps product managers understand true customer motivations, identify unmet needs, and innovate beyond incremental feature improvements.^[2]

Opportunity solution tree

Opportunity solution trees visually map the path from desired business outcomes to tested solutions. Created by Teresa Torres as part of continuous product discovery, the tree structure keeps teams aligned while managing the complexity of discovery work. At the top sits your desired outcome, typically a business metric like revenue growth or reduced churn. Below that spreads the opportunity space: customer needs, pain points, and desires that, if addressed, would drive your outcome.^[3]

The tree branches into specific opportunities discovered through customer interviews, then into potential solutions for each opportunity, and finally into experiments to test those solutions. For example, an outcome of "increase retention" might branch to opportunities like "users struggle with onboarding" and "advanced features go undiscovered." Each opportunity then branches to multiple solution ideas, which branch to quick experiments testing assumptions.

The visual structure prevents teams from jumping straight to solutions before understanding opportunities or building features without validating assumptions. It makes implicit thinking explicit, showing stakeholders how solutions connect back to customer problems and business goals. Teams work on one small opportunity at a time rather than trying to solve everything simultaneously. The tree evolves as experiments provide learning, with branches growing or pruning based on validated insights.^[4]

Pro Tip! Work on one small opportunity at a time rather than trying to solve everything at once.

Sunk cost fallacy

Sunk cost fallacy is the tendency to continue investing in something because you've already invested time, money, or effort, even when continuing no longer makes sense. The resources already spent are gone regardless of what you do next, but people irrationally let past investments influence future decisions. Product teams fall into this trap constantly, continuing to build features nobody wants because they've already invested months of work.

For example, a team might keep developing a complex integration even after learning customers don't need it, reasoning, "We've already spent 3 months on this, we can't waste that effort." But those 3 months are gone, whether you finish or not. The rational choice is asking, "Given what we know now, is this still worth the next 3 months?" If the answer is no, stopping saves future waste rather than compounding past waste.

The fallacy becomes particularly dangerous with long projects where teams become emotionally attached. The longer you've worked on something, the harder it feels to abandon it. Product managers need to separate past investments from future decisions. What matters isn't what you've already spent, but whether continuing creates value going forward. Good decision-making means being willing to kill projects that no longer make sense, even after significant investment.^[5]

Impact mapping

Impact mapping is a visual planning technique that connects business goals to deliverables through actors and impacts. Created by Gojko Adzic, it answers 4 key questions in sequence:

• Why are we doing this?
• Who can produce the desired effect?
• How should their behavior change?
• What can we build to support that change?

The map branches from a central goal outward through these questions.

For example, a goal of "increase revenue by 20%" might branch to actors like "existing customers" and "trial users." For existing customers, the desired impact might be "upgrade to premium plans." Solutions supporting that impact could include "add collaboration features only available in premium" or "show ROI calculator demonstrating premium value." The map keeps solutions connected to specific behavioral changes in specific actors, all tied back to the original goal.

Impact mapping prevents teams from building features disconnected from business objectives. It makes assumptions explicit about which user behaviors will drive goals, allowing teams to test those assumptions before building. The visual format facilitates stakeholder discussions because everyone can see how proposed features connect to outcomes. Teams often discover they can achieve goals through simpler solutions once they focus on changing specific behaviors rather than building comprehensive feature sets.^[6]

Pro Tip! Impact mapping prevents building features that don't connect back to business goals.

5Ws and H

The 5 Ws and H is a simple questioning framework for understanding problems thoroughly before jumping to solutions. The questions are:

• Who is affected?
• What is the problem?
• When does it happen?
• Where does it occur?
• Why does it matter?
• How does it impact them?

By systematically answering each question, teams ensure they understand a problem from all angles before deciding what to build. Product managers often rush from hearing a complaint to building a solution without fully understanding the context. A customer says, "The dashboard is confusing," and teams immediately start redesigning it. But asking the 5 Ws and H reveals deeper insight:

• Who finds it confusing? New users or power users?
• What specifically confuses them? The layout or the data itself?
• When does confusion happen? During onboarding or daily use?
• Where in the dashboard? The overview or detailed views?
• Why does this confusion matter? Does it prevent task completion or just slow people down?
• How does it impact their work? Do they make mistakes or just waste time?

These answers might reveal the real problem isn't the dashboard design but insufficient onboarding for new users, suggesting a completely different solution. The framework is deceptively simple but powerful for ensuring teams solve actual problems rather than assumed ones. It works particularly well early in discovery when defining what to investigate.^[7]

4 Ds of time management

The 4 Ds of time management help product managers decide what to do with incoming tasks and requests. Every item gets categorized as:

• Do it now if it's urgent and important.
• Defer it by scheduling a time later if it's important but not urgent.
• Delegate it to someone else if it needs doing but doesn't require your specific skills.
• Delete it if it's neither urgent nor important.

The framework prevents two common problems: reactive work overtaking strategic priorities, and task lists growing infinitely without anything getting completed. When someone requests a feature review, product managers can quickly decide: Does this need my immediate attention? Should I block calendar time for it next week? Can a designer or engineer handle this instead? Is this actually worth anyone's time?

The key is being honest about delegation and deletion. Product managers often feel they should personally handle everything, leading to burnout and important work getting delayed. But many tasks don't require PM judgment and should be delegated. Others simply aren't worth doing despite feeling obligated to say yes. The 4 Ds give you a structured way to make these calls quickly rather than letting your inbox and calendar fill with low-value commitments that crowd out real priorities.