Inertia and Entropy

Alan Kay famously said “The best way to predict the future is to invent it”. Based on this, there’s no doubt that engineers are most capable of predicting the future. Product managers are arguably 2nd best given their close work in helping product teams align around the problems that describe the sorry state of affairs today, clarity around what needs to be done to invent the future, and then ensuring that the product is built & adopted successfully — ergo, future is realized.

However, unlike engineers who face technical roadblocks on their way to inventing the future, challenges that a product manager faces are different. Since I’m an engineer, I’m most comfortable describing these challenges as broadly falling in two categories – inertia and entropy.

Inertia

Sir Isaac Newton defined inertia as “a power of resisting by which every body endeavours to preserve its present state”. Product managers encounter this on a regular basis.

Inertia with users

The place where it most manifests itself is with people using products we build. People forms habits (Fun fact: habits are formed to reduce how frequently we need to exercise judgment. If we didn’t form habits, our brains would need to be much bigger, the size of which is already constrained by a woman’s pelvis given that the cranium of a newborn human is 25% developed compared to 45% for other mammals), and get used to a certain way of doing things to accomplish an end goal. Good product managers identify problems with the way things are done today, and build new products that create better ways of achieving the same outcome. Better ways can range from being less time consuming, being more transparent, offering greater agency to the user, or being way more fun and engaging.

However, just like the user doesn’t know what she wants, she won’t jump off the seat to start adopting something new (see Crossing The Chasm). Therefore, a good product manager’s job is to fight that inertia to drive product adoption. Without product adoption, there is no value creation. Even worse, without product adoption there is no feedback on the impediments to value creation. Inertia will not only kill your product, it won’t even give you a shot at trying to survive.

Inertia with stakeholders

The other deadly form of inertia is stakeholder inertia. Stakeholders here includes managers, investors, engineers, and designers. One of the most delightful (no, really) things about being a product manager is building consensus with stakeholders. Stakeholders are an important form of constraint put in place to guard against runaway & wasteful spending on building the wrong product. Since most products fail (majority of the startups with top tier VC backing are doomed), stakeholders maintain a healthy skepticism that the dollars or time they’ve just invested in your product are going down the drain. This is their defacto state of mind, unless a product manager convinces them that the product is yielding value to the user. The evidence for this ranges from engagement to change in certain objective outcomes (e.g. a customer is able to win more bids because of the product, but doesn’t necessarily have to spend more time using your product), to revenue ($ is the best surrogate for value).

To fight inertia, start small

There are many ways to think about product adoption, and stakeholder support — the most meaningful way to fight this is to start small. I feel clever when I label my approach to building products as recursive. In other words, keep breaking the product building & adoption problem down, till you can’t break it down anymore. And then execute the *product building – launching – adoption – feedback* cycle. The craft here is to identify a cohort of enthusiastic early adopters, enthusiastic stakeholders, & a meaningful problem for these early adopters. If you succeed at the smallest, go out to the next set of audience, and so on. This is how Facebook started, and this is how Amazon started, and this is how Uber started, and this is likely how *name your favorite unicorn* started. Are you facing inertia? Start by starting small.

Entropy

In thermodynamics, Entropy is defined as a measure of disorder. However, I think this (http://www.quora.com/Whats-an-intuitive-way-to-understand-entropy) quora thread does a better job of explaining entropy.

*Entropy is how much information you’re missing. For example, if you want to know where I live and I tell you it’s in the United States, that’s high entropy because the US is a large country. It would still take quite a bit of information to pin it down. If instead I said I live in zipcode 21218, the entropy is lower because you have more information. The more information you have, the less entropy.*

This notion is critically important for product managers.

Entropy with users

As a product manager, it is your goal to keep drilling & experimenting till you are satisfied that you have actionable insight. One of the mistakes product manager’s make is that they assume that they’ve understood the user’s problem (Evolution to blame again, with its pattern matching and biases because it doesn’t want to burn calories on decision making). Understanding, in very clear and specific terms, a user’s problem, and why it’s a problem is the foundation of a strong product. Good PMs will exercise user empathy and intuition about the problem, & will strive to find ways of validating their intuition.

On the flip side, after a product is built, a PM must be able to articulate very clearly the benefits of the product. Once again, entropy here will result in poor adoption, though I maintain that product adoption is primarily an outcome of inertia. That is to say, that if the market wants the product bad enough, it will suffer through your iterations & give you a chance to build the right product. The market will fight entropy for you, if its problem is real.

Entropy with stakeholders

With investors & managers, it is very important for the product manager to articulate the value the product will deliver to the business, and the user. Absent of this, every stakeholder will form their own notion of the expected value which sets the stage missed expectations and that’s a messy place to be (I’ve seen others end up there, I’ve been there).

Entropy in communication with engineers and designers results in missed opportunities to create a meaningful product, and leads to waste — & worse, running out of resources.

To fight entropy, ask questions & be specific

The best way to fight entropy when it comes to gathering insight and information, is to form hypothesis and then look for data to validate the most compelling hypothesis. A mistake PMs often make is that they look for data only when the hypothesis doesn’t pass their gut check. This can be fatal. PMs should always find data to corroborate the most obvious conclusions. With users, PMs should keep digging to learn of their problems till they can form a complete narrative of the problems without any assumptions. If there are assumptions, PMs should find a way to validate them.

Similarly, PMs should constantly ask all stakeholders what their expectations are, and if they understand why we are building a product, and how its success will be evaluated. At the same time, they should be very specific in communicating what needs to be built, and why. They should also articulate what is not in scope. In fact, a good heurestic is that the not list should be longer than the “in-scope” list.

tl;dr

Product managers need to think big, but start small to build great products. They should also strive to super specific in their communication.