Methods & Frameworks Product Managers Should Know: Part 2 of 2
If you’re looking to improve your team's work, a product management framework can be an excellent starting point. A framework is a set of guidelines or principles that can help guide your team’s decisions and provide a common understanding for all team members. While frameworks don’t necessarily cover every aspect of being a good product manager, they provide guidance on how to approach problems and make decisions.
In our previous article “Methods and Frameworks Product Managers Should Know: Part 1 of 2”, we discussed four frameworks that help designed to help product teams improve and refine their approach to product development. In this article, we continue doing the same. Below are three unique yet impactful frameworks you as a product manager can use for your next feature/product development.
1. DACI
What is it?
The DACI decision-making framework is a model designed to improve a team’s effectiveness and velocity on projects, by assigning team members specific roles and responsibilities when it comes to group decisions. DACI stands for
- Driver (the person who drives the decision),
- Approver (the person who makes the decision),
- Contributors (the people or teams whose work or knowledge aid in the project), and
- Informed (the people whose work might be affected by these decisions and hence need to be kept in the loop).
Why use it?
The DACI framework is useful in situations where a decision is going to affect multiple groups of people across different teams and business units. The process provides the context so that people know why a decision was made. There are a few other reasons why you as a product manager should use DACI,
- Eliminating friction and confusion by giving complete authority over specific aspects of decision-making to a specific person.
- Representing every aspect of decision-making with a specific role.
- Removing collective responsibility and correcting team imbalance by giving authority to one person or role.
- Eliminating potential disagreements and speeding up decision-making
How to use it?
Consider the below example to understand how you as a product manager can utilize the DACI matrix for the decision-making aspect of your next feature initiative.
2. Buy A Feature
What is it?
Buy-a-Feature is an approach to prioritizing a product’s development and is used in various product and engineering teams. The product team works directly with a group of customers or other stakeholders to learn what features or enhancements to the product those participants would value the most.
Why use it?
The main use-case of buy-a-feature is when the product team is struggling with a complicated list of features, limited resources, and a shorter timeline. Buy-a-Feature is a game-based activity that can help put these limited resources according to the priority and where they are needed the most.
How to use it?
As the name suggests, the mechanism for determining customers’ favoured features is to give them each a fixed amount of play money for the exercise (denominated in poker chips, jelly beans, Monopoly money, etc.). Then, let them spend that money on the proposed products — each of which will have its price tag based on its estimated development costs. The game can be played internally with your product team or externally with the customers.
3. Two Equal Parts
What is it?
Two equal parts is a framework introduced by Typeform. According to the framework, the first part of the product development process focuses on product discovery, while the second half of the framework focuses on delivery. Discovery consists of identifying problems, brainstorming solutions, and validating solutions with a testable product. Once a feature clears discovery, it moves to delivery, which is made up of three more steps: scope, execution, measurement, and iteration.
What sets Typeform’s framework apart is its unique approach to MVPs. They don’t have just one version. Instead, they break the MVP into three parts:
- Earliest testable product — The testable product is the fastest way to get data on an idea. So as not to spend too much time developing an MVP, the earliest testable product might be something as simple as a fake door test.
- Earliest usable product — A “usable” product is an actual product that early adopters will use without being incentivized. At this stage, the product has baseline functionality and may lack “delight,” but the purpose is to collect data and feedback. Typeform is trying to figure out whether it’s worth putting more hours into developing the full product.
- Earliest lovable product — This is the product that customers will love. They’ll tell their friends about it and are willing to pay a premium for it. It’s still not 100% finished, but it’s the closest thing to a finished product at this stage.
Why use it?
Breaking down your MVP into bite-sized pieces will help you get feedback and data during every step of the process. That way, you can use a much more measured and testable approach to delivering something your customers want.
How to use it?
An example created by Sebastien Phlix and illustrated by Henrik Kniberg can explain the framework and its essence.
There is no one-size-fits-all approach for PMs
A framework is a tool, not an end in itself. Like all tools, it can be used correctly or incorrectly by different people at different times in order to achieve different results.
Different businesses have different problems, solutions, and goals. Different businesses have different customers with different needs and expectations. They also have products that serve these customers in unique ways, which are distinct from those of other businesses within the same market segment or industry vertical.
