I was having a conversation today with a friend of mine who is building a new product called Bubblr, for which I’m assisting in the design. Bubblr is an app that allows you to share and discover songs on a map, in the form of bubbles. We were discussing potential use cases of the product as well as the possible directions to take it.
He stated that when he first started working on Bubblr, he just wanted to build a “cool” product. He said at this point, he had done that. There was no user base, but regardless, he seemed content at simply having built it. He added that if it failed, he’d be ok with that, because he did what he set out to do. I inquired further, “How do you know when it has failed?”.
I biked home and began thinking more about that question. How do you know when a product has failed? Or how do you know when to stop pursing a product. If this question were easily answerable, countless years of energy could be saved and redirected on other efforts, especially given the saying that 9 in 10 startups fail. Unfortunately, it isn’t.
A product can fail at many steps of a company. For this article, I’m going to look at one of the earliest point, as it is most common. Before significant traction is gained, after you know who your ideal user is (finding your ideal user is a whole nother article). Plenty of startups will form, they will develop, iterate, test, etc. Each one has a hypothesis; that whatever product they are creating, there is a need for that product.
Then the question becomes, “How can I prove of disprove this hypothesis?”. In many cases, the energy is heavily weighted towards proving as opposed to disproving (for obvious reasons). In the example of my friends company Bubblr, the hypothesis is, users will find value in a product that allows them to interact and listen to music displayed on a map. Not only that, but they will find enough value in it that they will return, and continue returning.
You could then break this out into a subset of other hypotheses. What is necessary for that value to be found? We could propose that there must be a sufficient amount of bubbles (songs) placed on the map that are relevant to their tastes in music. Then even further, what is necessary to build in order for that step to be attained. Maybe that means implementing an onboarding flow that allows users to define their preferences. Or possibly some sort of algorithm to learn the tastes and adapt appropriately. Often there are ways to fake this, or at least reduce the amount of steps involved to achieve this insight. For example, Reddit using bots to comment and up/downvote threads. They assumed (correctly), that in order for a forum to grow, there must be perceived activity with inside of the forum.
I was watching a lecture on Youtube given by Reid Hoffman (founder of LinkedIn, Product Genius, etc…) and he spoke on a similar subject. He mentioned two questions worth asking yourself in the formative stages of a product. Firstly, what is necessary for your product to break through? Essentially, what hypothesis do you have that will require the value of the product to be acquired. This could be related to product itself, technology evolution or even distribution. Secondly, what is the least amount of work that can be done/quickest route to testing these hypotheses?
Once you have these hypothesis defined, its a matter of prioritization, implementation, and rapid learning. According to Hoffman, assuming the priority of multiple requirements are equal, the “stickiest” should be tackled first. This seems logical, as the sooner you can prove out a dead-end, the quicker you are able to adapt and refocus those efforts. The stopping point (knowing when to stop) comes when you learn that whatever requirement is necessary for your product to succeed, is highly unlikely to achieve.
The answer will most likely in the form of yes or no. But it’s hopefully sufficient that you can reroute accordingly. You learn that either this path is unlikely to work out, or it isn’t. The sooner you can get to this inflection point, the quicker you can learn and adjust. Whether that means scraping everything and starting over, pivoting in a slightly different direction, or continuing forward with the original vision.
I’m fairly certain one of the key differences between a good decision maker and a great one is their their ability to decide from the culmination of this newly found data. Data can guide this decision, but ultimately it’s intuition that will make the final decision, as the data/research won’t be binary. The hardest part is being true to those learnings. To not let confirmation biases or dreams of success impede the best path forward.
I like transposing these thoughts to the metaphor of chasing a rainbow (For this metaphor, lets assume some rainbows (1 in 10) you can get to the base of.) It can be tempting to continue forward on a route that seems subjectively fruitful. Each step you take, you seemingly get closer to the destination in mind. Product success. Millions of dollars. Whatever that may be. You invest more of your energy to that goal and it becomes increasingly hard to turn away. But that route is not always the best route. Stepping back, asking yourself these hypothesis, and being realistic with the results that are learned is crucial to truly seeing your distance from your end goal, and what direction you must take to get there.