As Greek philosopher Heraclitus opined, “you can never step into the same river twice.” This post is an ode to time—the true source from which learning derives.
As a product manager, a significant portion of my role is fostering decisions. This comes in many forms but my personal maxim is to minimize the number of decision’s I make at any point in time.
Minimize the number of decisions made at any one point in time.
It’s important to visit the assumptions that would drive a maxim such as this, so here are mine:
- The right answer reveals itself with time
- Distributed decisions win in the long run
- We will be smarter tomorrow than we are today
Independently, these are easy maxims to nod your head to. In practice, it’s incredibly difficult to organize a team and keep a team organized around these principles.
In a product organization, you’re seemingly forced to make decisions every day so it’s important to reflect on how I’ve turned this into action.
- Develop empathy for the problem space. Really understand it, listen to the domain as if it’s a full body experience. What assumptions does the industry have to believe for the industry to be where it is? Where is it wrong?
- Don’t pay above market value for knowledge. Should you ship a chainsaw without a safety throttle? No. Some knowledge is already in the world. Don’t ship a product to learn a lesson that’s available in a $30 book or a $10 research paper. But there are two issues with relying on empirical knowledge, the first is a tendency to treat all empirical data as knowledge. When much of it is information, or worse anti-knowledge—information confused for knowledge that actually makes it harder to achieve knowledge. The second is a priori knowledge is the most powerful skill you can harness, can you grow a multi-billion dollar paintball business with one location? Is the probability of this business more or less probable than Bigfoot? Examining ideas through inquiry is a powerful way to improve your first idea over time.
- Go with your first idea. When all information is equal and in absence of validation, your first idea is just as valid as all others, go with it. Save the time debating whether or not it’s the best idea (because it isn’t) and spend it increasing the probability of success and time to market of the first idea. This will free you up for your next first idea. This is effectively a greedy heuristic for decision making. Over time: a good enough decision fast bests a better decision slow.
- Reduce the cost of change. On a software project, we tend to think about the cost of change in terms of how much code needs to be thrown away, but cost also includes entering partnerships that are difficult to get into and hard to get out of, services that are quick to stand up but are difficult to throw away. Finally, change is often hardest for people. Ship the idea that is easiest to walk back socially, which often means ship the idea that is the least right politically. There are some ideas that can’t be walked back politically–as in if it fails no one will have the heart to walk it back. Ship those last.
- Optimize for adaptability, not predictability. As a product development org you want a highly adaptable team in most parts of your system. Since you don’t know where your perspective will take you–it’s important that everyone understands the conscious trade-off between an adaptable system and a predictable one.
- Try to live with your product for as long as possible. Do this by shipping it as early as possible, not by shipping it later so you can use it longer. Does it become something that you can’t live without? Do you become disinterested with the product over time?
Note: Last year I wrote on a related topic: Your Codebase is The Best Prototype
In practice the software project unfolds like a sketch artist, making hundreds of noncommittal strokes to the page. No one stroke is “right” but taken together, a clear form begins to emerge.
While there are artists who can create this in one go, with bold lines drawn at the outset, I’m not one of them and probabilities are that you aren’t either.
While looking at this you could easily focus in on the small deliberate strokes, but what’s more important is the time between each stroke. With each stroke you gain new information, feedback about how the bigger picture is unfolding even if others can’t see it yet. If you blindly placed each individual stroke without regard to how the others that proceeded it turned out you’d have a very different picture.
While we’re all familiar with the principal that knowledge is in the world, it’s important to reflect further on how much of that knowledge is only possible through the dimension of time.
Time is information.
Reflections
- Time is information. Much of our job comes from identifying waves that are high growth. Growth, like acceleration, requires a function of time.
- Time is information. The current project state tells you one thing, the same project state for a year tells you another.
- Time is information. If you live with an idea for a day and are excited and live with it for a year and are still excited these are materially different feelings.
- Time is information. How you use something changes materially with time, strong behaviors become stronger weak behaviors are replaced.
- Time is information. You have 200K customers. Hooray! 30 days ago you had 1M customers. Oof.
about the author
Mikal is a reformed startup CEO and experienced Product Executive based in Austin, TX. After years leading product teams at Microsoft, Nordstrom and most recently VP of Product at RetailMeNot, he now serves as a product coach helping teams in growing tech markets work their way up The Product Team Ladder.
subscribe (it’s free)
I’ve been writing business notes since 2005 (as notsocommoncents) – join my newsletter, sent every Tuesday, to read notes for the week on topics that go beyond the daily news cycle, plus any new blog posts.
You should sign up – and hear about an awesome thing each week.