New Features are Rarely the Answer

If you'd rather listen to this article:

One of our biggest responsibilities as product managers is the day to day management of our backlog. Working with the team to make sure that the things we need to build and do are well documented, prioritized, and eventually executed on. A good product manager cares about the state of their backlog and knows it inside and out.?

However, since the backlog is so important to our team success and so much of the backlog is made up of engineering tasks, it can be easy to come to the misplaced belief that the only (or the most effective) way to affect change is through coding new things.?

This bias is often summed up with the phrase, "if all you have is a hammer, everything looks like a nail;" but that's never been particularly satisfying to me since it is often used in circumstances where the person has more than just the single metaphorical hammer and most often the hammer is a person and not a hammer at all. I dug a little into the origin of the phrase, which are much more interesting that the cliche.?

It turns out that the first time this hammer concept is recorded was in Professor of Philosophy Abraham Kaplan's Law of the Instrument: "Give a small boy a hammer, and he will find that everything he encounters needs pounding." Later on, Abraham Maslow (of hierarchy of needs fame) would write in The Psychology of Science, "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

Both of those original statements are clear on the point that if someone truly only has a hammer, it can lead to a bias. As product managers we have way more than just our backlog of engineering tasks (a hammer). We often have team members in marketing (a megaphone) and CS (a ladder). We have companies to partner with and in some cases integrations (a multi-purpose ratcheting screwdriver), onboarding emails and in app messaging (a... series of automated onboarding emails). So the bias usually doesn't come from an actual limitation, but from a self-imposed restriction in our thinking.

Beyond that fairly pedantic issue is the much greater one. The people we work with aren't tools and they aren't anywhere near as one-dimensional as the figurative hammer. Our teammates, whether they're engineers, marketing folks, cs team members, or anyone else, has a lifetime of experience and creativity to bring to the problems we want to solve. Are some people better at solving certain problems than others? Sure. Does that mean we should view some or all of them as blunt, single-purpose instruments as opposed to heart and soul team mates? certainly not.?

The knowledge that we have these teammates with varying skillsets and perspectives gives us the chance to go back to our initial problem and identify ways to get to our goal that don't necessarily involve engineering new features (I wrote A Framework for Decision Making to list out a simple series of questions to ask yourself to make more effective decisions).

We should make sure that we're regularly checking that?we're focused on the most important business and customer problems and not a specific toolset. Some things to think about:

• What areas of the platform are most underused, with the highest correlation with success and stickiness that we could be educating more people about?
• What do we already know, or what can we surmise about the people who use our product from their behavior that we aren't currently using to make their experience more personalized?
• What emerging best practices are out there that use our existing features that we can education people about?

To be clear, this doesn't mean we shouldn't build new things. It just means that since our engineering time is finite, we need to focus it on the highest priority new things, and use the other capabilities we have to solve the problems they can.

Remember, you have more than just a hammer. You have a whole workshop full of tools to work with and a team of smart, talented people to collaborate with.