Before I dive into the crux of this article, I want to be clear about this new phase in the product management process: we’re going to be jumping around more than usual here. Validation could also be called rapid experimentation. The goal of Validation is to eradicate any doubt of our product not being valuable to our customers and our business.
So, to recap, in the last step of our Discovery process, we discussed how we could rapidly ideate solutions to our customers’ problems utilizing the “How Might We” and the Worst Possible Idea methods. After we come up with those ideas, we have to determine which ones are good and worth moving forward. This is where assessing the impact compared to the feasibility comes into play.
The Impact/Feasibility matrix
The impact/feasibility matrix enables us to visualize how straightforward or complex an idea will be to build and how much value it will provide the customer. I place this step in Validation because when we’re ideating, we’re not seeing the bigger picture of how those ideas compare to others. When we put the ideas on a matrix like this, we start dragging them around.
How do we start?
I typically start this exercise by placing the idea I think has the highest impact and highest feasibility (the lowest hanging fruit, if you will). Then I set the highest impact and lowest feasibility (major project). Finally, you can probably see where this is going; I place all the edge cases on the board for each quadrant, similar to when building a puzzle. Of course, we can build from the middle outward, but it’s much easier to have the frame and build inward.
Low Hanging Fruit (High Impact/High Feasibility)
The low-hanging fruits are the quickest wins and the things we should no doubt start wireframing and mocking up. Of course, sometimes this is easier said than done, but in general, it’s always easier to provide these quick wins than the rest of the other quadrants.
Major Project (High Impact/Low Feasibility)
These projects are ripe for MVP’s (minimum viable products). I have a lot of thoughts on MVP’s, so allow me to get on my soapbox for a second. In an ideal world, the concept of the MVP is almost flawless. Unfortunately, we live in the real world where humans are involved. I’ve seen this term butchered and interpreted ways that make an MVP fall flat on its face and end up in the trash more often than it is allowed to become a successful product. Many folks think MVP means the bare minimum criteria needed to be viable and usable; what they miss more often than not is creating something valuable. The term minimum viable product often becomes an excuse not to make something of value; it needs to shift to Minimum Valuable Product.
With that said, we, as excellent product managers, can break down these major projects to release incremental nuggets of value (in other words, a series of MVP’s). For example, we wanted to create an intake component to enable users to request access, enhancements, general service, and report incidents in a product I was managing. As a whole, this was a massive project requiring the coordination of multiple departments and stakeholders. We broke it down into multiple MVP’s where we would enable intake piecemeal, starting with what would add the most value first (requesting access), then adding on as we go.
Busy Work (Low Impact/High Feasibility)
I would hesitate to do stuff in this area unless it impacted elsewhere. What do I mean by this? Suppose one of these ideas had a low impact on our customers and a low impact on our business. Still, it would drastically increase our credibility with some internal stakeholders. In that case, we might want to consider doing this. We also need to determine the right time to work these into the product. I try to figure this out by estimating how valuable that stakeholder relationship is/will be. For instance, I wanted to sell a new product to one of my current customers. The new product targets customers in an entirely new department than the existing product. Before our current customer would introduce me to those new users, they needed to see the product and then had some things we needed to build into it first. Yes, these things we had to build into the product were for this customer. After some discovery, however, we determined these things would scale beyond this customer. Although, the overall impact on all of our target customers remained low. We improved the product with these changes, got introduced to these new users, and won their business.
Don’t waste our time (Low Impact/Low Feasibility)
Now, it’s easy to place an idea here most of the time, but sometimes we need to validate it before we throw it away entirely. Often we know these requests right off the bat, but sometimes we’re in conversations with other stakeholders who propose ideas we know aren’t good, but we can’t immediately shut them down. Managing these relationships is where our job becomes political. I’ve found myself having to validate or “discover” why ideas aren’t good before I shut them down many times. Always, always, always use data. Using data removes us from the situation and shows you care enough about your stakeholders’ ideas to validate or invalidate them with numbers and logic rather than feelings.
Conclusion
There are many prioritization frameworks. First, there’s the framework I provided above. Then, the MoSCoW method(must have, should have, could have, won’t have). Then, there’s the RICE framework, Weighted shorted jobs first (WSJF) framework, or the Kano model, to name a few. I stuck with the impact/feasibility matrix because it’s easy, and my main goal is to provide a step-by-step process without getting too into the weeds or being too complex for product managers to follow. I want to enable us to sift through all the noise and focus on getting our jobs done with as little distraction as possible. I’ll go over these other frameworks later, but for now, good luck with the impact/feasibility matrix, collecting winning ideas, and moving on to our next step: wireframes & mockups. See you there!
Recent Comments