Not all problems/opportunities are created equal
It’s easy for builders to get down on a tactical level and lose sight of the big picture and, sometimes, lose sight of something’s original purpose. As far as I observed, this is a symptom that affects most employees in all tech companies — the cult of do-do-do-do tramps the cult of do-think-do-think.
The question to keep asking yourself is: What’re the right priorities for each activity and the amount of effort that justifies them?
The anti-pattern of not right-sizing effort properly is:
- Treating features of similar cost with similar priorities
- Accepting all customer requests at face value and adding them to the backlog
- Fixing all the bugs
- When there is an incident, working to prevent that type of incident from ever happening again
- Not differentiating the level of commitment for an RFP/Pitch vs. a PoC vs. a Prototype vs. an MVP vs. a full launch.
- Treating all partners/customers equally
- Being extremely proactive and getting things done much before they are needed
These are bad because it takes resources away from other things that actually need to get done.
The most natural “way out,” one might say, is to ask someone above you in the chain of command to make that decision. What should I do first? How much should we invest in X? Should we do feature Y for customer A before we do feature W for customer B? Should I visit customer C on the East Coast or customer D on the West Coast?
If you find yourself resorting to asking your manager this question often or if you frequently realize you over-invested or made the wrong decisions, this post is for you.
Let me start by giving you a way out. Every once in a while, you need to consult others. From your vantage point, both customer A and customer B look similar. Or, feature Y and feature W will cost the exact amount to build and launch, so they seem interchangeable. However, those situations should be the exception, and you should be equipped to make the right decisions most of the time.
Impact vs. # of Users
There are several types of matrices that you can use to help you determine the priority of something: Value by effort, value by risk, defensibility by effort, etc. However, I want to focus on the impact of the # of users matrix.
It’s an interesting matrix because it works for new initiatives as well as bugs/issues. Here’s what this matrix looks like:
You can plot all the “things” (features, bugs, contracts, customers, etc.) by determining the number of users who will be impacted and the value of that impact.
The vertical axis can be tricky, but you can use metrics like revenue from users, how much more satisfied they’ll be with the product (intuition works fine here if you don’t have data), proximity to the core value proposition, frequency of usage, etc.
The numbers are the priorities. The features, bugs, activities, initiatives, deals, and whatnots that fall in the top-right quadrant (#1) should take precedence over everything else. Even inside of a quadrant, you can prioritize execution order.
Quadrant #4 (bottom left) is where the initiatives for you to “just-say-no” live. For items in that quadrant, you need a robust strategic explanation if you still want to execute them. For example, the optionality of an experiment, hedging a risk (e.g., a privacy/security risk), or a PR/Marketing value attached to it might be reasonable justifications.
The trick is between quadrant #2 and #3, which might depend on your product stage. Typically, it’s better to have fewer users who are passionate about your product than many users that find it “meh.” In that case, you might want to favor the top-left quadrant. However, a small increment improvement that all or most of your users could be considered a higher priority than an impactful feature impacts very few.
For that reason, the right “matrix” that you should be using is this one:
Follow me on Twitter: @calbucci
