As a product owner deciding what to do or not to do for your product can be tricky. Most often the number of opportunities in front of you are more than what you, your team and company can focus on. Between the qualitative and quantitative data from your customers, competitors, stakeholders and your own team this decision making can become over whelming.
Getting to key focus areas is definitely an exercise that involves both art (intuition) and science (frameworks). Intuition as I define it is judgement, insight borne out of observation and possibly experience. There are probably better words to describe intuition but I’ll leave that for a different post. Let’s talk about frameworks…
There are tons of frameworks out there to aid decision making. But I’ll still throw out yet another one (I developed) into the mix - EFQ.
What is EFQ?
EFQ is Effort, Frequency, Quality - a framework that is modeled similar to ICE scoring model where you score potential ideas to quantitatively determine which ones to pursue. The ICE framework is super popular and effective as it’s simple to apply to many different situations, so EFQ tries to leverage the strengths from scoring and ranking.
Benefits of EFQ
Reducing subjectivity
A drawback I’ve noticed in some frameworks like ICE is that scoring “Impact” and “Confidence” is bias and subjectivity involved in quantifying these factors. Since both of these are subjective - intuition and bias naturally factor in and could affect the outcome of the exercise.
The inputs for “Effort” and “Frequency” can come very directly from instrumented KPIs you have or from customer behavior you gather. These should be easy to derive from facts. As a result, EFQ factors also inherently avoid stakeholder and/or competitive inputs that can bias scoring.
Level of effort agnostic
I’d also argue that with costs of development generally being pushed down lower due a multitude of factors (cloud, dev frameworks, APIs etc) it likely should not be factored in quite as heavily as it currently does in prioritization decisions. When determining what is the right thing for the business to pursue, let’s focus more on impact and leave the estimation to product scoping stages.
Most frameworks assign heavy weightage to level of effort and while this a real tradeoff and cost to consider, I’d argue that this factor and discussion can be moved scoping exercise where the team figures out the best way to solve the said idea/customer need after we’ve decided this even is worth solving.
Customer centric
All 3 factors in EFQ are from a customer view point rather than internal perspective. By removing aspects like cost, urgency etc we are putting ourselves in the customers’ shoes. The scores you assign and outcome you reach from this exercise should end up very close to how your customer would fill out.
Even your customer can fill out the EFQ framework and get the same results as you
Breaking down the framework
Effort
Effort is how much time a given job takes for the customer. This is not the effort of development and maintenance for this feature/idea. For example if a job takes a few minutes it gets a 1, about an hour gets a 3 and about a day gets a 5.
As the effort to complete a job increases so does the score.
Frequency
Frequency is a measure of how often the customer does a given job. For example a job done daily is 5, weekly in 3 and monthly is 1.
Keep in mind that your scale is assigning a lower score for less frequent jobs. This is so that jobs that are done less often get less weight.
Quality
Quality (or quality risk) is a measure of the quality of outcomes for the job if the customer does not have the idea you’re evaluating. Your assumption is that by not having the said feature the customer completes the job with potentially more errors, lower satisfaction or is unable to complete the job at all.
Assume you don’t have a confirmation for a major settings change. It’s likely that customer confusion about the settings leads to them make a change they didn’t fully understand resulting in impact down the line which leads to churn, dissatisfaction or higher costs for you to remediate this customer. In this the quality score would be high because having this feature would dramatically improve the quality of outcomes for the customer and your team.
You choose the quality score scale such that a higher number indicates a higher positive impact to quality.
Final scoring
Once you have the relative scores for all potential ideas you should have landed on the winning ideas and opportunities to pursue.
Choosing a scale
The scales you choose can vary based on your preference - go from 1 to 10 if needed. Preferably a scale of 3-5 values should get you precise enough results.
EFQ in action
Where to apply
Everywhere? ;) You could apply EFQ to both 0-1 feature development where you want to understand what new things to build or you can also apply this to incremental improvements you plan to do for a product that is live. You should be able to apply this to compare across new feature development and incremental improvements too.
Example
Let’s close with an example. Let’s take these hypothetical features we’re considering for an expense management app. Using the scales described you’d probably agree quickly on the effort and frequency. The quality scoring can be debatable but lets assume that incorrectly changing account settings or not being able to contact support could be bigger pain points and impacting quality vs incorrect data submitted on receipts. You can now see where to focus very easily.
Summary
EFQ can be effective when trying to minimize subjectivity and develop high customer centricity in your decision making. By looking at jobs to be done by customers and aligning priorities based on their perspective versus internal perspectives we can hopefully come closer to building products they love and use.
I’d love to hear your thoughts and feedback on this framework.