Jen Dante, Head of Product for Payroll at Square, opens her talk at #mtpcon Singapore by telling us that humans are terrible at making predictions. This is unfortunate for product managers, given that at its core, our job is all about making predictions. We predict that making a change in our product will have a given outcome for our users or our business, and we’re wrong more than half the time. But there is something you can do that will slightly increase your chances of being right more often: you can stop behaving like a hedgehog, and start behaving like a fox.
The Fox and the Hedgehog
The fox knows many things, but the hedgehog knows one big thing. Archilochus, Greek Philosopher
Jen compares this famous quote with the challenges of product management. The hedgehog, knowing one big thing, only has one framework of how they understand the world. Because of their limited view, “hedgehogs” tend to be completely certain they are right and judge things in a binary way, forgetting all of the times they were wrong in the past.
The fox on the other hand, has many frameworks which they use to try and understand what is happening and to make predictions. Because they are evaluating situations based on many different views, “foxes” tend to constantly change their opinions as new data comes in.
Human nature often conflates confidence with competence, and therefore views the hedgehogs as the most competent when the opposite is often true. In the tech world, you will often hear from writers and speakers who are hedgehogs – completely convinced that their framework is the one right framework. They will tell you of all the times their framework was successful, forgetting the stories of the many times their framework led them in the wrong direction. That doesn’t mean it’s a bad framework – it’s just not the only one.
The Rolodex of Frameworks
As product managers, we should be collecting a variety of frameworks that we can pull out to tackle different types of problems – similar to collecting contacts in a Rolodex. While not an exhaustive list, Jen takes us through three different frameworks that she likes to use in her work.
Jobs to be Done
Jobs to be Done (JTBD) is the idea that you should move away from thinking about the specifics of what your product does, and focus instead on the problems you’re solving for the end user. When you really understand the problem, it opens up the ability to understand other ways that people could solve it. The framing of JTBD allows you to recognize the full range of competition, from your closest competitors to non-digital substitutes, that can provide the outcome your users are looking for.
This is a great framework when looking at your strategy, or trying to see gaps in what you are doing. But it is not useful in every situation; for example, it doesn’t tell you anything about how to price your product.
Behavioral Economics
There has been significant research into the ways that human psychology affects purchasing decisions, which has an impact on how we should price our products. Jen talked through one example of a behavioral economics concept: anchoring.
Whether we are aware of it or not, we constantly evaluate many inputs to make a decision of whether to buy something or keep shopping. With so many scenarios to evaluate, the effort required to make a perfect decision becomes really cumbersome. To compensate, our brains use heuristics to allow us to make quicker decisions. We set a number in our minds that is the “anchor” for a given product, and then evaluate what we see against that number. When we see something lower than the anchor, we get excited at the prospect of a “good deal”. When we see something higher than the anchor, we react emotionally, feeling that the company has broken a social contract and get angry that they are being “unfair”.
Companies to use this to their advantage – showing the “actual retail price” before their lower price, or mitigating price increases from anger. But while behavioral economics is very valuable in this context, it is also not the only framework you should use. It doesn’t provide any information that would help you to answer questions such as “Why are my users dropping off at this point in the flow?”
The Kennedy Principle
To answer questions about user behavior within your product, Jen likes using the “Kennedy Principle”: Never ask your user to do for you, what you can do for your user. Users essentially have a gas tank of energy when they start using your product, and every time you have them do something, it depletes that energy. Knowing this, you shouldn’t ask users to do stupid things that you could do for them.
One example Jen gives is choosing the type of credit card you pay with in a purchase flow. While it may not seem like a large effort to ask a user to select whether they are using Visa or Mastercard, it adds friction to the process of checking out. Not only that, the first four numbers of a credit card tell you which kind of card it is. There is no reason to deplete a user’s energy on information that you already know.
Be a Promiscuous Product Manager
Jen has made companies millions of dollars simply by using the Kennedy Principle and focusing on reducing friction in flows for users. While this is exciting, it is also not always the right solution. She points out the track record of Steve Selzer (formerly of AirBNB), who has made companies millions of dollars by adding friction to workflows. This doesn’t mean that either method is inherently right or wrong; it means that different situations call for different tactics.
This all comes together to highlight the value of being like the fox, and being promiscuous in the frameworks we add to our Rolodex. Don’t think that any one framework is the right solution for every problem. Play the field in the frameworks you choose, because in product, it turns out, monogamy might not be the best way!
