In our freshman year, my cofounders and I studied decision theory. If we had been more intentional about leveraging the concepts, my first startup might have evaded pivotal problems. Decision theory involves examining the reasoning behind an agent’s (individual’s or group’s) choices (Steele & Stefánsson, 2020). It concerns both mundane choices, like between taking an Uber or the underground, and high-stakes choices, like whether or not founders should relocate to work in-person or stay in separate time zones, working remotely. Decision theory is good at categorizing the inclinations agents have towards suboptimal decision-making (Steele & Stefánsson, 2020). Specifically, the cognitive biases that significantly stunted my first startup included the G.I. Joe Fallacy, confirmation bias, the planning fallacy, and sampling bias. Some critical mistakes could have been sidestepped if we had been more proactive at identifying and combating these phenomena.
The G.I. Joe Fallacy
The G.I. Joe Fallacy (GIJF) enabled the rest of the biases to wreak havoc. It is the false idea that awareness of a bias is sufficient to overcome it (Santos & Gendler, 2014), causing false confidence. To make the name of this fallacy less distracting, I’ll clarify that it originates from an American cartoon that always ended with, “Now you know, and knowing is half the battle” (Kristal & Santos, 2021). Biases fall into two categories: encapsulated and attentional. Encapsulated biases cannot be overcome by simple awareness because the mental processes cannot be cognitively penetrated (Kristal & Santos, 2021). For example, even if we know an image is an optical illusion, we still cannot unsee the deceptive effect. But encapsulated biases weren’t my first startup’s major impediment; attentional biases were. Attentional biases can be overcome by self-awareness in theory but not often in practice (Kristal & Santos, 2021). The information that reduces bias is usually not considered during decision-making (Kristal & Santos, 2021). Confirmation bias, the planning fallacy, and the small sample fallacy are all attentional biases, and the entire founding team was aware of them. We were guilty of having the false belief that knowledge alone was sufficient to influence a change of behavior, resulting in a lack of implementing sufficient mitigative measures or executing solutions consistently. In the following sections, I will outline how the GIJF amplified the negative consequences of all the others.
Confirmation Bias
Confirmation bias is the inclination to search for, interpret, and recall knowledge that reinforces an existing belief (Eisenmann et al., 2013). It necessarily involves ignoring evidence that contradicts an appealing idea. This is a rampant mental habit. Since my cofounders and I studied confirmation bias and corresponding solutions, we thought avoiding it would be second nature. This assumption and mode of thinking stems from the GIJF (Santos & Gendler, 2014).
Contending with counter-arguments is how ideas get iterated upon, the most essential process for startups. Startups often begin without even a skeleton. The foundation of the company needs to be thought through from scratch. If those fundamental infrastructures do not go through refinement, if they do not confront contradictory evidence, the startup’s growth and longevity are highly likely affected. Even though we reduced our confirmation bias over time, we still suffered the opportunity cost of ruminating on bad ideas for far too long.
It is easy to say that confirmation bias is wrong, but it is often difficult to recognize, and hence, reducing it is a never-ending battle. However, I did not truly understand how confirmation bias quietly creeps into a thought process, and describing how this happens narratively seems more appropriate.
In the second and third months of working on the startup while I was interviewing university professors, our intended target market at the time, I discovered an exciting notion. One of the professors specialized in a revolutionary methodology, and he suggested that we create a hyper-specific tool that would help them teach students how to conceptualize and execute the method. Having attended his class before and reflected on how such a tool would have helped me and my colleagues, I thought, “ How cool, right?” I did a bit of research on the methodology’s rising popularity amongst prestigious universities and became very enthused - Our target market was growing very rapidly! It was an early stage conviction that clouded my judgment.
I interviewed other people who attended the class and designed a feature set that would deliver some excellent learning outcomes. I was attached to these talking points: a rapidly growing user base, a very effective feature set, access to an expert who created the methodology, and easy access to user testing as many fellow students are or were enrolled in the course. My cofounders confronted me with challenges, but I would find ways to dismiss them. They were all technical-oriented and discussed how difficult the tool would be to develop. However, my response would suggest how easy it would be to use base code to create learning tools in other fields. It was just an investment that would help us scale in the future. If they pointed out that the existing target market was tiny, I would respond with the expected rapid growth. Unfortunately, these rebuttals were superficial and continued for about a month and a half.
We intentionally employed the consider-the-opposite strategy in the most productive and final meeting about this idea. This works by actively directing a conversation from the narrow set of confirmatory evidence and towards contradictory evidence (Larrick, 2004; Danielson & Sinatra, 2017). This method increases efficacy when additional related factors are considered (Fahsing et al., 2023; Van Brussel et al., 2020). So, I was compelled to think: What if the significant market expansion did not correlate with a proportional customer increase? My cofounders helped me flesh out the ideas. Customers would have either been administrators of academic institutions or university students because professors aren’t often the decision-makers when purchasing additional tools to complement their lectures. Additionally, students are very price sensitive and thus access less niche learning platforms, which would inevitably come up with their units on this new methodology. There were many other equally good arguments against my talking points. Using the consider-the-opposite strategy, we reduced the instances where particular individuals got stuck on an infeasible idea. However, group-level confirmation bias or group polarization was more elusive.
In team settings, something called “polarization” happens. This occurs when shared opinions do not get the scrutiny they deserve, thus creating an excessive net confidence in those opinions (Myers & Lamm,1976). The team’s technical approach, similar cognitive approach, and desire to avoid conflict reinforced unchallenged assumptions. Hence, the impact of group polarization persisted for too long, was challenging to identify, and was difficult to mitigate.
When we settled on a product, the following sales and development process were not ideal. In retrospect, it is easy to see that building out the backend before we had strong traction or a well-thought-out frontend was not the best idea. But that is what we did for a three-month sprint. We mainly constructed the mechanisms behind the feature set while dedicating few resources to sales and fewer to UI development. Our team dialogue was like this:
“We must gauge and develop our backend capabilities early on.”
“Prompt engineering is new, and our team had younger, less experienced developers.” “Gauging traction, marketing, and thinking about how the product looks are essential, but pointless if we can’t build the product.”
We challenged this argument and acknowledged our deficiencies, but the backbone of this thought pattern lasted a long time. We all agreed on it, and agreeing with your cofounders feels comfortable, especially when you highly respect them. Admittedly, it was easier to focus on technical problems since they have more exact and tangible solutions than the fuzzy business problem of gauging market interest or getting sales deals. The temptation of dealing with less resistant issues and the comfort of consensus were the mechanisms for the GIJF (Santos & Gendler, 2014). Technically, we should have been able to identify our confirmation bias, but it was so difficult in practice. This aspect of confirmation bias results from favoring coherence and comfort over dissonance, as described by Kahneman (2011). Our mistakes became more evident when we released the product but got no users and had no avenue for attracting users.
On paper, we should have been less susceptible to confirmation bias. It is expected that teams are most successful at mitigating collective confirmation bias when there are diverse viewpoints (Myers & Lamm, 1976). We were a relatively diverse group of people: three different nationalities, three different ethnicities, three different majors, three different religious inclinations, almost no overlapping hobbies. But, we were similar in ways that we did not acknowledge, and therefore, were unable to consider the implications. Before university, we were high-achieving STEM students. Consequently, we were very drawn to problems that can be solved with an exact solution. If a feature wasn’t working, then there was something we could change in the code to make it work. Our dilemmas included: “If we couldn’t find a reliable way to gauge market interest and already had a bunch of random code built out, and if one set of test users said they loved a part of the UI that another set of test users hated, then what?” We were unaware of the
We were accustomed to solving similar problems, so we aligned on what we felt comfortable prioritizing. In this way, our viewpoints were not diverse, and we should have sought out external opinions to help refine our approach. We had regular check-ins with mentors but did not leverage these sessions to change our fundamental approach. They prodded us to balance our focus and think more about the deprioritized elements of the company. We did not do much to initiate in-depth conversations to this end and did not internalize the message in time. Engaging in deep reflection and discussions within our group as well as seeking external, expert opinions would have assisted us in identifying and exploring diverse perspectives and solutions.
Planning Fallacy
The planning fallacy is the tendency to underestimate the resources required for a project, even though past experiences are contradictory (Pilat & Sekoul, 2021). There are two ways that an estimate can be calculated: by breaking the project down into subcomponents or by considering the distribution of resources it took to complete similar projects (Kahneman & Tversky, 1979). The vast majority of people underestimate the resources required for a project, overestimate their abilities, and do not consider the very likely possibility of technical difficulties (Pilat & Sekoul, 2021). The planning fallacy can manifest in several ways (Kahneman & Tversky, 1979). It can be the case that the team creates the estimate using only the project breakdown method: totaling the resources estimated for each subcomponent (Kahneman & Tversky, 1979). This neglects to factor in emergencies or how long such projects have taken in the past. It can also be the case that the team only uses the distributional method. The risk here is matching the current project to the wrong place regarding the distribution of resources required for similar projects. For example, imagine that Projects A, B, and C took 2, 4, and 6 days to finish, respectively. We thought Project D would be similar to A or B, so we guessed it would take 3 days. But once we started, it turned out to be more like Project C. C had taken 6 days because of a last-minute issue, but D didn’t have that problem, so it ended up taking 5 days. In the end, our guess was still way off because we matched it to the wrong project and didn’t break it down properly. Here, we can see that the good thing about the distributional method is its ability to consider the buffer time required for emergency delays. However, neglecting the subcomponents of the project still led to an unacceptable estimation. The most accurate estimates are a hybrid of the distributional and project breakdown methods (Buehler et al., 1994), and I can testify to that.
My underestimation of time and effort occurred again when I initially thought I could build a website in three days. Having built a prior website, I assumed that I retained all the skills, but it was indeed challenging and demanded a month of my time and effort. Additionally, I was overconfident in making suitable design choices quickly. There were three components of the project: reteaching myself the use of the platform, designing, and iterative execution. Furthermore, I did not even factor in my concurrent obligations, like academics. These assumptions made me think, “Yeah, three days is enough”. On an individual level, the GIJF held firm. If I had chosen to be cognizant, considered my previous website development timeline and website building components, and avoided inflating my self-perception, I could have made a better estimate.
A complementary strategy to the distribution and breakdown hybrid is having an external source generate the estimate. Individuals can estimate the time it takes others to complete a task with notably improved accuracy (Buehler et al., 1994). Upon finding this in my research, I was confused because that’s not what happened at my first startup. We consulted each other while creating estimations but repeatedly missed the mark. As it turns out, group discussions about shared projects experience planning fallacy “accentuation” (Buehler et al., 2005). This is when discussions become narrowed toward excessive optimism (Buehler et al., 2005). The accentuation effect occurred because my co-founders and I operated as a unit on collaborative, interrelated projects. We did not qualify as the kind of external sources that would help generate planning estimates for each other. If my team had this startup do-over, I would try an arrangement where my company and another startup help each other with realistic planning estimations. We were close friends with other startup founders who knew about the distribution of resources for past projects and understood project breakdowns. They would have been an ideal resource to leverage, but we genuinely did not think of it. We did not take the initiative to dig deeper into our recurring planning issues, and they persisted. Of course, the repeated frustration of this fueled a growing despair.
Sampling Bias
Sampling bias is when an investigation uses a flawed sample to conclude about a population (Simkus, 2023). Our population of interest, or target market, at the time, were university students or young graduated professionals seeking to upskill themselves. We interviewed people to understand their characteristics and interaction with the product prototype. The specific flaws of our sample were the convenience sampling method and small size. The sampling method and size must work together to produce generalizable conclusions. Convenience sampling meant we only investigated members of our target market that were easiest to access, such as our peers or secondary connections. This was in stark contrast to the most ideal method, random sampling, where each member of a population has an equal chance of being selected (Horton, 2024). In our context, random sampling meant that a peer at our university was just as likely as someone from a different institute to be interviewed by my first startup. A large random sample drastically reduces the impact of influential variables, called confounders, that can lead to erroneous conclusions (Biau et al., 2008). Such samples are more likely to distribute known and unknown confounders similarly to the target market population. Small samples of convenience are likely to have a drastic difference in confounder distribution (Rabin, 2002), making results ungeneralizable, and hence, we don’t end up knowing much about the target market. We recognized that our small convenience sample was not representative and continuously tried to interview more people, totalling about twenty. However, this was not quite the problem and solution we should have been chasing.
Our issues with selection bias stemmed from the more fundamental problem of not creating a solid primary evidence strategy. We conducted user interviews because we were told that primary research was critical. Given real-world constraints, we were inexperienced at navigating market research and had many competing individual priorities. We did not take the time to research and think about how creative we could be about primary evidence gathering. I had an epiphany about this at a conference in the Fall of 2023. A language-learning AI startup posted their product in language learning Facebook groups with a few hundred members and got dozens of responses from people interested in their value offering. Then, they simulated the product and got feedback from participants who self-volunteered to test. This was a much better approximation of a large random sample, and there was the added benefit of directly proving the existence of organic traffic towards the product. Another startup at the conference had a different strategy. They made a website that contained a mock-up of their product and a short form people could fill out to declare their interest. They continuously tweaked the search engine optimization and product offering until they got many hits. Again, this better approximates a sizeable random sample that built a stronger case for active market interest. Messaging groups and building a website were also strongly suggested to us by mentors and peers. my first startup should have spent more time thinking about these strategies than focusing on user interviews.
We did attempt to improve this from 2023 into 2024. I messaged Facebook and LinkedIn groups and created a website, but the execution was inconsistent. We only messaged about four groups and did not do search engine optimization for the website. We paid no attention to the lack of interest in the website. Still, I believe that is justified given that we put dedicated effort into making it accessible to the target market. However, the lack of group chat responses should have signaled little market interest or that we were not portraying ourselves appealingly. We ignored this and focused on the positive feedback from user interviews, where people said they would use the product and gave us ideas on how to tailor it. Our failure to fully develop alternative primary resource approaches and defaulting to focus on user interviews was confirmation bias that slipped in. It was fed by a growing exhaustion and shift in priorities as we approached graduation. This is another excellent example of how biases can feed off of each other to produce a much larger monster.
Conclusion
Although being aware of biases is important, the real challenge is transforming that knowledge into something actionable. This is especially true when juggling college courses, part-time jobs, personal obligations, and an ambitious new venture. If there’s one key takeaway from my first startup story, it’s this: Don’t always trust yourself to remember or spontaneously apply what you “know” at the moment of decision-making. Instead, make bias mitigation a structural component of how your team operates.
That can mean scheduling a monthly “Consider-the-Opposite” brainstorm to deliberately pick apart your favorite ideas or inviting external peers to weigh in on your project plans before you commit to resource-heavy sprints. It might look like letting trusted mentors review your front-end wireframes and your back-end architecture in the same conversation so neither is permanently sidelined. Or it can be as simple as pausing every so often to ask, “Are we giving in to comfort here because we’re exhausted from balancing classes and internships?” My cofounders and I never made these pauses systematic because we kept stumbling into our blind spots.
However, inexperience and failure are common rites of passage for startup founders. It’s almost cliché to say, “Learn from your mistakes,” but it’s also more genuine than I ever could have realized before. The missteps we made with my first startup gave us tangible lessons in how to structure research, how to question each other’s assumptions, and how to keep personal life stressors from clouding our team’s collective judgment. If you’re wrestling with similar challenges, my advice is to embrace the fact that you won’t get it right every time. Reflecting on these experiences is far more valuable than the illusion of a smooth ride. The real tragedy isn’t in failing once or twice; it’s in failing to turn that chaos into a roadmap for better decisions tomorrow.
References
Biau, D. J., Kernéis, S., & Porcher, R. (2008). Statistics in brief: The importance of sample size in the planning and interpretation of medical research. Clinical Orthopaedics and Related Research, 466(9), 2282–2288. https://doi.org/10.1007/s11999-008-0346-9
Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the "planning fallacy": Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381.
Buehler, R., Messervey, D., & Griffin, D. (2005). Collaborative planning and prediction: Does group discussion affect optimistic biases in time estimation? Organizational Behavior and Human Decision Processes, 97(1), 47–63.
Danielson, R. W., & Sinatra, G. M. (2017). A modern approach to critical thinking and analysis. Educational Psychologist, 52(3), 183–204.
Eisenmann, T. R., Ries, E., & Dillard, S. (2013). Hypothesis-driven entrepreneurship: The lean startup. Harvard Business School Background Note, 812–095.
Fahsing, I. A., & Ask, K. (2023). Enhancing investigative decision-making: The value of consider-the-opposite strategy. Law and Human Behavior, 47(2), 101–112.
Horton, M. (2024, October 21). What are the disadvantages of using a simple random sample to approximate a larger population? Investopedia. https://www.investopedia.com/ask/answers/042815/what-are-disadvantages-using-simple-random-sample-approximate-larger-population.asp
Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.
Kahneman, D., & Tversky, A. (1979). Intuitive prediction: Biases and corrective procedures. TIMS Studies in Management Science, 12, 313–327.
Kristal, A. S., & Santos, L. R. (2021). G.I. Joe phenomena: Understanding the limits of metacognitive awareness on debiasing. Harvard Business School Working Paper, No. 21–084.
Larrick, R. P. (2004). Debiasing. In D. J. Koehler & N. Harvey (Eds.), Blackwell handbook of judgment and decision making (pp. 316–337). Blackwell.
Myers, D. G., & Lamm, H. (1976). The polarization phenomenon. Psychological Bulletin, 83(4), 602–627.
Pilat, D., & Sekoul, D. (2021). Planning fallacy. The Decision Lab. Retrieved February 19, 2025, from
Rabin, M. (2002). Inference by believers in the law of small numbers. The Quarterly Journal of Economics, 117(3), 775–816.
Santos, L. R., & Gendler, T. S. (2014). What scientific idea is ready for retirement: Knowing is half the battle. Edge.org. http://edge.org/response-detail/25436
Simkus, J. (2023). Sampling bias: Types, examples & how to avoid it. Simply Psychology. https://www.simplypsychology.org/sampling-bias-types-examples-how-to-avoid-it.html#
Steele, K., & Stefánsson, H. O. (2020). Decision theory. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy(Winter 2020 Edition). https://plato.stanford.edu/archives/win2020/entries/decision-theory/
Van Brussel, L., & Huyghe, P. (2020). Confirmation bias in scientific research. Nature Human Behaviour, 4(6), 553–561.