Building products is essentially about making predictions. No matter how many data points you have, you are always working off incomplete data and approximate, biased models of how the world works. And even if you are building to get data points, you are still making a prediction on what would give you the data, and more importantly, what data you need in the first place! All too often, that can be even harder than building the product itself.
As a result, you are always in a perpetual state of ambiguity. The more ambitious and more unconventional your product is, the more ambiguity is going to set in, and the harder the process is going to get. Consider this basic set of judgement/prediction pairs that our aspiring product guy needs to make (consciously or not):
- A judgement on how the world is today, and a prediction about where it is going.
- A judgement on what your capabilities are today, and a prediction that it can grow to fit your goals
- A judgement on what product is needed for a niche user base today, and a prediction that the same basic product will be needed by a much larger user base in the near future.
If you are building a networked product, the ambiguity is vastly compounded by the following:
- You do not have any direct control over your product, since your product is pretty much other people.
- You need your user base to organically grow into a far larger one, aka nailing the mythical, ever-changing viral loop.
- Adoption is based mainly on social trends, not technology trends. And social trends are often driven by emo teenagers and drunk college kids. ;)
Any of these, judged incorrectly, can derail the plans of the smartest people. Personally, I got plenty of the above right, only to brutally fail at a couple of them. And there went all my hard work. To make it worse, I was almost constantly color-blinded by my own promises, biases and ego, all of which makes us the worst judges of ourselves. And I know i am not alone. It is little wonder that we are constantly walking around with our heads in the clouds.
Since ambiguity is a key part of the problem we are trying to solve, you would think that we would have a good mechanism for handling it. But not really. Like how we approach most elephants in the room, we try to ignore it or kill it.
First off, we ignore ambiguity whenever we set assertive goals that have no basis on reality. This is a standard fixture in most investor, board and team meetings. Goal setting works when you have past basis and some amount of future stability. But when you are dealing new products, assertive goals do not help. They hurt because you are forced to make premature decisions about what metrics are important. We are blindsided into trying to uphold promises made (with little data points and a lot of hubris) rather than focusing on updating our mental models based on new data points.
Conversely, we try too hard to kill ambiguity when we believe that we can find out all we need with enough customer feedback, A/B testing, experimenting on features without really taking a big swing at something. These work best in building small optimizations or incrementally better products. But trying to apply them on new products drain all sense of excitment, drawfing the problem into a scale where no one gets excited anymore, let alone talented people or investors.
So why do every single startup or product team do both of above 2 things? In some sense, it is inevitable. There is an intractable need to both maintain a certain amount of delusion while constantly seeking out the truth. Delusion and truth are strange but necessary bed fellows. Without delusion that the current direction is going to work, it is impossible to burn 18 hour days while staying focused on building something kickass. Without constant calibration with datapoints, everything will crash, and in a very bad way.
So there is no contradiction. But what we are missing is a mindset that puts ambiguity front and center. One that makes sharing uncertainties and fear a strength, not a weakness. Many of our current approaches to goals setting, measurements and instrumenting stem from practices that worked for proven products with consolidated markets, not building new products in unproven markets. Our current lexicology in the latter consists of “be focused”, “move fast”, or be “user centric”, each of which needs serious context and beefing up.
As human beings, we abhor ambiguity and love books that tell us exactly what to do or what process to follow. We love reading about how company and products win and try to replicate it. We scrutinize interviews with successful builders for clues on why they are successful. We buy books like “Viral loop”, “Hooked”, “Rework” which promises us exactly that. We use arguments in startup meetings that are similar to “But Twitter had APIs… or Facebook started in colleges…” — as if executing based on the strategies of others is how these very examples succeeded in the first place.
Probably the most damning is when I talk to fellow startuppers, the number one question that always want to know is what others did to succeed. But that completely neglects the reality on the ground, which is that they were probably as confused as anyone else before their shit took off.
They just navigated it better than the rest of us, including yours truly. And that is what we should be learning — how they navigated ambiguity, not live in the myth that they never had it.
