Kano, MoSCoW, KJ Method, QFD.

To many, these may sound like candidates for the latest celebrity workout plan. To a product manager, these are just four of the 20+ well-documented prioritization techniques all trying to achieve the same goal: provide a strategic framework for determining which features should be invested in—and in what order—to deliver the most value for both a company and its users in any given time frame.

The best way to approach feature prioritization is so hotly debated because in SaaS, the successful growth and development of a company can often be traced back to key prioritization decisions. These are the decisions that allowed a product to address the right customer pain, in the right way, at just the right time.

The 20+ frameworks out there, all focused on how to get these mission critical decisions right, are mostly developed for product managers by product managers.

Why?

Because PMs are on the front lines of this decision-making every day.

Ultimately, when it comes to a good product strategy, the whole is often greater than the sum of its parts. As a PM, by exploring the different inputs that feed into the equation, you can often come up with a combined approach that meets the specific needs of your product organization. At some point, though, some key truths must emerge, right? Is there a secret sauce?

Maybe.

First things first: Defining value

In early 2016 at Klaviyo, I was the only PM working alongside a newly hired Director of Product. We were excited to tackle this classic prioritization puzzle head-on. Picking a starting point, the two of us decided to pin down one of the more nebulous elements first—value. 

If we wanted to make sure our engineering resources were being invested in the right projects, and “right” translated in part to “highest value”, we had to first define what value meant to the company.

At the time, we were interested in coming up with a quantitative scoring system that let us rank the potential value of any proposed piece of work. Anticipated effort aside, how could we rank the business value of a given bug fix against, say, a new feature idea? Or an internal efficiency improvement?

We developed a set of value scoring matrices that, over time, proved to be a solid foundation for dynamic prioritization.

For each entity type, we looked consistently at criticality vs. scope of impact. If a bug is blocking a key feature for many known customers, the value in fixing it is high. For feature ideas, we found we could use a similar model.

There are some nuances worth noting. We realized that the value of fixing a fringe bug that’s only annoying one, small account on a Free plan is different than if that same bug were actively bothering one large top-tier account. We gave needs or requests coming from large accounts a 2x multiplier to account for this inherent value discrepancy when it came to the origin of an entity.

Similarly, we needed a way to ensure we were prioritizing work that aligned overall with the company’s established business goals. At any given time, work that could help move the mark on a key OKR or KPI was certainly more valuable to the business than something that wasn’t aligned with any goal. To solve for this, we gave entities a 3x multiplier if they were aligned with an established business goal.

You may have also noticed that the Feature Value Scoring Matrix, by design, already prioritizes one type of stakeholder value over another. This comes back to the three high-level categories of value generation that are most often discussed when it comes to feature development:

Business goals, or established KPIs, may not necessarily speak to these outright. Stack ranking these three overarching types of value, however, is required to give a company’s prioritization process a north star. For Klaviyo at the time, we wanted to reduce churn—our existing customers were our focus. This is why we placed “Will Churn Without” above “Won’t Buy Without” when it came to the criticality of a new feature idea.

One big win was that we were able to present these matrices to the rest of the company so they could understand our methodology. Engineering teams could then even go as far as saying, “Hey, we’re allocating 30% of each sprint to tackle bugs in Q2 and are committing to prioritizing all bugs scored 6 or above within 2 weeks” or “Due to resource constraints, we may not be able to get dev eyes on new bugs scored 3 or below for the next few weeks.” Those that submitted ideas or bugs had real-time visibility into the score applied, which helped with expectation management.

Value vs. effort

Once an entity leaves one matrix, where value is determined, it enters another one: the Value vs. Effort matrix.

Something that is high value and low effort can be considered a quick win. Conversely, anything that is low on the value scale but high on the effort scale is a timesink.

Determining the effort required to solve a problem is a process in itself. At Klaviyo, we’ve developed a love/hate relationship with the SWAG size method.

A scientific wild-ass guess (SWAG) is an educated guess made by someone with enough experience to qualify the guess as “within the scope of reason”. We use SWAG sizing to estimate the effort involved in a project before any real de-risking, validation, or any other type of more rigorous calculation takes place. 

SWAG sizing can help a PM place entities on the Value vs. Effort matrix quickly. Ideas that are more valuable will get prioritized on the roadmap, at which point the actual work will get fleshed out and firmer timelines will get set.

The upside to SWAG sizing is that the earlier you qualify where something falls on the Value vs. Effort matrix, the earlier you can work the entity into your product strategy. The downside comes when a SWAG size is significantly off-base—this can either come from changes in project scope or just poor advanced insight into what may be required to get the job done.

Overestimating how long something will take can leave teams in a disorganized state where the question becomes, “What next?” and the PM is left playing catch up. When effort is underestimated, pushing out timelines by a wide margin can erode trust with key stakeholders and put a team on the defensive.

At Klaviyo, we’ve explored different tools that aggregate new ideas and present them on this type of visual matrix. ProdPad is one tool we’re currently using, where every new idea someone submits comes with sliders for Effort and Value that PMs can adjust after review. There is then one meta matrix with all submitted ideas plotted. This visual matrix can be really powerful to help communicate that (a) there are a LOT of ideas on the map, and (b) value is constantly being weighed alongside effort when it comes to prioritization.

The secret sauce

Brandon Chu, the Director of Product at Shopify, has said that one of the two First Principles of Product Management is: Maximize impact to the mission.

To achieve this first principle, PMs must remain goal-oriented, effectively manage limited resources, and yet always move forward without blinders on. For Chu says that product planning isn’t a straight line, and “...PMs have to listen to their environment to detect, anticipate and course correct the path.”

Reflecting on Chu’s model, we know that goal setting is critical as this feeds into both how projects get prioritized and how success gets measured. The reality of resource constraints is then what makes prioritization so important, and why estimating effort matters. With unlimited resources, most work can be parallelized and disruptions are easily accommodated; what comes first becomes almost a matter of semantics.

Finally, we have this assertion that the path to product success is not linear. In product, being flexible and responsive to new information is darn close to being a first principle of its own.

While a good product leader can take all the inputs, do the necessary research, and dynamically chart a way forward to hit key goals, most will tell you that’s not necessary the hard part of being a product leader. 

Bringing the rest of the company along for the ride, and getting buy-in on your strategy, is the real bear you have to content with. Changing priorities, shifting timelines—all of this can be a critical point of failure for even the best PM if the modus operandi is not well communicated.

So, what if the secret sauce to product strategy isn’t necessarily what you do, but how you do it?

Managing a product strategy and roadmap that is going to gracefully bend (and not break) with change requires not only solving for the critical “buy in” problem, but finding a way to bridge communication gaps across a company in a continuous and ongoing basis.

Getting people to trust you, when the only constant you can truly offer is change, may seem like an impossible task. The way to get there is something not talked about nearly enough when it comes to product management—having a framework for good storytelling.

Good storytelling is the secret ingredient in the secret sauce. 

When it’s there, it tends to be overlooked. Without it, the sauce won’t ever quite come together. 

In my next post, I’ll be discussing how to build a compelling storytelling framework to engage and build trust across stakeholder groups as a product leader. Stay tuned!