The Dangers of Overconfidence in Tech Development

The year was 1865.

In the beginning, the company was a paper mill in Finland.

Fast-forward to the 1960s, when the company found itself (somehow and someway) in the telecommunications space, producing radio telephones and other communication devices.

The company ultimately developed the Global System for Mobile Communications (GSM) standard, the global standard for mobile networks.

By the early 2000s, this company was the leading mobile phone manufacturer, capturing nearly 40% of the global market share.

In 2007, the mobile phone division generated nearly $70 billion in annual revenue.

In 2014, they generated $21 billion in revenue and ultimately sold for $7.2 billion that year.

The company that bought them eventually dissolved them and took a write-off for the 2014 purchase price.

The company was Nokia.

The purchaser was Microsoft.

It's an example of a company that was a leader who thought its dominance was its moat. Ultimately, it became a chaser as the iPhone revolutionized the mobile phone space with the smartphone. Ultimately, it became defunct.

It's a classic example of how overconfidence can blind us to disaster.

For us, our journey started nearly 150 years after Nokia started. And it all began in a booth of a local pizza shop by our offices.

We had an idea. And we already had a successful business. The potential was endless and highly likely, so we thought.

That day, we decided to enter the technology world and begin building a financial app to help energize our pipeline for one of our wealth management businesses.

In the beginning, four core feelings drove business decisions. Now, looking back, we can learn from our failings.

• Confirmation: We believed that the need for our technology vision was there because other companies had launched (e.g., Personal Capital, Betterment, Mint, etc.) and had extreme success.
• Confidence: We had built a successful traditional RIA firm that managed multiple billion. We had started a mass affluent division that was ahead of the times and highly profitable. We had experience in "doing the actual work," while the companies in the market were tech first and wealth management second. We were wealth management first and tech second.
• Urgency: The model was already proven, so we thought the blueprint was out there in the open. Given our success in building profitable businesses, our focus and desire were to invest a little to get going and ultimately reach profitability quickly.
• Profitability: We wanted to build this on our dime and not get into the game of raising money. The focus was on making a profit. The judgment of success was relative to the firms we had built, both profitable, stand-alone businesses.

Our experiences building a tech company provide lessons that can help us, as an industry, think differently about innovation and how we should proceed to continue impacting more families' lives.

We are in an AMAZING industry, and competitors will continue to try to enter our space. We must be constantly curious and innovative to shore up our moat consistently with the changing times.

Our confirmation of our idea stemmed from what we observed in the market. Others had successfully built, launched, and grown their financial tech apps, so we knew that. The internet allowed us to dig into their journeys and elements of their blueprints.

We then built our vision by replicating what we saw without knowing how they adapted and iterated to that point. We were building to replicate, not necessarily differentiate.

A lesson within the startup ecosystem is that you must build a product that is 10x better than what consumers currently have access to. 10x better means more efficient, effective, or valuable than competitors.

Google, for instance, made search faster and more robust, and Tesla created an electric car that was aesthetically pleasing, environmentally friendly, and powerful. These products didn't just add features; they simplified and enhanced the user experience.

The hard work to be 10x better happens behind the scenes. The work is to deliver something easy, simple, and valuable to the consumer.

With confirmation, we added our own overconfidence. This combination led to us jumping straight into building a product.

The success of early innovators confirmed that the market wanted the product. Our overconfidence led to an overestimation of the likelihood of success and an underestimation of the risks.

Building a technology solution or launching a new service offering or a new way of doing business are massive endeavors. Their success extends beyond us. It depends on the consumer / the end user.

This means that we shouldn't sit and theorize but wade into the process. We should start small, test with a small group of people, and understand if what we are building resonates with the people we want to serve.

We felt that, given that we understand wealth management and the market has accepted these technology solutions, we could bypass this stage—a stage that is integral in finding what is known in the tech world as product-market fit. We assumed it was there, but we didn't confirm that our vision for the product was a better option for the market.

Overconfidence in all industries leads to resistance to iterative development. When leaders are overconfident, they feel they have the answers, and the feedback from others is irrelevant because they don't understand the problem and solution. Thus, overconfident leaders jump all the way in. This is costly and makes it extremely hard to adjust if the initial vision/thesis is incorrect.

Another major challenge that overconfident leaders face (unknowingly, as I've come to learn) is resource misallocation and inefficient time use. Overconfident leaders believe tasks can be accomplished faster than in reality and with fewer resources.

We often focus on tasks that we think are important to meeting our vision but are not important to gaining adoption. Because we are overconfident, we believe we know what is important and what is not. However, we have yet to receive the market feedback that will be critical in accepting our project.

This happened more times than I can count in our journey. For instance, the client didn't care about opening an account, yet we knew it was necessary to earn a profit. What the user cared about was getting financial advice relevant to their situation. So, we focused on the paperwork, and the consumer wanted the complimentary advice. We used our time inefficiently.

Overconfidence leads to another cognitive bias found by Daniel Kahneman and Amos Tversky: the planning fallacy. The planning fallacy impacts the projects that overconfident leaders enter into because it leads to underestimating the time it takes, the costs it will incur, and the risks associated with the project.

With the planning fallacy, leaders tend to focus deeply on specific tasks rather than looking at the bigger picture. A side effect of this is the inability to delegate.

We believed we could build a solution that scaled to 10's thousands of people by investing minimal money. We thought who we were and our past successes would allow us to navigate the risks efficiently and cost-effectively.

We were wrong.

Then comes the feelings of urgency and profitability, which led to us scaling prematurely.

We tried to be more than who we were at a specific time. We had to reach profitability, and we expected (anchored ourselves) to do it quickly because we set a narrow funding period.

This led to us overhiring and doing so too early. For instance, we hired a much too experienced marketing team member very early in the process. We had not yet hit product market fit, yet we were looking to gain users to our technology as quickly as possible. This led to people signing up, not being satisfied, and never coming back.

It also created significant tension between our marketing lead and me because we constantly evolved our vision. We still needed to nail it. But we needed users so we could get clients, ultimately generate revenue, and quickly reach profitability. There was friction in the reality of the situation and the path we had anchored to.

We also experienced a similar situation on the sales side multiple times. We didn't have the core message, we hadn't refined our sales strategy to be replicated, and our product wasn't "prime time" ready. We expected an experienced sales leader to overcome this and help us reach our profitability and sales goals quickly.

We were wrong. We were scaling prematurely.

Premature scaling leads to product proliferation.

We kept adding new features and expanding the current features, never having a core foundational product that was solid and validated by the market. Our answer to needing to be validated was that the product needed more. It needed to be more robust. It didn't have all the features. So, we kept adding, inefficiently using our resources and time and burning through our cash.

A product that fits its market doesn't need more features. It is so easy, simple, and good that more features just confuse the value, not enhance it.

The combination of confirmation, confidence, urgency, and profitability meant we continued in this vicious cycle of assuming what the market wanted.

The missing part of the first step—getting feedback, starting small, and finding product market fit on a small scale—was the nail in our coffin before we started.

Too often, I find myself remembering this as I look to make adjustments in our business today. I jump to the conclusion, but then I remember. I jumped to the conclusion because I'm confident in my abilities and understanding of this industry. But ultimately, the change needs to be accepted by the team or our clients.

Thus, I may need to be corrected. It's hard for someone who is highly overconfident to admit that.

So, I pull back, break the vision down into small pieces that can be tested, test these pieces, learn, and then iterate because it is easier to iterate on a small scale than to invest time and money and then try to adjust.

I build iteratively now, not directed by what the user wants but more by how they engage in what I believe they want. This is a really important concept to understand.

Finding a product market fit for a new process or product doesn't mean asking the user or the team what they want and just building precisely what they say. Instead, it is a matter of doing research (conversations, surveys, industry research, etc) and observing others. Then you, as the visionary, bring all of that together to build a small, simple, rough version of what you think would be a solution for the problem you identify.

Then, it is a matter of introducing this to the market it is meant to serve (clients, team, etc.) and getting feedback on their experience with it. Then, based on this new information, it is a matter of adjusting.

Nowhere in this process is the end user telling us what to do; they are engaging, and we are observing and iterating to find that product-market fit.

The visionary has the idea. It's the Henry Ford quote, "If I would have asked them what they wanted, they would have said a faster horse." Ford went on to build a car. However, it was iterative and evolved based on how the consumer interacted with the innovation.

So, to ensure we don't fall into the traps that I did in building a technology company, we must do the work to find product market fit (market research, observation, conversation, etc.). We also must be constantly curious and desire to continuously learn from both those in our industry and those outside of it. We must dive deep into the trends of our industry and those outside of our industry.

The lessons I learned aren't new. They are just more visible now that I've had space to reflect. Sitting and being the Monday morning quarterback is easy. When in the thick of building a product or a business, we get lost. We know what we should do, yet what we do tends to be different.

So, these lessons are simple to understand, yet they are challenging to implement.

However, the leaders who do will be the ones who impact this industry in ways we can never imagine today.