There’s an innate trick with the human brain. It remembers procedurally anything you try to think about. What’s the remote button to switch to a channel? Your brain tries to remember the last time you performed that action and only then recollects the answer to the ‘what’ part. There’s a downside to this kind of thinking. It’s great to find a logic and revel in it, only until the human mind tries to apply the same logic to anything that it thinks is remotely related. Sometimes, it also brings in a false connection just so that it can apply the logic across to any situation. This habit doesn’t take a long time to grow.
Let’s say you’re threatened by a bug or a pet. The fear makes your mind picture the presence of what threatens you literally in any place you focus on. This unconnectedness and unnecessary patterns crawl their way into our mind very easily. This is similar to the folk phrase ‘a man with a hammer’ meaning to a man who has a hammer, anything and everything looks like a nail. What’s more intriguing is how much similar this effect is to laying out and prioritizing product features.
This concept was interestingly explored by Charlie Munger in one of his speeches in 1994, more from an investment management perspective. Coincidentally, the very same concept can be applied to product management as well. As a maker, you think you have a grip over your hammer aka product roadmap. When you’re looking at your product, your shortsightedness can sometimes lead you into thinking all the features you have in hand are necessary. Leaving the actual problem statement and the user experience behind, your hammer just tries to hit every nail right, sometimes things that aren’t even nails.
What needs fixing here is not throwing away the hammer but trying to fill your toolbox with other tools—some spanners, drivers, and drillers could be a great addition, all of which will help you see the dents and holes and not just the nails.
As for prioritizing product features, teams can follow different frameworks, but what matters at the end is picking the right ones that are solving the relevant customer problems. When Instagram was originally Burbn many years ago, growth was stagnant beyond 80 users (most of whom were friends of the co-founders). Systrom and Krieger had built a thriving app that could potentially invite the interest of many users, but what did it really lack? Did Burbn need a new feature to attract the target audience and bring signups in droves?
The solution was simple—the co-founders saw that Burbn had three popular features, pretty much overwhelming for the times. The features were—checking in at locations, coordinating visits with other users, and uploading photos when you checked in somewhere. They finally narrowed it down to one—they chose photos. And, the rest about Instagram is history! So the hammer hit another nail or did the toolkit’s observational tool help recover from the dent? You know it by now. [Fast forward to the current times, is the brand’s toolkit really working? That’s another debate altogether!]
It’s not always easy to prioritize features and it’s never a one-logic-fits-all case. While frameworks and techniques can differ, some standard tools can set the base to apply those:
It’s a known fact that rephrasing or removing lines from a script is a tad easier than writing something from scratch. The same lens can be applied to setting your product themes and drawing up on the features. Start at a broad scope, list down all your user problems, key themes your product revolves around, and challenging posits you need to address. Instead of hitting the hammer on everything you have initially listed, construct distilled versions through iterations. Stop when you know it’s all not just nails but what your product fundamentally needs to address. The key lies in simplifying.
All of us would have used the Boltzmann constant in our physics problems, but Boltzmann wasn’t the person who invented this constant in the first place. But he’s the person who made the derivation of the fundamental value in a more simpler way than the actual not-so-famous person who tried to initially start work on this. Several iterations later, the fundamental result is championed for its simplicity and its nature to support the core problem in hand, not the complex way it started eons ago.
Mostly we assume costs to be the direct incentives from our product or the production time it takes for planning and execution. So, prioritizing features or researching new ones always revolve around the concept of ‘creative’ timing. But talking to cross-functional teams can help you get a holistic concept of other kinds of delays-turned-costs.
Carrying costs are counterproductive and they can take the shape of marketing, maintenance, sales, support, or customer success performances. If maintaining databases is at one of the spectrum, allocating budgets and capping CAC for all the new features when added to the product can be at another end. To add to the ongoing imbalance, operational costs around bug-fixing and closing the alarming support tickets can worsen the situation at hand. Even if not directly, these costs influence the existing features as well as the new ones happily stationed in your roadmap. What contributes to outcomes and what increases the burden of negative costs can result from shared understanding with your co-teammates from other verticals, productive researching, and calculated estimations.
Calls, tickets, ratings, or messages—negative impact can queue up within no time even after the product team spends hours working to finesse. Did the finesse involve the right tools from the kit or just the old rusty hammer? Picking the wrong customer problems and solving for it even with utmost care and priority can lead to poor gains. Also, it’s never easy to know which of the features can drive retention or which could increase the perceived value of your product. It’s with experience and repeated learning you figure that out.
One of the simplest tools, almost any product person’s friend, is ranking based on intuition and importance. Stripe (thanks to Shreyas’ coverage) has been following a technique called Customer Problem Stack Rank, that lets you involve stakeholders from different internal teams and build a set of peripheral problem statements, ranked according to priority, that can be vetted and examined by customers. Customer discovery stories? Sort of, but directly done in a way where customers focus on problems given to them easily at hand and not suggesting random features to you/your team directly. A similar approach that comes to mind is MaxDiff scaling or analysis where customers can vote for least preferred and most preferred of the problems (or existing features, if you’re taking an audit) and you can apply calculation to find the scales in which they belong.
Indeed the hammer syndrome never often unhides itself until we later figure out something has been messy all the while. That’s because the nails end up looking like they need a hit. All features and ideas are great and exemplary, but time gives the right learning in pursuing what makes more sense to the customers, stakeholders, and the product as a whole. Until then, stocking our toolbox with the right items is the best we can all do to soon keep the hammer away.