Living the Startup Dream
Are you one of those founders living the dream... the wrong dream? All too often, founders fall for confirmation bias because we're always looking for signals to confirm our direction. It's natural. When you're driving somewhere with no network coverage, you look for highway or other signs to confirm you're on track towards your destination. Sometimes, you follow the wrong clues or get bad directions and end up in the wrong place.
It's understandable. You wear many hats, burn mid-night oil and face numerous daily challenges. You latch onto any glimmer of hope. A startup journey is a very long marathon with few if any cheering you on and handing you water. Left unchecked, that glimmer of confirmation hope can easily become fantasy; a dream completely detached from reality.
-
Falling in Love – It usually starts with falling in love with the solution not the problem. You unconsciously get emotionally attached to your solution. You selectively pay attention to signals that confirm staying the course. One more feature to add. One more bug to fix. All strongly demanded by a fantasy client ready to pay with Monopoly dollars.
-
Worthy of Greatness – The un-needed solution becomes your identity and you envision introducing it at a prime time event. You dread sharing your magnificent creation with potential users because it'a not ready. "My brand and reputation is on the line," you say. TechCrunch, WSJ and the NY Times must wait for perfection.
-
True to Vision – You confuse persistence with stubbornness. You sacrifice so much to design and build. You even win a patent or a partnership. Major validation for your generic AI-generated vision statement. Months pass and all you have is a patent or a partnership. No paying customers. No investors. Of course, you knew better than the potential customers you hardly know.
-
Filtering Out Negativity – You lock onto the subset of people who tell you what you want to hear. You interpret ambiguous experiment results in your favor. Taking time to seek and investigate negative or neutral results slows us down even if we're careening towards a cliff.
To combat this, we must hold ourselves accountable. Not the way founders and teams generate To Do lists and check them off. The learning has to extend beyond done/not done. Follow the discipline of setting and scoring a manageable set of Objectives and Key Results (OKRs):
-
Fall in Love with the Problem – Strive to be the authority on your chosen problem. Time and effort you invest in understanding the problem, it's root causes, and pain cost will point you to the best solution. In December 2016, the Navy was struggling to reduce risks of decompression sickness impacting Seals operating submersible delivery vehicles which required dangerous surface maneuvers. Initially, it was assumed that Seals had no way of monitoring their physiological limits when surfacing – the obvious and incorrect problem. After a thorough investigation, a team of Stanford students (AquaLink) realized the problem had to do with providing a GPS signal under water to avoid surfacing in the first place. In contrast, the TekDry team won a tech patent, a Staples distribution partnership and funding on Shark Tank then realized that no one needed to dry their cell phones.
-
Discover, Learn and be Humble – This goes beyond getting feedback and avoiding the negative parts. If you're solving a problem for someone, it stands to reason that you involve them. Doing so early and often provides regular input that keeps the solution on track and builds buy-in gradually leading to a higher likelihood of purchase. If you cannot engage your target user or beneficiary in trying your solution, this is a strong negative signal. Akshay Kothari and Ankit Gupta spent as much as 10 hours a day at a Palo Alto coffee shop to get user feedback while developing their news aggregation service Pulse. They sold it to LinkedIn in 2013.
-
Iterate, Test, Iterate, Test... Adopt the discipline of running experiments to attempt to prove your desired position and a position opposite of or adjacent to it. These experiments need to start quick and cheap. Jeff Hawkins, Palm Computing and Handspring founder, made a small wooden block with a printout of screen and keys glued to it. He pretended to use it to check his schedule and take notes. He was testing acceptance of this new form factor and input method. Tom Chi at Google ran similar low budget, low fidelity Google Glasses experiments.
When running many experiments, as you should, it's good to keep track of hypotheses and assumptions being tested in each iteration. Documenting OKRs diligently allows for learning that may take place later when patterns or insights emerge.