A Missing Link in Start-Up Ideas: "Insights"
Over the past couple months that I’ve been on Hacker News, one thing has consistently bugged me about the way we think up ideas, especially whenever I come across someone’s latest start-up ideas.

The process of idea-generating usually starts out along the line of “think about a problem that you wish could be solved” and/or “build something people want” (aka think about a problem that THEY wish could be solved). Then think of how to solve the problem and, if you thought of one, there’s your potential idea right there! Pretty obvious right?

Except, I always feel like we’re overlooking something important between the problem-finding stage and the idea-finding stage. It’s almost on the same level of having a bad execution of an idea, or rather, you could almost say that it IS responsible for leading to many bad executions of ideas.

Specifically, I think what we’re missing is the insight-stage. By “insight”, I’m referring to your understanding and selected assumptions about the true nature of the problem. Everyone will have assumptions about the true nature of a problem, whether they’re aware of it or not. When you DO insightfully think about the problem from different perspectives (each of which comes with new sets of assumptions about the nature of the problem), it should hopefully lead you to good ideas that addresses the problem much better than if you didn’t do so.

Now, when you DON’T insightfully think about the assumptions underlying the problem, I’m guessing that you would probably unconsciously adopt the assumptions underlying how the problem is currently being solved. In other words, you’re probably adopting the underlying assumptions of a solution that wasn’t good enough to solve the problem if it’s still a problem. When there’s enough people adopting the same assumptions about a problem, regardless of how different their ideas and features may be on the surface, they may all end up trying to solve the problem in the same way.

If anyone’s curious, what drove me to write this post was because of my experiences with searching for a personal productivity app for my sister and I (ie. getting you to exercise, stop procrastinating on your need-to-dos, creating good habits, achieving goals, etc). Most of the apps were about tracking, surveilling and/or reminding you, which is probably useful for some people and some situations, but not for people truly struggling with self-discipline and not for most activities that you have low motivation or ability for (ie. getting yourself to exercise regularly if you haven’t done so since high school P.E.).

But the real problem came when most of these apps (and subsequent newer apps) kept the underlying assumptions that the problem is technical, which simply led to more ideas of how to more efficiently track/remind/surveil/organize your activities when, if you don’t mind my bias here (I come from a psychology background), I felt they were missing half the problem, the very important psychological half that influences people’s motivation and perseverance. I can understand that it’s not the developers’ fault that they’re not behavioral psychologists, but still, I couldn’t help but notice that most people-problems out there tends to be solved from a technical point of view because, obviously, the only people who could build apps are technical people. I think there are potential to discover hidden but amazing insights simply from combining perspectives of different disciplines. (At least, for my personal interest, it'd be interesting to see what come out of programmers reading up on behavioral psychology or psychologists jumping into programming.)

If there’s any takeaway point here, it would hopefully bring with it greater awareness of one’s underlying assumptions about a problem when thinking up ideas, which would hopefully lead to better execution of products.

(Eventually, I became frustrated enough that I’m currently learning programming so I could build a personal productivity app based on my own set of assumptions about the true nature of the problem...well, we’ll see how that turn out...)