2023 was marked by numerous experiences of building products from the ground up. Reflecting on the past year, I want to share our journey along with the products we developed. I wrote the Korean version first, which you can read here.
The story begins in the summer of 2022. After two years at Riiid and an internship at Google, I found myself deeply missing the thrill of going from 0 to 1. Building Everest, my first “startup,” 4 years ago, I realized the joy of developing services people love. With my military service (mandatory for Korean citizens) completed, I was finally ready to pour my heart and soul into creating a product I could be proud of.
In August 2022, I returned to UC Berkeley, as I wanted to build in the Bay Area. For the next 1.5 years, our team validated 20 ideas and built 8 products. At the same time, I was cramming college courses to graduate in 3 years. This article is my retrospect of 2023, with 8 products that we launched.1
Idea 1. Chrome extension that organizes what you learned during complex search journeys
Period: August 2022 ~ January 2023
Background
Will Smith smacked Chris Rock during the Academy Awards ceremony in Spring 2022. I remember learning about the incident after reading a post about it on Facebook. Shocked, I quickly searched for a full video on YouTube. Then, I read articles on Google to learn more about people's opinions. A few days later, I read an article on LinkedIn stating that the East and West think differently about the incident, which prompted me to read some Korean articles on Naver (Google of Korea).
This whole thing made me realize something: while each platform has its own slick recommendation system, there's nothing out there that connects the dots across them all.
Imagine if our browsers could actually keep track of all the bits and pieces we learn about a topic and suggest even more cool stuff. We can't just start recommending things out of the blue, so why not have the browser help sort and manage all this knowledge we pick up from different places to start? This was the beginning of my first idea.
v1 Hypothesis
We defined the process where a user visits dozens of tabs and collects information for a specific purpose (e.g. learning about a new topic, researching for an article, etc.) as a complex search journey.
In general, when people conduct a complex search, they either split their screen to paste content from different pages or simply keep dozens of tabs open for research.
We observed that the information obtained from a complex search tends to have a hierarchy, but such hierarchy isn't reflected in the browser's UI or note-taking apps. We hypothesized that if we could visualize the pages visited during a complex search journey in a tree-like structure, it would provide value to the users.
Progress
Having no prior experience in developing Chrome extensions (I mostly focused on AI/Backend/Mobile in my career), I was not familiar with the usual web frameworks. Despite this, I learned on the go and quickly created a basic but functional product. I then conducted a private beta test with about 20 people for approximately 10 days.
Learnings
Observing actual user patterns revealed that even web surfing that requires more than one tab often didn't necessitate a tree structure as much as we thought. In fact, if the tree has fewer than 5 nodes, we concluded that the value provided by the tree structure isn't meaningfully different from simple bookmarks. For those who frequently engage in complex searches, the extension was inconvenient, as they couldn’t leave a memo about the page in our UI.
Additionally, we concluded that the scope of the problem we were targeting was too broad. It might have been more appropriate to first validate our solution in the most specific and complex search cases and then adapt the UI/UX for a broader audience as we progressed. Starting with a general case made it difficult to discern whether we were effectively addressing the problem or if it was a problem at all.
v2 Hypothesis
Based on the learnings from these experiments, we started to formulate the hypothesis for the second version. From this point, we began to diagram complex searches2 and clearly define our users.
User Persona 1: Journalists who need to quickly learn about topics outside their expertise to write articles on specific subjects.
User Persona 2: Analysts who need to conduct in-depth research on specific industries.
User Persona 3: Undergraduate and graduate students who frequently need to write research-based essays.
v2 Progress
The most significant change in version 2 was the question/topic-based UI.
The reason for opening the first tab is because there's a curiosity or question that the user wants to solve.
The reason for opening the N+1-th tab from N tabs is because there are still unanswered questions or curiosities.
Therefore, the reason for opening each tab can be expressed in the form of a question.
Instead of managing the carelessly opened tabs, how about managing the 'question' that motivated each tab to open? As long as this hypothesis holds, we thought that managing the 'motive' of the action rather than the 'result' of the action would be more intuitive.
Having a UI that can record the series of questions has the following additional benefits:
One can search more consciously and be clearly aware of what they have learned.
Hyper-correction effect: Even deriving a wrong answer can make the correct answer more memorable when learned later.
When one wants to continue reading without leaving the visited page, they can easily leave a question behind and focus on acquiring information.
If Copilot is added later, answers to these questions will be included as one reads through the article.
This led to the creation of the product shown in the demo video. With this, I met dozens of journalists, analysts, and college students.
It was exactly one winter ago. During winter break, I started visiting various newspapers in Korea, braving the bitter cold winds. Fortunately, most of the people were willing to listen and even provided their contact information. However, the deeper I discussed with journalists, the more I realized that this market wasn't the right fit.
Firstly, I was too distant from the users. I had no journalist friends in my network, making it difficult to secure distribution and have domain knowledge. Many journalists in Korea were still using Microsoft Word, not even Google Docs, so I had to develop a Word extension. Moreover, the concept of a SaaS subscription was very unfamiliar to Korean newspapers, making them quite uncomfortable with the idea of paying $10 per journalist per month for the service.
As I continued interviewing, I increasingly realized that unless the product was specifically tailored for journalists, it wouldn't properly solve their problem. The same was true for analysts. This realization led our team to pivot. We decided instead to develop a product in an area where we had prior experience in our professional lives.
Learnings
Two journalists subscribed to the private beta version at $10/month, but they didn't use the product much. Ultimately, we learned that having our own distribution channels makes everything a hundred times easier if we aim to go vertical.
Idea 2. A tool that creates study notes based on the content researched on the web by knowledge workers
Period: February ~ March 2023
Background
Another insight we gained while developing v1 and v2 was that in order to manage and recommend the user's knowledge at the browser level, we needed to create a new browser, not just a Chrome extension. It was too complicated and restrictive to get the metadata we needed on Chrome.
Looking at the Arc browser, which was popular in the United States at the time, we realized that a browser developed by a startup could also become mainstream if its product quality was excellent. So, for about two weeks, we tried to design a browser that could manage the knowledge obtained from organizing tabs according to user intentions. But in the end, we decided not to develop it. The Arc browser was already filling the gaps in Chrome well, and our experiences had taught us that creating a 'pain killer' for a niche group of users is much more effective than creating a 'vitamin' for many people, so we had doubts about whether the new browser we created could be a 'pain killer'.
Therefore, based on the lessons learned about the distribution channel from v2, we decided to focus on college and graduate students, for whom we have optimal distribution.
Hypothesis
If note-taking can be done just by highlighting while doing a web search, students would be willing to pay $10 a month to use the service.
Progress
As shown in the demo video below, the service organizes the information learned online into a Notion page as if it were notes you wrote yourself.
We launched and conducted a private beta for about 20 people with this product.
Learnings
The main reaction from people was something like “it’s… interesting.” However, when our target audience (college and graduate students) needed to research a topic that required note-taking, they did not feel a significant pain point in taking notes by switching between windows. On the other hand, for topics that didn't necessarily need organization but would be nice if they were organized, the willingness to pay was very low.
Even if we go vertical, if it's a market with low willingness to pay, it's hard to grow. Going vertical and reducing the Total Addressable Market (TAM) reminded us once again that there must be a high willingness to pay to compensate for this.
It sounds like an obvious realization when written down like this; but up to Idea 2, we were making a product to solve the problem we personally wanted to solve. We never tried to make a product while thinking about its market potential, even though our goal was to create a venture-scalable startup.
Idea 3. AI Meeting Notes with Zoom Integration
Period: April - June 2023
Background
Through Idea 2, our team always had at least one member working in Korea, so we had to get on a Zoom call every time we had a meeting. It was my job to takes meeting notes, but writing meeting notes was so cumbersome that we made a small tool that uses the OpenAI API to write meeting notes for us. The performance was surprisingly good, so we started using our tool for our ongoing meetings. At this point, we started to think about selling it, which led us to Idea 3.
Hypothesis
If AI automatically generates meeting minutes in the desired format, companies will purchase and use our product.
Progress
Having learned our lesson from the previous two ideas, this time we thought about selling, not just making, from the start. I contacted a startup who I already had a connection with and proceeded with a discovery call. During the discovery call, the co-founder of the startup was not interested in our service. They were already paying a significant amount to Gong, which also generated meeting summaries.
After the call, I showed him the meeting notes generated by our technology, and he was so surprised at the quality that he immediately decided to purchase it (the meeting notes were the output of a Python script that took us only a few hours to create).
So our team signed a letter of intent stating that the startup would pay X dollars per month as soon as the product was developed, and we started product development with a customer in line.
The product works as follows. Through the Zapier and Zoom integrations, as soon as the Zoom call ends, it outputs meeting notes directly into the company's knowledge base (e.g., Notion). In addition, a Zoom bot joins the Zoom call and provides real-time transcription and translation services.
After the launch, three startups paid a monthly subscription fee to use our product ($500 MRR).
Learnings
Compared to other meeting note creation products, the most significant difference of our product was that the customer could receive meeting notes with whatever format they wanted. For example, if a customer provides a template for a sales call, we generate meeting minutes according to that template. However, we had not yet found a way to provide this in a scalable way, and it was a simple feature-based difference, so we could not find a clear reason why we would beat our competitors.
Also, the type of meeting where our service was mainly used varied from company to company. Even though we started this idea from problems we faced during internal meetings, customers who used our solution for their internal meetings had the lowest satisfaction. Surprisingly, the meeting type with the highest satisfaction was sales. Unlike sales calls and user interviews, meeting notes for internal meetings were rarely looked at after the meeting ends. If employees were curious about the content of the meeting, they could always just ask the person next to them. Even if they wrote notes in fear of losing context, they rarely looked at those notes in the near future, making it hard to clearly convey the value of the notes.
Meeting summarization for sales calls was already a red ocean and not an area we were passionate about, so we tried to find insights from internal meetings. We thought the greatest value-add in internal meetings was eliminating unnecessary meetings or shortening meeting times. However, Loom, Rewatch, and others were already solving this with asynchronous meetings.
Another solution we thought of was a tool that resurfaces the relevant context when it comes up during a meeting. However, this too seemed like an idea that an incumbent who already has a meeting platform could do much better.
The only way we could’ve avoided pivoting was to dig deeper into the use cases in sales calls to focus on workflow automation that fits JTBD (Jobs To Be Done). However, we decided to pivot because we thought that the founder market fit was not good.
Summer 2023
The semester ended after we finished the development of Idea 3. Until then, I had been developing while attending school, but finally, I was able to devote all my time to Pensieve. Since 7th grade, I’ve always dreamed of starting a company Pied Pier style: friends crammed in a living room, working all day. I will always remember the summer of 2023 as the time my dream finally came true.
On the wall, we made a huge Scrum board, imitating the Scrum board of Jared from the TV show Silicon Valley, one of my favorite shows.
During summer break, we tried to validate a lot more ideas that are not mentioned here. For instance, we went to the SF Market (wholesale produce market of San Francisco) at dawn to study the food supply chain, and ordered a large amount of dumplings, which was the cheapest food item in SF Chinatown, to check food prices when envisioning a new food delivery system.
After venturing around for a short period of time, we decided to proceed with Idea 4.
Idea 4. Real-time translation tool for university lectures
Period: July 2023
Background
We thought about creating a translation tool for a specific use case since we were already developing real-time translation tools while creating the meeting notes service. Many technical courses in Korean universities are taught in English, so native Koreans often have trouble understanding lectures. According to Korean students that we interviewed, they would pay about $30 a month if the content of English-taught university lectures could be translated and summarized in real-time. So, we decided to develop the product.
Hypothesis
If translations and summaries of English university lectures are provided in real-time, undergraduate students taking English-taught major courses at Korean universities would pay $30 a month to use our service.
Progress
We developed it quickly in just a week, but ultimately did not launch it to the public.
Learnings
This idea is the only one where we think we didn't learn anything. We should have launched if we developed it, but after creating the MVP, the product was too lackluster. Our real-time interpretation was quite fast, but as for quality, it was clear that it would take a long development period to properly transcribe and translate high-level university lectures. Moreover, both my co-founder and I studied at Berkeley and were distant from the target user, Korean engineering college students. So we decided to axe this project.
However, there was an occasion when we found this product unexpectedly useful, which will be mentioned later in this article.
Idea 5. Tool that replaces admin panel with AI
Period: July ~ August 2023
Background
Although we mostly built products during summer vacation, we also attended a few AI events happening in the Bay. One of them was Stripe AI Day, held in July at Stripe's headquarters.
Stripe did a demo of how to automate tedious processes using an agent. At the time, my co-founder was constantly being called to resolve admin panel issues for a startup where he had already resigned. It led to discussions on the idea, "What if we automate this with an agent instead of me doing it?"
Hypothesis
Instead of a tool that lets people easily create admin panels (like Retool), what if we give an AI Agent access to the company’s database and API endpoints (under human oversight with appropriate authority) and let non-technical users execute admin tasks via a chat interface? In that case, the company wouldn't need to develop an admin panel, and they would pay to use our service instead.
As shown in the demo video below, the agent handles admin panel tasks like, "return all the payments made by users on July 7th as store credit."
Progress
Before developing this idea, we made a demo video and signed an LOI after finding a company willing to pay $500/month. We started development once we had a customer, and until the development was complete, we manually handled the admin panel issues on their behalf.
Learnings
In actual tests, 90% of the chat messages sent by the startup's PM were queries about data analysis, not administrative tasks. The frequency of admin queries was much less than we thought.
Also, we discovered that the admin panel follows the 80:20 rule. 20% of the features of the admin panel are used 80% of the time, and the remaining 80% of the features are not even used 20% of the time. And those 20% of features were something that a developer could develop in just an hour. So, we pivoted yet again.
Idea 6. AI Property Manager
Period: August ~ September 2023
Background
My co-founder and I had experienced several weeks of back-and-forth communication with our apartment’s property management (PM) company due to parking issues and broken blinds respectively. In this process, we learned that resolving a single property management issue can require multiple rounds of communication.
For example, for the broken blinds, we contacted the property manager and then the property manager found an available handyman nearby. Then, we scheduled a time for the handyman to visit via the property manager. After the handyman came, he had to measure the size of the blinds. Then, the PM had to place an order with the blinds manufacturer with the measurement. Then, we had to schedule another appointment with a handyman, several weeks later. Only after that, we were able to get new blinds.
Due to the back-and-forth communication required, a typical property manager can only manage ~30 properties at a time, receiving 3~10% of the rent from each property as compensation. As the compensation is quite substantial, the property management (PM) market is huge, exceeding $40 billion in the United States alone.
Hypothesis
Our idea was simple. Could we automate the PM communication process and the process of finding the right person to resolve PM issues with an AI agent, allowing them to manage not 30, but 300 properties at once?
We thought that if we could automate the communication process and the process of finding contractors with AI, we could create a service that benefits both tenants and PMs.
Progress
The biggest problem was that we didn't know much about the PM market. Therefore, this idea underwent the most rigorous hypothesis verification process out of all the ideas we had pursued so far. We created a separate hypothesis sheet, listed the hypotheses with the highest risk first, and verified each one directly. It took three weeks just to verify our hypotheses, during which we also went on a business trip to Irvine, California, braving a storm.
Just a few days before the start of the school semester, we heard that several acquaintances of my co-founder's mom were working as Property Managers. We decided to go on a trip before the start of the semester to meet these people. However, coincidentally, we saw news that a hurricane was heading to Irvine for the first time in 84 years, just as we were planning to visit. We couldn't get flight tickets as flights were cancelled. Since it would be difficult to go once the semester started, we decided to take the risk and drive over 400 miles from Berkeley to Irvine.
Looking back, I don't know how we managed to go. As seen in the video, as we drove further down, we were hit by heavy rain.
Fortunately, we arrived in Irvine faster than the hurricane and met with property managers as soon as the hurricane passed. The real-time translator (Idea 4) we previously made was used here, as all the property managers we met were immigrants from China and the meetings were conducted in Chinese. My Chinese-American co-founder conducted the meetings, and I understood the flow of the conversations while looking at the real-time translator we made.
As the final step of hypothesis validation, we wanted to get experience on PM issues by becoming Assistant Property Managers ourselves.
As shown in the image above, when a problem arises in a house managed by a property manager, they contacted us, and we looked into how to automate it with AI while we resolved the issue ourselves.
Learnings
We learned that a few PM startups were already solving the problem we want to solve with overseas workers in India, the Philippines, etc. Surprisingly, there was no significant cost difference between automating using AI and automating through these overseas workers.
Companies like Marble have already introduced AI and are innovating the PM market. We ended up dropping this idea when we learned that these companies are not growing quickly even though they offer a price similar to the pricing point we were thinking of.
Idea 7. Google Slides for Teachers
Period: October 2023
Background
I really like the YouTube channel 3Blue1Brown. It is a channel that explains difficult STEM concepts in an intuitive way through high-quality animations and visualizations. Seeing the recent advancements of gen AI, I wondered if we could use LLMs to allow anyone to make visualizations like 3Blue1Brown.
And if this were possible, the first targets we wanted to give this technology to were STEM professors who regularly prepare and deliver lectures. Many STEM professors at UC Berkeley shared their iPad screens during lectures, writing formulas on their iPads. Sometimes the readability was poor because the handwriting was not as neat as LaTeX formulas; there were limitations to the lecture speed; and most importantly, they had to draw pictures or bring in pre-made images when the visualization of a concept was needed.
Hypothesis
It would be possible to create animations like 3Blue1Brown by entering simple diagrams and prompts as input using LLMs.
If we make Google Slides for STEM teachers, the school would purchase it.
Progress
3Blue1Brown creates videos using an animation engine called manim that he developed himself. Therefore, for a few days, I built a simple toy project to generate manim code with an LLM, and after seeing that it produced fairly high quality animations, I validated hypothesis 1.
To quickly verify hypothesis 2, we made a demo video as if such a product existed without developing anything.
Then we went to meet 20 professors of mathematics/physics at Berkeley.
Learnings
First, we asked the professors how they prepare and conduct their lectures, and then we asked the following two questions.
Whether the professors would think about pre-ordering at $50 even before the product is developed
After the launch, whether they would be willing to personally pay $50/month/course
However, even the most passionate professor about our product found number 1 difficult and number 2 too expensive.
We thought that the market size would be too small if we charge each professor individually or if the school pays for the software that the professor uses. Eventually, we thought that we should make a product that could be purchased on a per-student basis.
Idea 8. ?
Period: October 2023 ~ Present
The eighth idea is the one we are currently working on. Since the current ongoing idea has not yet been finalized, I won’t spoil too much of it.
Using insights gained from previous ideas, we are continuing to develop in the education domain, and we are earning $2K+ MRR.
Discarding good ideas in search of great ones
Among the companies that went public in 2023, many would pick Instacart as the one that received the most attention in the tech industry. Apoorva Mehta, the founder of Instacart, created more than 20 products before Instacart, many being totally unrelated ideas to the grocery delivery market.
If I were to define the past year, I would describe it as “discarding good ideas in search of great ones.” To be honest, the ideas we decided to move on from weren’t bad ideas. I believe a couple of those ideas could be developed into products generating over a $1M in annual revenue if pursued with dedication. However, we abandoned certain ideas because they were not great enough.
The biggest learning that Apoorva Mehta had after reflecting his 20 pivots was this:
The reason to start a company shouldn’t be to start a company, but should be to solve a problem which you truly truly care about.
We started our company to solve a problem that we can solve the best and has a significant impact on humanity. In this process, we want to build a generational company that can withstand the test of time. To do that, we believe it takes courage to boldly discard good ideas in favor of great ones.
Good ideas aren’t enough—you need great ones.
As I connected the dots through several pivots, I came to understand more about myself and also realized the importance of founder-market fit.
Step by step, I strive to walk down the path towards myself.
I feel that we are getting closer from -1 to 0.
Looking Ahead
I am not sure how well our journey has been conveyed. If you have read this far, you must be someone deeply interested in our journey.
To the person who knows their path, every event is destined to happen. If this feels like destiny to you, please contact yoonseok@berkeley.edu.
We define “launch“ as not just launching a software product, but as launching any type of service (e.g. manual labor provided by founders).
Jack joined Pensieve as a co-founder in December 2022 and has worked on all the ideas with me except Idea 1. Without Jack, we couldn't have iterated so quickly. I am very grateful to Jack for being by my side over the past year.
Moreover, products before Idea 6 were not developed just by the two of us. Dooho Lee, Sanmaru Um, Tinah Hong, Suyeong An, Kitae Hwang, Deokhaeng Lee are all people who participated in at least one project. Thank you for believing in me. I hope the experience of working together in our team, even if it was only for a little while, has had a positive impact.
Let's consider the scenario of conducting a complex search on the topic "Should I consider using React over Vanilla JS?".
Q (Question): This is the primary question or objective behind the search. In this case, it's "Should I consider using React over Vanilla JS?".
Q hat (^Q): These are sub-questions derived from the main question to facilitate finding answers. They are essentially smaller, related questions that help break down the complexity of the original query. For instance, to decide whether to use React instead of Vanilla JS, one might consider questions such as what JS is (Q1 hat), what React is (Q2 hat), and how much time it would take to replace current JS-based software with React (Q3 hat). The reason for using "hat" (^) is to denote these as estimated or derived questions, which might be necessary when the original question is too broad or unclear for direct searches.
P (Page): Pages are the results obtained from searching the Q hat. A single estimated question can yield multiple pages as results.
I (Information): This denotes the pieces of information within a page (P) that could serve as potential answers to the Q hat or the root question (Q).
S (Sub Knowledge): These are insights or partial answers derived from combining the information (I) pieces. They contribute towards partially answering the root question. An example could be understanding the pros and cons of both React and Vanilla JS.
K (Knowledge): This is the structured knowledge that encompasses answers to the root question, synthesized from the sub-knowledge (S) elements.
Envisioning the search process in this structured way acknowledges that a complex search might span across one or multiple sessions. A session is defined as a continuous period of web surfing by the user. This entire process could unfold within a single session or over several sessions, depicted as Day 1, Day 2, Day 3, etc., in the diagram.
By diagramming the complex search problem and clearly defining the user groups, we establish a framework for understanding and navigating the intricate process of seeking information across multiple dimensions of inquiry.