Is Entrepreneur First Worth It? Part 3: Luck Surface Area
How pursuing a goal with full intensity lead to an unforeseen opportunity
The first week of November was a bloodbath. We called it the “Halloween Massacre.”
On October 31, the EF staff attempted to maximize founder liquidity by breaking up as many suboptimal teams as possible (so that new ones could be formed). It seemed like any team who had not found a hair on fire problem - most teams - was in this boat.
The effort to break up teams was so intense that we began to gossip about why it was such a priority. I thought that some of the teams that were being encouraged to break up had been doing well. The theory was that in the previous cohort, there was a trend of underperforming teams staying together for too long, so EF wanted to ensure that that didn’t happen in our cohort. If you weren’t in a team by November 28, you had to leave the program, so EF was trying to create an opportunity for as many of us as possible to form new teams with the benefit of the past month’s experience.
Luckily for me, I had broken up with my previous cofounder amicably the week before. I was in a new partnership, working on an idea that I was excited about (collaboration software for analytics teams).
Welcome to Part 3 my 4-part series about my experience at Entrepreneur First. If you’re new here, start with Part 1 and Part 2. In Part 3, I’ll share the remaining ideas that I worked on at EF and - spoiler alert! - why I decided to leave the program early.
Idea #3: collaboration software for analytics teams
Picking up where I left off last time, I wanted a nonobvious, esoteric problem with a global market. The problem of data teams being unable to measure the impact of their work seemed to fit this criteria.
The problem that my cofounder, an analytics and data science leader who had built the analytics teams at multiple unicorn startups, had identified was the symptom of a larger problem: there’s no effective way for business stakeholders to engage with the insights produced by the data team or to see what insights exist in the first place. I had experienced this problem from the business stakeholder perspective when I was CPO at Lendesk.
We hypothesized that the reason why this problem exists is because business intelligence tools like Looker and Tableau are not built for sharing and collaboration. BI tools help data teams visualize data; to share the insights that are born out of that data, data teams take screenshots of charts, export the data to CSVs, and create slide decks. An insight is shared once - typically only with the stakeholder who requested it - and then dies in an email or Slack channel, never to be seen again.
We thought that we could solve this problem by building a collaborative and searchable system of record for insights. By making it easy for data teams to document and share their findings - and by making it easy for the organization to be able to to discover and engage with those findings - we could help organizations uncover the critical insights that exist in their data.
So we got to work on problem validation. Unlike my previous partnerships, this time I had to rely on my technical cofounder to set up discovery calls due to his network in analytics.
To our surprise, after a week of problem validation calls, none of the analytics leaders we spoke with seemed to care about this problem. Yes, it had only been a week. But if this was truly a hair on fire problem, I would have expected to have heard at least one anecdote to back up our hypothesis, but we had nothing.
My cofounder didn’t want to give up yet, but I lacked conviction in our idea because we had no evidence that it was a problem worth solving (beside the opinion of my cofounder). I was also feeling the pressure from EF; those who didn’t have a cofounder by November 28 would have to exit the program. The opportunity cost was too great to continue working on something that I didn’t have conviction in, so we broke up.
Lesson #3: know where you sit on the problem spectrum
Rob Bishop sold his startup to Twitter for $150M 18 months after founding it at EF. Rob gave a talk halfway through EF, and it changed the way I think about problems.
The subject of Rob’s talk was applying the Jobs to Be Done framework at EF, but what resonated with me was how he thought about problems existing on a spectrum and how the problem’s position on that spectrum determines the “shape” of your startup:
At one end of the spectrum, people have a problem, but they don’t know that they have it. Startups that solve problems like this require a lot of marketing resources in order to make customers aware that they have the problem in the first place.
At the other end of the spectrum, people know that they have a problem and know what the solution is, but they aren’t using it for some reason (e.g. people want to get fit but don’t want to go to the gym). Startups focused on problems like this require a lot of sales resources to persuade customers to use their solution.
In the middle of this spectrum is where you want to be because the product sells itself. Here, people know that they have a problem and are searching for a solution to it. These problems are “hair on fire” problems - problems that customers are so desperate to solve that they’re willing to try anything (including listening to pitches from founding teams that don't have products yet, like us).
Rob’s startup, Magic Pony Technologies, fell into this third category; it created a technique for enhancing images with machine learning, which was a problem that Twitter was desperate to solve in 2016. Twitter was so eager to solve this problem that Rob and his cofounder were able to reach Twitter’s executives before they had built any product. According to Rob, your ability to connect with a senior executive at a big company quickly is a sign that you may have found a hair on fire problem. As was the case with Magic Pony Technologies, the opportunity to solve a hair on fire problem tends to be presented by some novel technical innovation.
My takeaway from Rob’s framework isn’t that you need to have a hair on fire problem in order to start a successful startup but that you need to know where your problem sits on this spectrum. Your problem’s position will determine the nature of your startup (i.e. marketing-led, sales-led or product-led). All else being equal, hair on fire problems are the best because the products sell themselves, but they’re rare, and finding one that you can solve in a short amount of time - like EF’s three month program - requires luck.
The collaborative analytics idea was not solving a hair on fire problem. It’s possible that we could have built a great product and business around it, but it would have required a lot of marketing in order to convince analytics teams that there was a better way and that our solution was it. Most successful businesses aren’t solving hair on fire problems.
More importantly, I would have required more conviction. This idea was only exciting to me if I could quickly determine that working on it was worth my time. I didn’t find the problem space inherently interesting, and I was dependent on my cofounder’s domain expertise to judge the validity of the problem.
I realized that I can get excited about any problem - even if it’s a boring one that I don’t have a personal connection to - but that excitement is fragile. To maintain my excitement about a problem like that, I need to be able to validate the opportunity quickly. On the other hand, I’m willing to invest more time into problem validation and customer discovery if the space is inherently interesting to me, because learning about it is a reward unto itself.
Ideas #4, #5 and #6: SolarCity for ADUs, X-Ray Vision for Home Renos and Computer Vision for Mining
After breaking up with my last cofounder, I wanted to change my approach because the work that I was doing didn’t feel like it was compounding; I was starting from scratch with each new idea rather than iterating in a particular problem space. I had stopped feeling like I was getting closer to starting a startup, and I was beginning to question whether or not EF’s framework and criteria (potential to be a unicorn, no solo founders, etc.) suited my goals. I considered withdrawing from the program and focusing instead on ideating on my own. Working with a technical cofounder without line of sight to a validated problem was starting to feel like a burden.
I realized that the option to ideate on my own would remain available to me after EF but that the option to work with such a talented and diverse group of technical co-founders wouldn’t. So, I decided to form one last team with someone that I had had my eye on from the beginning of the program. His areas of expertise were computer vision and robotics, which fascinate me. The way he spoke about technology was captivating, and he had great product sense; I thought he’d make a natural CTO. We quickly realized that we both had an interest in real estate, so proptech seemed like a promising place for us to focus.
A recent news headline caught my eye: Ontario had announced changes to municipal zoning laws in an effort to increase the adoption of accessory dwelling units (ADUs). A friend of mine was in the process of building a laneway house on his property in Vancouver, and from speaking to him, I knew that the process was long, expensive and complicated. My hunch was that homeowners in major Canadian metros weren’t building ADUs on their properties because there was too much friction involved. I thought that we could increase the adoption of ADUs by handling all of the complexity for the homeowner - permitting, construction, financing, etc. - in exchange for the rights to the rental income that the ADU would generate.
So we got to work speaking with ADU builders to understand what the constraint was to homeowner demand. TL;DR: it costs too much to install ADUs in urban areas due to the restrictive municipal zoning laws. Yes, the zoning laws were changing, but they hadn’t changed enough for our idea to be viable. To have a shot at solving this problem, we would have needed to innovate on the manufacturing side, which wasn’t a business that I was interested in building.
We went back to the drawing board and landed on the problem of expensive surprises in the home renovation process (something that I have firsthand experience with). We thought that we could use sensors to help contractors “see behind the walls” in homes to understand where the problems with a renovation might be upfront, before beginning construction. As a result, surprises would be minimized and contractors could provide a better client experience. But through speaking with contractors, I learned that the ones who cared about providing a great client experience already had a sufficient - albeit manual - solution to this problem (a “discovery” site visit, prior to project kickoff). None of the contractors that I spoke with seemed to have a problem (besides needing more business, now that interest rates had risen and demand for renovations had fallen). Time to pivot…
We shifted focus to commercial and industrial construction. The complexity of large construction projects seemed to present problems that computer vision could solve, like safety inspections and project management on the job site. So we attended a construction conference to see if we could find a problem worth solving, but OpenSpace was solving all of the ones that we had identified. Back to the whiteboard…
Impressed with OpenSpace’s traction in the construction industry, we wondered if a similar computer vision solution could create value in the mining sector. At this point, we were no longer just teetering on the edge of “Solution In Search of a Problem” territory, we were living there full time. With one week before “Super Check-In,” the meeting with our EF advisor which would help us prepare for our Investment Committee pitch three weeks later, we didn’t have time to pivot or break up and form other teams - we had to generate as much traction as possible with what we had.
“Do you really want to spend the next five years visiting underground mines?” our advisor asked my cofounder and I at Super Check-In. I felt my stomach drop. I didn’t know anything about mining. “But that was overcomable,” I told myself. After all, I was the business guy on our team! Surely I could figure out a new industry and talk my way into some customer discovery calls. But the bigger problem was that I realized I didn’t want to dedicate the next five years to learning about an industry that didn’t interest me. In fact, I had a hard time thinking about spending another week validating that our hunch was a real problem that needed solving. I only had three weeks left at Entrepreneur First (EF) though, and I dreaded the idea of returning home to Vancouver empty handed, without a startup.
But I dreaded the idea of committing to starting a startup that I wasn’t interested in starting even more, so we decided to break up. Exhausted and eager to return home to Vancouver for Christmas, I withdrew from EF with two weeks to spare.
Lesson #4: Want to win > right to win
In an attempt to “win at EF” - i.e. to start a startup that EF would invest in - I had strayed too far from what I knew. Neither my cofounder nor I had any experience in the industrial sector, so trying to validate problems was like the blind leading the blind. In other words, we had no unfair advantage in starting this startup. We didn’t have a right to win.
What’s worse, by trying to be open-minded, I ended up with a solution in search of a problem in a sector that didn’t interest me in the least. Researching the industry and cold emailing prospective customers felt like banging my head against a wall. Not only did I lack the right to win in this industry, I also lacked the want to win.
I was relieved to no longer be banging my head against the wall but disappointed that I hadn’t found my killer startup idea at EF.
Just as I was about to return home to Vancouver, I was approached about an opportunity that I didn’t see coming…
Two big names in the Canadian startup ecosystem were starting a venture studio (one of whom I had met through EF), and I was asked if I’d like to be their first founder in residence.
Beside conquering my fear of failure and learning how to validate problems insanely fast, the biggest benefit I gained from EF was the increase to my luck surface area. It had been a long time since I had pursued something I really wanted with full intensity, and after only a couple of months, it was leading to opportunities that I couldn’t have anticipated.
This is the end of the story of my experience at EF. In Part 4 (of 4), I’ll provide my brutally honest review of the program and finally answer the question, “Is Entrepreneur First worth it?”