This essay was originally written for NHS4001: Critical Reflection (Old) | (nus.edu.sg), a reflection class at the end of university.

How do we build valuable products? That is a question I have always been interested in as an aspiring entrepreneur and software engineer. To me, valuable products are products that people use as the product solves a problem for them. Successful companies cash in on pain of the problem by providing the product in exchange for a monetary sum. In this essay, I analyze my experiences in trying to build valuable products and how I had to reexamine an approach I learned in class while working on a hackathon project.

To learn more about creating valuable products in university, I enrolled in NES Start (DBM1201BSP), a design-your-own-module by the NUS Entrepreneurship Society to actively work on creating valuable products. One of the modules’ readings by venture capitalist and founder of Y-Combinator, Paul Graham, tried to directly answer the question of creating valuable products (Graham, 2012). The following is an excerpt from the essay:

As the excerpt shows, Graham recommended aspiring entrepreneurs to “look for problems” and not think about “startup ideas” directly. Graham also advocated focusing on “personal problems” as it “ensures the problem really exists.” For Graham, the value of a solution depended on how critical the problem was. Graham’s advice was to first focus on defining the right problem and then work on a solution that can be monetized later. Therefore, Graham was a proponent of the problem-first approach – where we work on problems first and then the potential solutions. Indeed, Graham’s advice resonated with other credible case studies from the industry. For example, I knew how the founders of Airbnb started the company as they could not pay their rent. Brian Chesky, a co-founder of Airbnb, mentioned in his tweet (as seen in figure 2), “It began when my roommate Joe and I couldn’t pay our rent,” indicating that starting with their own problem helped them create a valuable product. He also said, “sometimes when you solve your own problem, you’re onto something bigger..” which clearly demonstrated the success of the problem-first approach.

With these credible sources advocating for the problem-first approach, I was convinced. I thus internalized the problem-first approach to apply it to every product-making opportunity that I had. However, my belief in the problem-first approach was challenged while working on a Hackathon.

I participated in the NUS Hack & Roll 2021 in a team of four, and our team eventually won the Top-8 prize. Instead of celebrating, I was surprised: I had voted against the idea of our winning product, Cruiser Cursor, in our internal team meetings as I didn’t think it was valuable. I did not believe it at first when one judge said it was “super useful” and that it made “a lot of sense” to him, as seen in the following chat screenshot. I even questioned the judge when he said it was “super useful” and asked if he had actually used our product before praising it.

Since I knew the judge personally, I confided in him I didn’t think our product was valuable and reflected on why I thought so.

Cruiser Cursor was a chrome extension that helped shorten the time a user had to move their mouse. When the idea for Cruiser Cursor was proposed by one of my teammates, it was hyped as something “cool” that we could build and how we could have fun building it instead of it solving a particular problem. As shown in the following video, Cruiser Cursor predicted the trajectory of a user’s mouse movement and helped a user click a button or link on a webpage even before the mouse had completely moved to the button or link.

As I use the trackpad, a form of mouse control, to effortlessly navigate the web, the value of Cruiser Cursor seemed limited at best. After talking about how cool the idea for Cruiser Cursor was, my teammate highlighted that Cruiser Cursor would shorten the time and effort for a user to navigate on the web. He also mentioned that this was crucial for users who prefer using the keyboard over their mouse to interact with the computer. These individuals mostly use a command-line interface (CLI), where they primarily interact with the computer by typing commands on their keyboards, as against a graphical-user interface (GUI), where a user uses their mouse (and keyboard) to interact with windows and buttons. While CLI users can get most of their jobs done using the command line, they have to revert to using the mouse when they browse the web because since each website is different in terms of the layout, it is challenging to map the keyboard commands to website buttons and functions. While my other two teammates seemed to appreciate the idea, I did not. I was not convinced because the problem-first approach was ingrained in me, and we did not seem to follow it when discussing the idea for Cruiser Cursor. Instead of focusing on and defining the problem first, we had directly addressed the product first. The explanation of the problem came after the product was discussed and hence seemed artificial or made-up to me – I did not believe Cruiser Cursor could solve the problem of web browsing. It appeared to me that the problem was just used as a made-up excuse to work on the “cool” product idea.

Ultimately, everyone in the team except me voted for Cruiser Cursor, so we built it and won the prize. This experience made me think critically about my understanding of Paul Graham’s advice. Was it necessary that valuable product ideas are thought of in a problem-first approach? This experience clearly demonstrated a counter-example to the problem-first approach. Perhaps, it may be possible to go the other way: think about the solution first and then think about the problems it could solve. An example of this approach also exists in the industry. DoorDash, a delivery platform, makes everyone, including their CEO and Software Engineers, do the job of delivery riders at least once they join to see the use-cases and applications more clearly. Thus, many employees, including the top management, tend to work and ideate on the product before knowing and facing the problem itself.

In conclusion, I learned how the problem-first approach, a step-by-step prescription of tasks, was not universally applicable. On a higher level, I realize the limitations of persisting with a prescribed, step-by-step approach such as the problem-first approach recommended by Graham. I realize that while a step-by-step prescription of doing step B after A is easy to understand and apply, it sets stringent constraints that may not always hold in practice. These constraints, when unmet, could derail the thought chain, which is what transpired when my teammate tried to convince me to build Cruiser Cursor. As a software engineer and a Computer Science student, this realization is crucial for me because while working with algorithms, it is easy to fall into this trap of thinking step A must come after B while it could be another way. Consequently, I am now more critically aware of the assumptions I am making while writing code and thinking about the order of tasks that I complete.

References

Graham, P. (2012, November). How to Get Startup Ideas. How to get startup ideas. Retrieved February 2, 2022, from http://paulgraham.com/startupideas.html