For most of us technologists, figuring out user need is way way harder than doing research or building something. That's the reality. So we tend to take comfort in building technology and figuring out the user need later on.
Even discovering a real problem, a problem that warrants the expense on technology, is unfortunately out of the comfort zone for a lot of technologists. We often assume that the problem is real, or worse hope that the problem be real and jump into solving it right away because that's our comfort zone, building stuff.
There ain't nothing wrong with this attitude or process. In most cases, where technologists have solved real problems, the real problem has been a serendipitous unraveling during the build-iterate-shut process. So the best shot at figuring out a real problem for technologists is not spending time in problem discovery, but in a better ship-iterate-shut cycle. A cycle, in which in one can look at current usage and postulate the future and take rapid decisions on what to build, or what not to build.
Having read the biographies of many tech leaders, I have come to the understanding that the key skill that has set them apart is that exponential growth in their ability to hone the intuition about future demand, in a very short span of time, starting from a barebones MVP.
Gotta burn the candle at both ends a bit to make it big. Spend some time off in the far vistas of emerging tech - some just looking at how ordinary people live their lives, and thinking about how to improve that.
Building is a very expensive way of finding user needs, especially since you might rely on luck to start out even in the right ballpark.
I think of innovative products as the combination of a user need insight and an innovative solution. I think there’s a lot of time wasted when teams focus too much on iterating on one without the other.
If you’re a technologist who sees the potential in a particular technology, you need to start by thinking about how to navigate towards applying it to a real user need. The flipside happens too, where a team sees a need and gets stuck in circles because they lack the tech expertise to build a solution that delivers & is competitive (but surely less commonly in the HN crowd).
Someone good at one of these things but less interested in the other should find a co-founder who’s good at the other perspective.
Even discovering a real problem, a problem that warrants the expense on technology, is unfortunately out of the comfort zone for a lot of technologists. We often assume that the problem is real, or worse hope that the problem be real and jump into solving it right away because that's our comfort zone, building stuff.
There ain't nothing wrong with this attitude or process. In most cases, where technologists have solved real problems, the real problem has been a serendipitous unraveling during the build-iterate-shut process. So the best shot at figuring out a real problem for technologists is not spending time in problem discovery, but in a better ship-iterate-shut cycle. A cycle, in which in one can look at current usage and postulate the future and take rapid decisions on what to build, or what not to build.
Having read the biographies of many tech leaders, I have come to the understanding that the key skill that has set them apart is that exponential growth in their ability to hone the intuition about future demand, in a very short span of time, starting from a barebones MVP.