Building in Public: Founders Day Edition

Last week, I hosted the third annual Founders Day in Vancouver, BC.

Like the origin stories from many a startup, Founders Day was something of an accidental creation. It was originally born out of casual conversations and was intended to be a one-off event (before Web Summit moved to Vancouver the following year). Put simply, it was an experiment.

But as Eric Ries once famously wrote, “an experiment is more than just a theoretical inquiry; it is also a first product.”

Not only did the local ecosystem embrace the experiment that was Founders Day, by year two it had become abundantly clear that we had tapped in to a deep unmet need amongst founders in Western Canada.

Coming into year three, it was time to start evolving Founders Day into something sustainable.

The Evolution of an Event

The first two Founders Days were prototypes in the truest sense. They were giant meetups built atop a base of duct tape, paperclips and a lot of behind-the-scenes scrambling (if you arrived early enough last year to see Google, Fasken and RBCx employees madly stuffing badges into plastic name tag holders, you know what I’m talking about). The events looked fancy by virtue of being held at the Vancouver Convention Centre, but they were very much delivered in the model of Paul Graham’s famous essay, Do Things that Don’t Scale.

Nice place for a tech meetup, eh?

By the time we kicked off the planning cycle for Founders Day 2026 towards the end of last year, I had zeroed in on three distinct areas in which I wanted to evolve Founders Day:

1. The Venue

For as stunning as the Vancouver Convention Centre is, it’s very much designed for large-scale conferences and poses challenges for hosts of smaller events. For example, the first two Founders Days had no on-site lunch offerings and we had to host the networking portion of the day at a separate venue 15 minutes away (both of which led to a lot of attrition throughout the day).

This year, I wanted to find a venue where we could deliver a more holistic, continuous experience to attendees. I also wanted to see if we could take better advantage of Vancouver’s exceptional August weather.

Look how sunny it is outside…

2. Delivery

Like any good early-stage startup, the first two Founders Days were a success in large part because of the shared willingness of everyone involved to roll up their sleeves and “get it done”. Sponsors showed up at 6:00 am to stuff badges into plastic name tags. Lawyers and bankers scanned attendees at registration and handed out lanyards. Speakers ran around trying to find their fellow panelists and ensure that everyone got on stage at the right time.

That’s fun and exhilarating once or twice, but it’s not sustainable. Especially not when the novelty wears off and the hiccups become more glaring to attendees.

Coming into this year, a big focus was on progressing from the inconsistency and unpredictability of a large, volunteer-driven meetup towards something more intentional and well-executed.

Look! An actual sign with an arrow →

3. Finances

Of course, added infrastructure comes with added costs. To-date, Founders Day has been entirely subsidized by corporate and government sponsors and myself. In order for Founders Day to cement itself as a permanent event in the annual Startupland™ calendar, it needs to be built atop a foundation that is long-term sustainable.

That means, like any startup, we needed to start the long march towards break-even.

The Journey towards Product-Market Fit

Continuing along with the startup analogy, year three of Founders Day came with many of the same questions that all early-stage startups face as they progress towards product-market fit:

• Will free MVP users pay for it?

• Can you maintain what makes the core offering special while adding new features and making it more robust?

• How do you navigate conflicting user feedback and decide on a roadmap and priorities?

• How will you evaluate the success of the new version?

We made a number of changes this year to both the event and the organization/infrastructure behind-the-scenes. In other words, we rebuilt the MVP from the ground up, added a bunch of new features and released version 3.0 to the world.

If I were to write technical release notes for this year’s Founders Day, they would look something like this:

Release Notes - Founders Day 3.0

• New branding and design language

• Completely redesigned UI/UX (new venue)

• Improved user onboarding (actual conference badges, expanded registration area with redesigned staffing, improved signage)

• Redefined user roles

  • Blue = Founders, students

  • Orange = Speakers, mentors, ecosystem champions

  • Brown = Sponsors, investors

  • White = Staff, volunteers

• Enhanced in-app user support (on-site F&B)

• Improved and expanded partner integrations (more sponsors and community partners, many of whom exhibited at Founders Day)

• Platform and stability upgrades

• Misc. bug fixes

Enhanced user support 🍻

What does all of that look like, practically speaking? Here are some of the bigger changes we made for Founders Day 2026:

• By far, the biggest change to Founders Day was the move from the Vancouver Convention Centre to a new outdoor venue. That was a huge undertaking, as it meant moving from a “turn key” venue to one where we had to bring everything in ourselves (from the stage, A/V setup and seating to fencing, garbage, and even porta potties).

• The shift from “turn key” venue to custom experience wasn’t limited to the stage show. For the first two years of Founders Day, the networking event took place at a bar about 15 minutes from the convention centre. For year three, I wanted everything to be in one place. We brought in food trucks, concession stands, coffee bars, local beer and wine vendors and even an ice cream truck (the latter courtesy of local startup IcePanel). That kind of effort required procurement, power and permits. Lots and lots of permits…🤦‍♂️

• Completely rethinking the venue for Founders Day meant a massive expansion to the team. The first two events relied heavily on convention centre staff for much of the behind-the-scenes logistics. For year three, we had to assemble a full-blown event and production team from scratch. That included event planners, a stage team, A/V staff, videographers and photographers, on-site security and more. Plus a whole lot of volunteers (shout out to Chris Hobbs for recruiting, training and supervising all of the amazing Founders Day volunteers 🙏).

• Another seemingly simple but significant effort was on the design side. Founders Day 1.0 had a Luma page and a LinkedIn post. Version 2.0 had a Luma page, a LinkedIn post and a SquareSpace website. Founders Day 3.0 had my long-time collaborator Gail Yui. In the months leading up to this year’s Founders Day, Gail performed a top-to-bottom branding exercise that touched every aspect of the event, from signage and attendee badges to exhibiter booths and volunteer t-shirts to beer cans and bucket hats (plus, of course, the LinkedIn page).

For all of the changes we made to this year’s event, we tried hard to stay true to the original vision of Founders Day: to facilitate and encourage connections between founders. In his seminal book, Startup Communities, Brad Feld observed that,

“Building a startup community is not a zero-sum game in which there are winners and losers: if everyone engages, they and the entire community can all be winners.”

This year’s Founders Day had nearly 100 experienced founders and investors speaking to and mentoring up-and-coming founders — many of whom flew in just for this event.

These speakers flew in from San Francisco, LA, Toronto and Seattle ✈️

The Results?

So what did attendees think of Founders Day 2026?

🫠

The thing about building in public is that if you’re doing something that matters to people, then they are going to have opinions.

Strong opinions.

And that’s okay. In fact, it’s great!

Genuine customer feedback is a signal that people care about what you’re building. They may not agree with everything you’re doing. They may not like all of the decisions you make. They might get really loud and upset when things break. But that means they care about your product and the problem you’re solving.

And it’s infinitely better than silence. (It’s also why the field of product management exists.)

If the volume of attendee feedback alone is any indication, then Founders Day is trending in the right direction:

• Founders Day 2024: 7 people provided feedback

• Founders Day 2025: 37 people provided feedback

• Founders Day 2026: 102 people provided feedback (so far…)

Of course, that’s not the only metric that matters. So here is my honest review of Founders Day 2026:

Founders Day 2026: The Good, The Bad and the Ugly

Let’s start with the good:

• From a product-market fit perspective, the biggest win of Founders Day 2026 was that we had almost as many founders, investors and ecosystem supporters buy paid tickets as attended for free in 2025. (We didn’t have as many registrations as last year, but that was to be expected given how many people register for free events without giving much thought to whether or not they actually plan to attend.)

• At a more granular level, attendance figures for many ticket categories, including prospective founders/students, investors and ecosystem supporters, were up significantly compared to last year.

• Other than running out of cold brew coffee towards the end of the day, the logistics for the food trucks, bars and concessions all went off without a hitch.

• The registration process — which was a disaster in years past — was smooth and seamless.

• Attendee feedback on the founder mentoring and networking portions of Founders Day 2026 was through the roof. 📈

• We ever-so-slightly beat our revenue objective for this year’s event (revenue = sponsorship dollars + ticket sales).

• Finally, we got strong subjective feedback from the majority of attendees at this years event, including a 4.3/5.0 event rating on Luma and broadly positive feedback both publicly on social media and privately through attendee surveys.

Next, the bad:

• Overall attendance was slightly down compared to last year. We already know some of the reasons for this (e.g. marketing for this year’s event started later than planned due to delays in securing the venue). In the coming weeks, we will dig deeper into attendance statistics and feedback to see what other lessons are to be had.

• Some of the decisions we made around the venue layout and configuration led to challenges with the A/V setup (e.g. in some areas of the venue the sound was too loud while in others it was inaudible).

• Although we met our revenue target for this year’s event, expenses significantly exceeded our original estimates (primarily due to delays and unforeseen challenges with the new venue). Founders Day 2026 was never projected to break even, but the overruns definitely led to a larger deficit than planned.

Finally, the ugly:

• This biggest miss of this year’s event came from the main stage seating layout. Our team spent significant time and effort developing contingency plans for rain, but we didn’t anticipate that last Thursday would be one of the hottest days of the year in Vancouver. The result? For significant portions of the day, it was entirely too hot and sunny for most people to watch the main stage presentations from the audience seating.

• The change in audience flow resulting from the heat led to a number of additional challenges, most notably on the audio side. The speakers that lined the outside of the seating area weren’t configured to overcome the ambient noise from 400+ people mingling in close quarters. That meant many of the attendees standing in the shade were unable to clearly hear the panelists for significant portions of the day (though, rest assured, all of the sessions were recorded and we’ll post the videos soon!).

What’s Next for Founders Day?

Despite the hiccups that happened with this year’s event, Founders Day 2026 was an unquestionable success.

It delivered on the core value proposition we originally set forth while making considerable improvements over the “MVP” of years one and two. We also made meaningful progress on each of the three high-level objectives defined at the beginning of our planning cycle, which is a big deal when it comes to evolving into something that is long-term sustainable.

Of course, there is still plenty of work to be done on the journey towards product-market fit. Founders Day 3.0 had its fair share of “bugs” and there remains a healthy backlog of feature requests. In the coming weeks, we’ll dig deep into all of the feedback we received from speakers, mentors, sponsors and attendees and unpack the many lessons and learning’s from Founders Day 2026.

After that, it’s time to get to work on Founders Day 2027!

We’ve already got a tentative date soft-circled and clear ideas for how to make next year’s event even better, so stay tuned.

In the meantime, I want to thank all of the vendors, volunteers, speakers, sponsors, mentors and founders who made Founders Day 2026 happen. This year’s event wouldn’t have been possible without each and everyone one of you.

Thank you to our many corporate and government partners, including:

• Presenting Partner: Fasken Emerging Tech

• Gold Partner: Innovate BC

• Silver Partners: AWS, Conference Badge, DuploCloud, IcePanel, Launch, New Ventures BC, Osler, Remitly and Web Summit Vancouver

And thank you to the many incredible people who contributed to Founders Day 2026 in ways big and small, including: Alex Conconi, Alex Norman, Alexandra Greenhill, Ali Pejman, Allen Pike, Amin Yazdani, Andrew Fursman, Andrew Harries, Andrew Vilcsak, Anthonia Ogundele, Arif Khimani, Ath Caramanolis, Bijan Sanii, Bill Tam, Brandon Waselnuk, Chris Albinson, Chris Hobbs, Colin Harris, Conrad Whelan, Daniel Eberhard, Darrell Kopke, David Luba, Dennis Pilarinos, Derrick Emsley, Diraj Goel, Edoardo de Martin, Edward Chiang, Gary Agnew, Glen Lougheed, Handol Kim, Ian MacKinnon, Irene Dorsman, Jack Newton, Jacob Shadbolt, Joel Hansen, Josh Nilson, Karm Sumal, Landseer Enga, Mayor Ken Sim, Kenndal McArdle, Kim Kaplan, Kris Hartvigsen, Michael Buhr, Michael Henson, Nejeed Kassam, Noah Stanford, Olivier Vincent, Praveen Varshney, Ray Walia, Reza Sanaie, Reza Arbabian, Serge Salager, Shivam Kishore, Sophia Millar, Susan Su, Tanis Jorge, Tifanee Po, TJ Rak, TX Zhuo, Vik Kambli, Villi Iltchev, William Johnson, Wilson Tang and Yen Lee (sorry if I missed anyone!!).

See you all at Founders Day 2027.

Give Your Customers What They Want

For this week’s post, I’m going to start off with a case study that isn’t from the annals of Silicon Valley (although many in the tech world are loyal customers of this industry). Today, we’re going to talk about fast food. Specifically, we’re going to look at the astonishing rise of A&W Canada.

If you’re reading this from the U.S., you’re probably scratching your head right now (in all likelihood, you haven’t been inside of an A&W in years and, if you have, your experience was likely…not great).

A&W Canada is a completely separate company from A&W Restaurants, which operates A&W in the U.S. and elsewhere. You can read the full history here, but the tl;dr is that A&W Canada split from the US company in 1972 when it was sold to Unilever. A group of Canadian franchisees subsequently bought the company back in 1995 and have operated independently since then. Not only is the Canadian company larger than A&W Restaurants (by both number of stores and revenue), many of the popular menu items and brand assets (including the chain’s bear mascot) were created by A&W Canada and licensed to A&W Restaurants.

Ok, so let’s jump into the case study.

Back in the early 2010s, fast food chains were going through an existential crisis as millennials led a massive shift towards healthier eating. Quick-service restaurants (QSRs) around the world were seeing sharply decreasing sales and rushed to introduce new menu items in order to stem the bleeding. McDonald’s introduced McWraps and egg white sandwiches, Taco Bell added herb-grilled chicken and cantina bowls, while Burger King unveiled turkey burgers and low-sodium french fries. But A&W Canada took a different approach.

At the time, A&W Canada was having its own crisis of identity. Although it was the fifth-largest QSR in the country, its growth was stagnating.

“We were seen as not being very connected with consumers and being out of date, out of style, out of touch, outmoded, not very relevant,” said [Trish] Sahlstrom.

Rather than rush to introduce new menu items as many QSRs were doing, A&W Canada initiated a deeper strategic planning process centred on “dramatic changes in consumers’ attitudes and behaviours.”

“We saw, for instance, an increasing desire among consumers to know who and where their food was raised,” she said. “Consumers were saying, ‘Where’s the evidence? I no longer trust just that it tastes good. I want to know where it came from. I want to know who has raised the animals that are feeding us. I want to know your values, A&W.’”

The company then asked what factors came into play when consumers wanted a hamburger.

“As we started to put together all of these pieces of evidence — all of the answers to these questions — what came out incredibly strong and clear to us was leave out the hormones and steroids and don’t use the antibiotics.”

A&W Canada stumbled on an epiphany that, surprisingly, seems to have been missed by most other QSRs: their customers didn’t want them to change their menu per se, they just wanted to feel better about eating there. A&W customers didn’t want to buy a salad or a wrap or a gluten-free super food quinoa bowl when they visited one of the company’s restaurants. They simply wanted a slightly healthier hamburger.

So in 2013, the company announced that all of its burgers would be made with beef raised without hormones, steroids or other additives.

Following the announcement, the Canadian beef industry was up in arms. The move required A&W Canada to source beef from the U.S. and Australia, as there weren’t enough ranchers in Canada at the time raising cattle that met their requirements. The industry responded with a public relations campaign and attempted boycott of A&W, but failed miserably.

Same-store revenue for A&W Canada increased 6.3% the following year, while a consumer research study by QRI subsequently found that “89% of burger eaters [in Canada] were “impressed and interested that A&W is serving beef raised without added hormones or steroids.” (By contrast, McDonald's same-store sales decreased in 2014 — falling by -2.1% in the U.S. and -1.0% globally)

A&W followed up the success of its “better beef” campaign with similar shifts to its chicken and egg supply chains in 2014.

The sustained focused on healthy ingredients resulted in even greater success in 2015, with same-store revenue increasing 7.6% that year. Total revenue for 2015 topped $1 billion — the first time in the company’s history — while its share of the QSR market in Canada increased from 12.7% in 2013 to 14.4% in 2015. And the company hasn’t taken its foot off the gas since.

In 2018, A&W Canada became the first QSR in the world to introduce Beyond Burgers nationally. That same year, the company further evolved its egg supply from vegetarian-fed to cage-free and antibiotic free eggs. And in 2020, it shifted its burgers to 100% Canadian, grass-fed beef.

And the results showed. With the exception of 2020’s Covid-driven drop, A&W Canada outpaced the world’s largest QSR brands on same-store sales for many of the years following this strategic shift.

So what does this have to do with tech?

A&W Canada’s recent successes were the result of a management team that, amidst a groundbreaking shift in consumer preferences, took the time to stop and ask the question, “what do our customers really want?”

Today, the technology world is undergoing a similarly unprecedented shift as AI rapidly permeates every aspect of our industry. As I look around, I see countless companies of all shapes and sizes rushing to plug AI into their offerings without stopping to ask themselves, “is this what our customers really want?”

• Services businesses trying to become product companies, “so our customers can do it themselves”

• Product companies replacing interfaces that their customers have grown to love with text-based prompt interfaces, “because that’s how AI works”

• Business intelligence / data analytics startups rushing to leverage AI so that “business users can directly query the database” (trust me on this one 😉)

While it’s inevitable that AI will fundamentally change many aspects of our lives, it’s important that founders take the time to think about the shift from their customers’ perspective. In some cases, AI will completely upend a category and, thus, require a total rethink of a company and its products. But I suspect in many industries, customers will simply want a faster, more powerful, AI-enabled “hamburger”.

The Life and Death of Project Stag

If you look at the bio on my personal website, it says that, “I’m a 4x founder-turned-VC.” But only two of the entries on my LinkedIn page list me as a founder or cofounder: DataHero and Commonwealth Ventures.

The third company I cofounded, The Engineer & The Designer, was a consulting company formed with my long-time partner-in-crime, Gail Yui. From 2016 - 2018, we consulted with Series A and B startups in Silicon Valley, helping them to align their product and GTM strategies (I never added it to my LinkedIn profile because it was really just a short-term cash flow business while we each figured out what we were going to do next).

But there is a fourth company that we cofounded that almost no one knows about.

This is the story of Project Stag.

Chapter 1

Gail Yui was the unofficial third cofounder of DataHero. She was involved in the earliest days of the startup, back when it was known as Glean. She designed most of the UI in our original prototype, all of our logos and pitch decks, and pretty much every graphical asset the company ever had. At the time of DataHero’s founding, Gail was leading creative for a Sequoia-backed company that was about to go public, so she couldn’t officially join until after we had raised our Pre-Seed round.

When DataHero was acquired — about 4 years later — our fastest-growing customer segment was digital marketing agencies. Shortly before the acquisition, we discovered that they were a perfect fit for our product: each agency managed multiple clients and each client used multiple SaaS services (like HubSpot, Google Analytics, etc.). The agencies spent considerable time each month manually creating reports to demonstrate their value to clients — reports that could be automated in DataHero. DataHero’s reports weren’t an out-of-the-box fit, but the agencies didn’t care. They had a clear and urgent problem and DataHero was a pain killer.

After DataHero was acquired, that part of the platform and its emerging go-to-market was shelved. To Gail and I, it felt like a missed opportunity. Months later, as we decompressed over pisco sours in her hometown of Lima, Peru, we couldn’t help but feel that we had unfinished business. It wasn’t the first time we had talked about the digital marketing opportunity after transitioning out of DataHero, but that night (possibly because of just how many pisco sours we consumed), I turned to her and matter-of-factly said,

“We’re going to have to build this, aren’t we…?”

She silently took a sip of her drink and simply nodded.

Chapter 2

When we returned to San Francisco, it was on.

We reached out to some of DataHero’s former agency customers and found that they were all desperately searching for a new solution. We spent the next several months on the road, traveling from agency to agency (with more than a few stopovers at HubSpot’s Boston headquarters). The opportunity was crystal clear to us. Small-to-medium sized agencies were willing to pay $1,000 or more each month if we could solve certain analytics and reporting problems for them with a turn-key solution. We were pretty sure that it wasn’t a VC-scale opportunity, but we knew exactly how to design it, how to build it, and how to sell it.

Using the revenue we were generating from The Engineer and The Designer, we incorporated a Delaware C-corp (aptly named, “The Engineer and The Designer Labs”), brought on some engineering help to accelerate development, and went full steam ahead.

But what would we call the product?

Based on our customer research, we knew that digital marketers (and marketers in general) appreciated brands that felt exclusive, so we drew inspiration from private member clubs like The Battery (which, at the time, was the hottest ticket in SF). One night, we met up for drinks at a nearby restaurant and looked up to see this masterpiece looming overhead. Immediately, we knew that our logo would be a stag.

We spent about 20 minutes trying to figure out what the company name should be, what domain names were available, etc., but quickly agreed that was a waste of time (we were still pre-alpha, after all, so who cared?). We settled on the interim name “Project Stag”, knowing that this particular nomenclature would reinforce the feeling of exclusivity that we were going for.

Our minimalist business cards had no branding, no names and no contact details. Instead, the cards had an embossed gold image of a stag on one side and a URL and access code on the other.

We handed out these “exclusive” cards to digital marketers around the world to grant them the privilege of access to our alpha product. And they ate it up. Within a matter of weeks, we had hundreds of digital marketers testing out our product.

Chapter 3

Project Stag was designed from the ground up to give digital marketers two things:

1. Instant, out-of-the-box reports that could deliver value at any point in the client revenue journey, from demo to closing to monthly reporting to upselling

2. A feeling of exclusivity akin to having unlocked a “cheat code” for their business

With only a domain name, Project Stag could instantly provide a comprehensive analysis of a company’s online presence (everything from website speed to code errors to SEO performance). Add social media accounts and connect a few key services and the depth of analysis grew by orders of magnitude. One of the key early features was a competitive analysis, which digital marketers could use to visually compare a client’s online presence to those of their competitors (a feature that was particularly effective during sales pitches).

The alpha users loved it. Project Stag was saving them dozens of hours each month while generating client reports that looked far better than anything they were currently delivering. But as we got closer to public release, something seemed off. We noticed that usage was dropping off sharply at around the one month mark. We dug deeper into the data and saw a concerning pattern: agencies would onboard a client, connect all of the requisite accounts and create the initial reports…then never generate anything else for that client.

Red alert!

Gail and I immediately reached out to a number of the alpha testers and arranged for in-person meetings. Over the course of several weeks, we criss-crossed the continent, visiting dozens of digital marketing agencies in a bid to understand what was going on. We quickly discovered that we hadn’t built as turn-key of a solution as we had thought.

While Project Stag indeed saved the alpha testers dozens of hours of work each month, we discovered that the reports it created didn’t fully replace what they ultimately delivered to clients. Almost all of the agencies augmented their reports with a significant amount of editorial content (intended to demonstrate how knowledgable they were and, thus, support the hefty retainer fees they charged). The agencies were copying the output from Project Stag into their existing report templates and continuing with their mostly-manual reporting processes.

Moreover, we learned that the time savings were mostly coming from their junior-most staff, whereas the features we had planned for subsequent releases (such as a recommendation engine to help them prioritize client improvements) were where they really saw the value. The agencies loved the competitive analysis feature as a sales tool, but it was a “nice-to-have”.

By the time we finished our feedback tour, it was unequivocally clear that the alpha version of Project Stag was not a pain killer. Despite that, a number of the agencies wanted to continue using the product (and were willing to pay a nominal amount for it), but nothing close to what we were aiming for. We would need to deliver a significant number of features that we had planned for future releases before we would be able to generate meaningful revenue.

Chapter 4

At this point, we faced a decision. We had significantly decreased the amount of consulting work we took on in order to focus our efforts on Project Stag, but were nearing the end of our runway. We estimated that it would take at least 6 more months of full-time effort to implement the functionality that we believed would deliver meaningful revenue. That left us with two options:

1. Raise angel capital to support the work needed to get us to cash flow positive

2. Ramp back up our consulting work and continue to bootstrap (knowing that the pace of Project Stag would decrease and it would likely take 10-12 months to start generating meaningful revenue)

Later that week, Gail and I met up for dinner to figure out our path forward. Over the course of the evening, we discussed the current state of Project Stag and debated the potential paths ahead, analyzing and over-analyzing each option.

After several hours, Gail paused and stared off into the distance. Then, in a scene that inverted the conversation that had birthed Project Stag, she turned to me and matter-of-factly said,

“I don’t want to do this for the next 5 years.”

I silently took a sip of my drink and simply nodded.

Epilogue

It turned out that while we were both excited by the opportunity that the digital marketing agency use case presented, neither of us was deeply passionate about digital marketing itself. We would later come to recognize that our initial interest stemmed from what it represented within the context of DataHero — a missed opportunity — rather than a particular excitement about marketing analytics.

We explored several acquisition scenarios, but all of the offers were contingent on the two of us joining full-time and bringing Project Stag to production. As neither one of us wanted to do that, we ultimately shut down the project and shuttered the company.

Shortly after that, I joined 500 Startups as an EIR and embarked on my journey as a VC. Gail returned to senior operating roles, working with later-stage companies while mentoring for Sequoia’s Ascend program.

---

I wrote this post not only to share the story of Project Stag, but because of the profound effect the experience had on one particular aspect of my approach to investing: how I view “founder-market fit”.

Many investors place a premium on “founder obsession” — the degree to which a founding team is driven to solve a particular problem. My experience with Project Stag led me to realize that it’s possible for a team to execute for a fairly long stretch of time with the velocity necessary to succeed, but without having a deep, emotional connection to the problem they’re solving. In other words, I believe that some founding teams can get so caught up in the excitement and momentum of building that they mimic the obsession investors are looking for. That adrenaline enhances everything they do — including the intensity with which they talk about the problem they’re solving.

But, eventually, the adrenaline that comes from the excitement of building runs out. And when it does, if there isn’t a deep, emotional motivation to fall back on, momentum quickly fades.

Which is why I ask a very specific question of founders,

“Why is this the problem you want to work on for the next 7-10 years? What will keep you working on this when many of the people around you stop caring?”

I find that this particular framing can elicit some very illuminating facets of a founder’s personal experiences and personality — including the real reason(s) why they’re doing what they’re doing.

How Glean Raised a $1M Pre-Seed Round

It was October 2011.

Seven months earlier, Aster Data — the big data pioneer where I was employee #1 — was acquired by Teradata. The acquisition left a halo around everyone involved and, with big data at peak hype, by Q4 many of of us were spinning up companies in adjacent areas.

Dheeraj, Mohit and Ajeet were hard at work on Nutanix. Manav, Hari and Raghu had teamed up on Instart Logic. Sharmila, John and Vaibhav had co-founded Clearstory Data. And I had partnered with my old roommate from Stanford, Jeff Zabel, to create an entirely new type of BI platform called Glean (oh…you thought I was talking about that Glean?).

Given the pedigrees of our respective teams and Aster Data’s reputation amongst investors, there was no shortage of interest in the companies being formed by Silicon Valley’s newest mafia. By late-2011, Nutanix had already raised two rounds of funding from top-tier VCs, while Instart Logic recently closed a seed round from Wing Ventures’ precursor fund. ActionIQ, Workspan, ThoughtSpot, Level Up Analytics, Cyberhaven and Cohesity were still to come. But in October, it was our turn to go to market.

Start Your Engines

The Aster Data acquisition gave our alumni a huge collective advantage when it came to fundraising: we could literally get meetings with any VC we wanted. In fact, many investors were so eager to meet with Aster Data’s alumni that they were reaching out the moment they heard rumor that one of us had left Teradata.

With such an advantage, Jeff and I figured that it would be easy for us to raise our first round of funding. Many of the Aster Data spinouts that had already raised VC funding had done so pre-product. We were coming to market not only with our experience and reputations, but with a functioning prototype. We thought it would be a cake walk.

But ours was to be a different journey. In the end, our experience had far more in common with that of relatively unknown, first-time founders than it did with those of my former colleagues.

And it taught me a lot about how early-stage investors think.

The First Try

Jeff and I started working together in May 2011. At the time, Jeff was wrapping up a stint in Münich leading development of the world’s first automotive integration with the Apple iPhone as head of BMW Connected (a precursor to the Apple CarPlay platform we all know and love today). By October, he had left BMW, returned to the Bay Area and was full time on Glean.

We were focused on creating a business intelligence platform that would enable less-technical users to make analytical decisions without having to rely on corporate data teams. The incumbent BI tools (MicroStrategy, Cognos, Business Objects and even Tableau), were so archaic in their interfaces and bloated with features that anyone without a strong data background struggled to use them. As a result, most organizations had entire teams of analysts that did nothing but create dashboards and reports for other employees. We saw an opportunity to change that.

We captured our vision — BI for Me — in this two-page overview:

We sent the Glean overview to several dozen investors in my network (mostly VCs whom I had previously met plus a handful who had reached out to me). While the term high-velocity fundraising hadn’t yet been coined, that was effectively what we were doing in scheduling so many investor meetings back-to-back. We naively assumed that our round would be instantly competitive and planned to spend only a couple of weeks fundraising.

Every single investor we reached out to took our meeting — the Aster Data halo was strong and all of them were eager to see what we were up to. Here’s the deck we shared with them (sadly, a few of the images in the deck have been lost to time):

With our early (but functional) prototype, a credible, experienced team and the halo of a well-publicized exit, we figured this would be a no-brainer for investors. But the VCs we met with had other ideas.

After three weeks of meetings, it was clear that we weren’t going to raise our round. But there was a silver lining: by meeting with so many VCs in such a short period of time, it was impossible to ignore the consistency of the feedback we were receiving:

We like the two of you as founders.

You’re credible and have the right mix of skills and experience to bring this to market.

The prototype is very promising.

But…

We aren’t convinced there’s a market for this.

Why was our experience so different from those of the other Aster Data spin-outs?

Simple: we were the only one not building a traditional enterprise software company with a well-known, well-understood go-to-market. Our company had a risk that none of those founded by my former colleagues had: market risk.

In 2011, nobody had ever tried product-led growth for a data analytics product. Our collective skills and experience, while credible, didn’t provide any supporting evidence that our market hypothesis was correct.

And to investors, market matters most.

Back to the Drawing Board

While the outcome of our first attempt at fundraising was discouraging, we firmly believed that we were on to something.

We hadn’t been building Glean in a bubble. Not only had I seen the pain point firsthand at many of Aster Data’s customers, we had socialized the concept with dozens of potential users, as well as data team leads and corporate executives. The feedback we received was consistently and overwhelmingly positive (even after taking into account The Mom Test). But we needed to do better.

We needed to get more specific.

“Life might have its failures, but this was not it. The only true failure can come if you quit.” - Great-great-aunt Rose

For the next three months, we were laser focused on three things:

1. Nailing the initial use case(s) for Glean

2. Gathering more evidence that there was, in fact, a market for this

3. Figuring our what specific functionality was necessary for an MVP (and building as much of it as we could)

In the final weeks of 2011, we spoke with hundreds upon hundreds of people. Business and data users at companies like Neiman Marcus, MySpace, LinkedIn, Nike and Ubisoft, executives (aka buyers) and data team leads in organizations large and small, and other experts in the data analytics space.

As we dug in, we began to see a very specific, very acute pain point that many of the organizations we spoke with were facing: business units were increasingly relying on a new wave of “cloud services” like Salesforce, Marketo and SurveyMonkey, but they had no way to analyze the data contained within those services (at least, not without considerable help from their internal data teams).

In those days, there were virtually no integrations between cloud services and on-premise databases (Salesforce being the most notable exception). That left companies wanting to analyze their “cloud data” with only two options:

1. Download the data in a giant CSV file and try to manually make sense of it

2. Build a custom connector to each service in order to pull the data into the corporate data warehouse, then build custom reports and dashboards for business users on top of the data warehouse

Both of these options required considerable effort on the part of internal data teams, meaning literally no one was doing it.

That was our wedge.

A More Focused Prototype

The insight hit us like a ton of bricks.

Before Aster Data was acquired, we had started experimenting with deploying our data warehouse in the cloud (in fact, we deployed the world's first production cloud data warehouse on AWS for ShareThis in 2008…it was barely functional). Snowflake hadn’t yet been founded, but the opportunity seemed crystal clear: data was increasingly being generated by cloud-native services. Of course we would need cloud-native data analytics.

With the help of Gail Yui, an experienced graphic designer who would eventually become the third leg of our product development stool, we kicked off 2012 in earnest. We rapidly iterated on our prototype with a goal of highlighting its potential for cloud-native BI.

We already had a fairly advanced machine learning engine that did a reasonable job of automatically identifying and classifying CSV data (that’s right kids, machine learning wasn’t invented by OpenAI 🤣). We identified every single cloud service we thought someone might want to use for data analysis — everything from business services like Salesforce and SurveyMonkey to personal fitness offerings from Fitbit and Nike+ —then downloaded sample CSV files from those services and used them to train our algorithm.

We didn’t build any actual integrations — open APIs weren’t a thing yet and, even if we had access, we didn’t have the engineering resources to build them. Instead, we focused on making our data classification layer as accurate as we could for the CSV files one could download from those services. We reasoned that if Glean could handle the standardized CSV files users could currently download, then we could credibly argue that we could eventually build a direct integration.

Proving a Market

The second thing we needed to do was to prove beyond a shadow of a doubt there was a market for what we were building.

We had a two-pronged approach to this:

1. Take our new-and-improved prototype back to the potential users, data team leads and execs we had been talking to and get as many of them as we could to agree to take reference calls with potential investors

2. Reach back out to the experts in the data space we had been talking to and try to get verbal commitments from some of them to angel invest (the SAFE hadn’t yet been invented, so there wasn’t an easy way to raise angel funding in advance of a VC round)

After circling back with the potential users, data team leads and execs, a number of them agreed to take reference calls and/or gave permission for their names to be included in our fundraising materials as potential future customers. These ranged from the President of Neiman Marcus Online to the head of Stanford University’s alumni fundraising organization to countless individual users.

When we showed our updated prototype and explained our vision to experts in the data space, we quickly secured commitments from a number of them to angel invest, including:

• Mayank Bawa and Tasso Argyros, co-founders of Aster Data

• Dave Kellogg, CEO of Host Analytics (also ex-CEO of Mark Logic and ex-GM of Salesforce)

• Jonathan Goldman, Anu Tewary and Mike Greenfield, all previously of LinkedIn’s data team (Jon was the inventor of the “people you may know” algorithm that is used in literally every social media platform today)

(We also subsequently raised from angel investors who weren't in the data space, like Jerry Neumann and David Cohen.)

Fundraising: Take Two

With our narrowed focus, improved prototype, and clear evidence in support of our market hypothesis, it was time for us to try fundraising again.

But there was one more adjustment we planned to make: this time, we cast a wider net.

Our first attempt at fundraising was focused exclusively on VCs who had deep knowledge of the enterprise data space. While those investors immediately understood what we were trying to build, we were struct by how many of them reacted to our go-to-market hypothesis with some version of “that’s never going to work” (a far stronger stance than simply “I’m not convinced”). So, rather than just go back to the VCs who had previously rejected us, we took time to fill our fundraising funnel.

We built a target list that included more than 50 additional VCs that were active early-stage investors in B2B software companies but didn’t necessarily have a prior investment in a data analytics company. Then, we figured out how to get introductions to each and every one of them (reasoning that the Aster Data exit might not have been on their radar). The list of connectors included Jud Valeski, the cofounder of a young startup named Gnip who had attended the same high school as Jeff.

Over the coming weeks, we met with dozens and dozens of VCs. This time around, the majority of them were far more interested in what we were building and the early proof points we came armed with. We progressed into multiple meetings with a large number of firms, but ultimately, the majority of the investors we spoke with landed on the same conclusion as six month’s prior:

We aren’t convinced there’s a market for this.

While our first experience with fundraising was very much an exercise in our own naivety, our second attempt showed me for the first time how few early-stage VCs are actually willing to make non-consensus investments.

More than half of the investors we met with outright rejected the evidence we presented about a fundamental market shift. Unmistakeable evidence that data generation was moving to the cloud, large enterprises were struggling with this shift and cloud-native data analytics platforms would need to follow (I have no doubt that many of these same investors passed on Snowflake).

Trae Stephens of Founders Fund recently wrote about this phenomenon

But this isn’t about sour grapes. This is about fundraising being a numbers game.

Had we stuck to the “easy intros” — the VCs who were familiar with Aster Data and were looking to invest in Aster Data alumni founding another Aster Data — we might never have raised funding. Ultimately, we found success with investors whose view of the future of data analytics wasn’t colored by the industry’s recent past.

Which brings us back to Jeff’s high school friend, Jud. Jud introduced us to Ryan McIntyre of Foundry Group, a relatively new firm based in Boulder, Colorado. Ryan was a deeply technical investor who had firsthand experience with paradigm shifts, having cofounded dot-com pioneer, Excite. Unlike many of the other VCs we had pitched, Ryan had limited experience as an investor in data analytics platforms. As a result, his diligence was focused less on the recent history of the data analytics industry and more on the potential of the shift to the cloud.

Over the coming weeks, we met with Ryan multiple times in person and had calls with his partners in Boulder. We were excited about how they thought about our opportunity and Foundry quickly rose to the top of our list. All of which ultimately led to the moment of truth.

And when the dust settled, we successfully closed a $1M pre-seed round led by Foundry Group.

Epilogue: What About the Name?

You might be wondering why we gave up the name Glean and introduced ourselves to the world as DataHero.

This was another lesson for me: sometimes, your lawyers are wrong.

Jeff and I absolutely loved the name Glean. We thought it was far and away the best name for a data analytics company — especially one trying to bring data analytics to business users. We were so committed to the name that we had already started discussions about securing the domain glean.com while we were fundraising. But then we met with our lawyers.

Like many startups, we worked with one of the big 3 Silicon Valley firms. And our counsel was adamant that we should not under any circumstances brand the company as Glean. “You’ll never be able to get the trademark,” they said. “You won’t be able to protect the name.”

While they may have been right from a legal standpoint, it’s pretty apparent these days that trademarks aren’t everything. But we capitulated and abandoned our original name. And while the name DataHero served us well, I always lamented the fact that we gave up on Glean.

So it made me absolutely giddy when, 10 years later, a new startup called Glean came out of stealth to democratize data insights.

This Critical Lesson in MySpace's Failure is Still Relevant Today

Many articles have been written about the rise-and-fall of MySpace, the LA-based social network that in its heyday was the most popular website in the world. I had a front row seat to the experience — MySpace was Aster Data’s flagship customer and I was responsible for the relationship. For nearly two years, I flew back-and-forth between San Francisco and LA every week to be onsite with our largest customer as we brought the world’s first 100TB commercial data warehouse into production.

When we first started working with MySpace in 2006, the company had just eclipsed Yahoo! to become the most visited website on the internet (nearly 5% of all US internet visits were to MySpace), “The Facebook” was a fledgling startup that had only recently opened up access beyond U.S. university students, and Twitter was but a few months old.

Peak internet in 2006

At the time, MySpace easily had one of the top technical teams in the world. Everyone I met there was unquestionably an A+ player and the conversations we had on topics ranging from infrastructure to data analysis to user privacy were lightyears ahead of nearly anything else I’d encountered in Silicon Valley.

At the time, MySpace was growing at an insane pace and needed to expand. They needed more engineers, more designers and more data analysts (the term “data scientist” hadn’t yet hit the mainstream). There was just one hitch: the founders had made it their mission to build LA’s first massive tech company and insisted that all employees be based there.

But LA’s startup scene was still in its infancy. There wasn’t enough experienced, homegrown talent to satisfy MySpace’s needs. And candidates in the Bay Area had zero interest in moving south (the NorCal / SoCal rivalry was in full swing in those days, and the prevailing viewpoint in Silicon Valley was that a move to LA meant abandoning tech relevancy).

That’s when MySpace’s leadership made a fatal mistake: instead of keeping the bar high and expanding northwards to Silicon Valley (which other leading startups at that time were doing), the company doubled-down on its “LA-only” mantra. As a result, in less than two years, MySpace went from hiring only the best-of-the-best to bringing onboard people who previously wouldn’t have made it past the first interview.

When competition with Facebook heated up, MySpace simply didn’t have the talent to compete. The company ultimately relented and opened a San Francisco office in late-2007, but by that point it was too late. And we all know what happened after that.

For startups based outside of the Bay Area, the lesson from MySpace’s failure isn’t that every tech company needs to relocate to Silicon Valley. Or even that every tech company needs to open a Silicon Valley office. Rather, founders need to be honest and objective about whether or not the talent pool in their local market meets their needs:

1. In what areas is the local talent pool strong and in what areas is it lacking?

2. Is the local talent pool large enough to satisfy the needs of the company as it grows?

3. Does the local talent pool have experience building high-growth, globally-competitive companies?

Canada, for example, has strong engineering and product talent, but relatively little sales and marketing talent (and almost no experienced executive-level talent). Most Central and Eastern Europe countries have exceptional engineering talent, but limited product talent. And so on.

Similarly, a country like Canada has a large enough engineering talent pool to support thousands of high-growth companies, while the smaller size of Scotland’s talent pool objectively requires companies to look south to England (or to Europe) once they reach a certain level of scale.

And the vast majority of countries not named the United States have virtually no talent who have actually seen the full journey of a globally impactful tech company from inception to exit (and, no, being part of the “founding team of Uber Canada” or the “country manager for Facebook” does not qualify — you joined a stable, well-funded company with thousands of employees, plenty of process, a big, fat salary, and a lot of wind at its back).

The problem is, many founders are either unwilling or unable to look for talent outside of their home market. And even when they are, peer pressure from local investors, politicians and the media to “build a home grown success” often makes it more challenging.

But at some point, every fast-growing tech company based outside of Silicon Valley will be faced with the same question: do we hire an inexperienced, unqualified person locally for this role and hope they grow into it, or do we keep the bar high and go to where the talent is.

When that time comes, just remember that you’re competing against my friends.

The Moment of Truth

It was early 2012. My cofounder and I were huddled around a laptop nervously pitching yet another investor (that’s right folks, remote pitches existed long before Covid). But this wasn’t just any VC. Staring back at us from the screen was Brad Feld, cofounder of Foundry Group and TechStars.

It was the early days of DataHero and we were trying to raise our Pre-Seed round. Our vision was to create the world’s first cloud-native business intelligence platform. We believed that the shift to software-as-a-service would lead to massive demand for analytics solutions capable of unlocking insights across those services. Key to achieving this goal was the ability to identify and standardize data regardless of where it came from. To prove out our concept, we had created a prototype that could take any CSV file and automatically identify and normalize the data it contained.

Of course, it was the early days, so our prototype had lots of bugs.

DataHero 0.8 — aka why DataHero’s first hire was a designer

Brad Feld was the “final boss” in our quest to secure a term sheet from Foundry Group. We had already spoken with his three partners, Ryan, Seth and Jason, each of whom had given us a thumbs up. So there we sat, dutifully answering Brad’s questions before transitioning into a demo.

Brad’s eyes lit up as we showed him our prototype, importing a variety of CSV files that were automatically turned into beautiful charts. He then jumped into more questions,

“Can your system really take any CSV data and understand it?”

“Yes!” replied my cofounder and head of product, sharing more about how the underlying technology worked.

“Does the data need to be in a specific format?”

“No,” replied my cofounder, “DataHero can figure it out automatically!”

At that point, I started to get nervous. Brad was asking what were starting to feel like leading questions and my cofounder was getting caught up in the excitement.

“So…you can literally take any CSV file and load it into DataHero right now…?”

Before I could kick my cofounder under the table, he excitedly blurted out “Yes!!” as I watched a mischievous smirk pass across Brad’s face.

“I just emailed you a CSV export from my Withings scale. Can we try it?”

Actual photos of Brad Feld on a startup pitch call

Cue the record scratch.

At that point, we faced a choice: do we try loading Brad’s file, knowing that there was a high likelihood something would go wrong (seriously…our prototype had a lot of bugs), or do we back pedal and try to escape the corner that we’d painted ourselves into?

We took one look at each other and, without saying a word, answered, “absolutely!”

I then found the CSV file in my email, loaded it into DataHero and…

…it completely broke.

We desperately looked through the errors in front of us and figured out pretty quickly what went wrong. We told Brad that we knew what the issue was and asked if we could email him the results later that day. He agreed.

We got off the call frustrated and deflated.

We figured that we’d just blown our chances with Foundry, but nonetheless got to work fixing the bug in our prototype. A couple of hours later, we sent Brad a PDF with the charts that DataHero had generated from his data.

The next morning, we received an email from Ryan McIntyre with a term sheet to lead our Pre-Seed round.

---

A few weeks later, we went to Boulder and met Brad in person for the first time. I asked him about our experience and what made him decide to invest in us.

“The way you answered,” he responded, matter-of-factly.

“Look, I knew it would probably break,” Brad continued. “I didn’t care if it worked or not, I cared about how you answered. I would have invested even if your response was ‘we’ll send it to you the next day.’”

“The fact that you were willing to try it live — right then and there — told me that you guys believed it would work. That you believed in what you were pitching me. The way you responded told me everything I needed to know about you guys.”

Over the years, I’ve learned an incredible amount from Brad and his partners at Foundry, but this lesson always stuck out:

When the moment of truth arrives, how you respond matters as much as what you say.

The Genius of Creative Destruction Lab

Last Thursday night, I sat in a dining room in St. John’s, Newfoundland and Labrador, the eastern-most city in North America. On a jagged cliff overlooking the unforgiving Atlantic sea, a group of CEOs and investors from across Canada dined on moose (seriously) to celebrate the conclusion of two days of meetings. But we weren’t there to meet with each other. Everyone in the room had spent the past 48 hours focused on a shared goal: mentoring 30 of the most promising startups in Atlantic Canada.

Signal Hill, where Guglielmo Marconi received the world’s first transatlantic wireless signal in 1901

If you’re a founder in Canada — or are involved in the Canadian tech scene in any way, shape or form — then you’re familiar with the letters CDL.  The Creative Destruction Lab is more recognized across Canada than any other accelerator, save maybe Y Combinator. In 10 years, the program has helped create more than $19 Billion in equity value.  That’s right, $19 Billion.

And it costs founders nothing to participate. 🤯

Awkward selfie with Adam Keating, CEO of St. John’s-based CoLab (Panache portfolio company and CDL Atlantic graduate, who recently announced a $17M Series A)

CDL’s model - a cross between a traditional accelerator and Shark Tank – was dreamt up not by a serial entrepreneur or well-known investor, but by a business school professor who was pissed off that Canadian PhD students kept getting hired away by Silicon Valley companies. Ajay Agrawal was determined to change the status quo. His audacious experiment to create a “marketplace for judgement” has completely changed the Canadian tech landscape.

The “Main Room” at CDL Montreal

I first attended CDL in Toronto in 2017 while I was with 500 Startups. And like so many people before and after me, I was blown away by what I saw.  Billionaire CEOs, top investors and world-renowned subject matter experts sitting in a single room, laser focused on mentoring first-time founders.

Soon after, I found myself flying back and forth between San Francisco and Montreal for the CDL “AI Stream.” Two years later, I began adding regular trips to my hometown of Vancouver for CDL “Prime.” The year following, it was CDL-Atlantic, a rotating program held across Canada’s four maritime provinces. And my experience was far from unique.

Creative Destruction Lab’s approach to mentorship has tapped into a desire that many of us in business and tech have to do more. To make Canada better. Yes, many of the people involved in CDL find some manner of business value in participating (investors see deal flow, corporates meet potential vendors and everyone benefits from the networking), but that’s not the driving reason why so many CDL “Associates” fly across the country (and, increasingly, around the world) every 8 weeks.

As the program has continued to expand, so has the impressive list of CDL Fellows and Associates, which not only includes prominent CEOs and investors but also astronaut Chris Hadfield, Turing Award winner Yoshua Bengio, economist Joshua Gans and many more.

Astronaut Chris Hadfield mentors a group of founders at CDL Toronto

And CDL’s ambitions haven’t stopped with startups. They’ve added a program specifically designed to get more high school girls into entrepreneurship, created streams for everything from space to cancer research, and expanded beyond Canada’s borders to the US, UK, France and Estonia. Of course, there have been some growing pains along the way, but the core mission of CDL — to “Build Something Massive” — continues to strike a chord with many across the Canadian ecosystem.

Being back in person for CDL after two years of Covid — two weeks ago in Montreal and last week in St. John’s — reminded me of how special Creative Destruction Lab really is and what a game-changer it’s been for Canada.

I can’t wait until next year.

Applications are currently open for CDL’s 2022/23 cohort. Click here to learn more and apply.

Wow, Did My Pitch Deck Suck

Since becoming an investor, I’ve reviewed thousands of startup decks and helped hundreds of founders prepare their pitches. But long before I was a VC, I cofounded DataHero, the world’s first cloud BI company. I recently came across one of our old fundraising decks and boy, did it suck!

Let’s take a trip down memory lane and look at all the mistakes we made in that deck.

I’ll review the deck in two passes:

1. A Slide-by-Slide Review

2. An Overall (Holistic) Review

After that, I’ll conclude by sharing what the outcome of the round was.

---

Note: This deck is for a $3.5M “Series A” that we raised in late-2013, following a $965K “Seed” round in 2012. By today’s standards (for both company stage and round size) this would be considered a Seed round (with the prior fundraise our Pre-Seed).

As such, the feedback and recommendations in this post are from the perspective of a Seed investor reviewing a Seed deck.

---

Here is the full deck for DataHero’s 2013 fundraising round. Flip through it and then we’ll review it in detail…

Slide-by-Slide Review

Let’s start off by going through the slides one-by-one:

Title Slide

DataHero was founded at a time when tongue-in-cheek interfaces were quite popular (e.g. MailChimp had monkeys all over). Our branding was designed around superheroes, with a mid-century look.

The title slide showcases the art style (which we thought was important given our focus on UI/UX) and the background suggests that DataHero is some sort of an analytics product.

The one mistake in this slide is that we used our marketing tagline instead of describing our product and/or market, so it’s not clear what exactly DataHero is or who it’s for.

Slide #1

What did we put on our very first slide…? Another title slide! 🤦‍♂️

Having a subject title slide like this might make sense if you’re presenting at an academic conference or BigCo™️ event, but in a pitch deck it’s completely unnecessary/redundant.

(If we wanted our names as cofounders at the start of the deck, we could easily have put them in the actual title slide.)

Slide #2

Here’s the real first slide. The opportunity to grab the reader’s attention, like an explosion right out-of-the-gate in an action film.

So what did we do? We shared a company timeline — something that should generally be the second-to-last slide in a deck.

Oh…and the timeline didn’t have any user- or revenue-related achievements.

An effective first slide needs to have impact. It could describe the problem being solved and its scale, present compelling traction metrics, or show impressive customer logos. But it has to draw the reader in and make them want to learn more.

This…ain’t it.

Slide #3

This, on the other hand, is a pretty effective slide.

It frames the problem we were solving by showing the data sources that traditional BI solutions worked with (at that time, primarily on-premise databases and other software) and contrasts that with the many SaaS services BI software couldn’t connect to.

If I were to do anything different with this one, I’d try to find some numbers to quantify those services in some way (how many users do they have? how much do companies spend on them, etc.). We implied that it was a big market by including the size of the traditional BI market, but at that time it was still a leap of faith to quantify the opportunity for DataHero.

Slide #4

This is a strong, concise product statement.

The only way to improve it would be to add market sizing, such as:

“DataHero will be the platform that enables 5 million enterprise users to visualize their cloud data”

or

“DataHero will be the platform that enables enterprise users to visualize 100 PB of data locked away in cloud services”

Slide #5

This is another strong slide that answers one of the most important questions early investors have: “Why are you the team to win this market?”

In the case of DataHero, we were building a product focused on a new market: business users who relied primarily on cloud services and needed to better understand the data stored within those systems. We felt that our combination of a CEO with a background in enterprise data software, a well-known UX expert and a creative director who led design at a Sequoia-backed company through IPO perfectly positioned us to develop the right product for this market.

This slide resonated strongly with potential investors.

Slide #6

This was a placeholder slide for demos during in-person / virtual meetings.

There’s obviously no reason to include this slide in a deck being emailed to investors. That said, were we to remove it, we would have needed to add more screenshots of the product (which we should have done anyways, since this is the only screenshot in the entire deck…).

Slide #7

This is a relatively decent “what does your product do” slide, but in hindsight it would have been better if we had replaced the cutesy cartoons with actual screenshots and/or a flow chart describing the user journey.

Slide #8

User/customer quotes are great, but they’re always a bit suspect when they don’t include the name of the company where a user works.

I can’t recall why we didn’t include Ali’s company name here - likely we thought it was too small or unknown. Now that I’m on the other side of the table, I see it through a different lens: you should always include customer names / logos whenever possible (even if you don’t think it’s a “big” name), because it’s an actual customer and you can/should project pride around that!

Everyone has to start somewhere.

Slide #9

Ok, so I just said that user/customer quotes are great…

…but there’s no reason for them to span two slides.

These should be combined into a single slide (with company logos added to each).

Slide #10

This is the first slide in the deck that references traction.

As an investor, the fact that it took so long is going to make me a bit skeptical, especially given that the timeline slide told me that the public launch occurred at least three months prior. We should have gotten to this sooner.

As for the slide itself, one of the biggest questions we faced when raising our Pre-Seed was “would end users pay directly for a data product?” (the number of successful bottoms-up SaaS products was still relatively small at that time). The title was meant to answer that question. The thing is, almost none of the investors we spoke with about our Seed round had met us before - so we were answering a question that they didn’t ask.

As such, they interpreted this slide as us claiming that we had “proven” a market, when it was obvious that we weren’t anywhere close to product-market fit.

All registered users proves is that you’re good at marketing. It says nothing about what happens after signup - is the product actually what people are looking for..?

Slide #11

At first glance, this is a really strong slide. It’s a list of amazing logos of companies that were using our product.

Unfortunately, they represented free users, not paying customers (at the point we raised our Seed round, we had just started to figure out monetization and how to effectively separate our free and paid products).

That said, to a potential investor, this is likely an impressive enough list to result in a first meeting - if only to dig in deeper. At the time, several investors told me that this slide was what resulted in us getting a meeting. The problem was, when they inevitably asked us how many of these companies were paying customers, we would sheepishly say “zero…” which wasn’t a great look.

Slide #12

This is a relatively strong case study slide, with one exception: it’s also talking about free users rather than paying customers. And the wording makes that fact glaringly obvious to an experienced VC.

As an investor, anytime I see a case study slide without any reference to revenue or licenses, alarm bells go off. 🚨

This slide is effective at showing that “land-and-expand” was working for DataHero as a product, however (unbeknownst to us at the time), it also makes clear that we weren’t in control of it — it wasn’t yet working from a sales perspective.

All that said, at the Seed stage, this is still okay — because pricing can be fixed.

Slide #13

Ugh…another slide with “proven” in the title 🤦‍♂️

I’m not sure why we made this slide the way we did, but in our minds it was important to emphasize how cheap/scrappy/cash-efficient we were.

As a concluding/timeline slide, the bullet points are solid. As a team slide, this is underwhelming (because we don’t include any logos of where our employees previously worked).

Going back to my comment on slide #5 about investors wanting to know why you’re the team to win, anytime you show your team it’s essential to include key details about them. A picture is worth 1,000 words and the best way to do that is to add logos of prior employers, schools, etc.

Slide #14

Conceptually, this go-to-market strategy makes sense.

But as an investor, I’m screaming “where are the numbers?!?” The product has been in market for at least 3 months, slide #10 has fairly impressive registration numbers (at least, for those days), but there’s still nothing concrete about user behaviour, retention or — heaven forbid — revenue.

As an investor, the fact that we’re now on slide #14 and I haven’t seen anything on unit economics is setting off all sorts of alarm bells that nobody is actually using this product (and they’re certainly not paying for it).

Slide #15

This is an interesting product slide, but I immediately want to learn more:

• Which integrations were most popular?

• What are the retention/revenue metrics for each?

• What did you learn by attempting to attract a “diverse base of business users?”

For in-person meetings circa 2013, this was great (because we had answers to all of those and it would steer the conversation in a certain direction). By 2022 standards, this slide needs more depth.

Slide #16

There is literally no reason why this should be a separate slide (vs. combining it with slide #15).

Slide #17

This slide really frustrates me - as it breaks one of the cardinal rules of pitch decks: don’t mix two separate topics on a single slide.

The first section talks about predictors of usage (which hints at our retention / monetization strategy), while the second is about feature requests (or at least it reads that way - it was actually a really awkward way of explaining why the majority of our users didn’t connect a cloud BI product to a…you know…cloud service).

Oh…and still no depth to the numbers.

Some charts and substance around retention would have been great here. Also using plain english to explain that the 75% of users who weren’t connecting to SaaS services were doing so because they were uploading Excel files (from corporate data stores, services we didn’t support yet, etc.) and visualizing them.

Slide #18

Oh, look! Another roadmap slide.

All of this makes sense, but it’s frankly pretty in the weeds and could easily be combined with slide #14.

Slide #19

But wait! You haven’t seen enough roadmap slides yet? Let’s add one more… 🤦‍♂️

…and what is this one is entirely focused on? Product. Nothing about user numbers, revenue, or any other business metric. Just features and functions.

Interesting stuff to be sure, but by this point as an investor, I’m likely convinced that there are zero active users, zero revenue and I’m skeptical that there’s any plan whatsoever for sales and marketing. Typical technical/product founders building a product without talking to customers…

(The worst part is, we had tons of data from talking to early users and customers, but we weren’t showing it!)

Slide #20

Slide #20.

The second-to-last slide in the entire deck is the first and only time we used the word “revenue”.

FFS.

And even then — this slide shows projections for 2014 and beyond, but there is still no information whatsoever on the revenue DataHero had achieved to-date.

Looking back at my records, at the time of our fundraise our revenue was pretty paltry (we had about 20 paying customers generating around $500/mo in revenue), but it was something. To think that we could “hide” it from potential investors was beyond naive. Even for an early startup, you have to talk about revenue.

In our case, while our revenue was minimal, we actually had a strong free user base and had learned an incredible amount around usage patterns (hinted at in slide #17). The revenue was a lagging indicators because we had the wrong “premium” features at the time — something that’s fairly common for early startups. We should have leaned more into the data we had, rather than shying away from the revenue we felt that we didn’t have.

Slide #21

The final slide: the ask!

…this slide makes me cringe every time I look at it.

It makes two big mistakes:

1. It doesn’t include anything about what we’re going to achieve with the fundraise (how many users will we attract, how much revenue will we generate, etc. with the funding)

2. It positions $3M / $3.5M as already secured.

The former is a very common mistake in pitch decks. Founders talk about what they’re going to spend the money on, but not the milestones they’re going to achieve with it. Investors want to know what your plan is for the next 12 - 18 months to understand how you will de-risk the business and position it for a subsequent raise.

The latter point is one where I know we made a big strategic mistake.

Foundry Group, who led our first round, had shared their conviction in DataHero and offered to take down the entire seed round. We wanted to test the market, but didn’t know how/if to leverage Foundry’s offer with other investors.

We thought that we could gain leverage by bragging that “our existing investors think DataHero is so awesome they’re willing to put another $3M in!” but by including it in the deck the way we did, I believe a significant number of investors passed without a meeting because they presumed the lead to be secured. They thought we were looking for a relatively small amount of money to close the round (which wouldn’t achieve their ownership targets) and passed immediately.

Overall Review

Now that we’ve gone through each slide one-by-one, what are the key takeaways?

The Good

Despite the title of this post, there were certainly some things we did right:

• The design of the deck was clean and did a good job of reflecting our brand and approach. (There continues to be a healthy debate around whether or not a pitch deck needs to “look good” — I am firmly of the belief that if UI/UX is a key part of your value proposition, the answer is 100% “yes.”)

• We did a good job of answering the question “why are you the team to solve this problem?”

• We presented the opportunity effectively by contrasting the world today (BI for on-premise data stores) with the world of tomorrow (BI for cloud-based services).

• We presented the key features in an easy-to-understand manner while making clear that there was real tech under-the-hood.

• We had strong customer quotes in support of the product.

The Bad

By far the biggest overall issue with our pitch deck was the complete lack of metrics. Despite the fact that we were only a few months into market and had almost no revenue, we had a significant amount of data around usage patterns and user retention. At a minimum, we needed a revenue slide (since every investor immediately asked about it), but in reality we could have done a lot to support our progress towards product-market fit by including user data — and we had a ton of it. By committing the sin of omission, we left potential investors free to assume the worst: that we were a heads-down product-centric startup that was good at getting registrations, but not at building a product users actually wanted.

In hindsight, the lack of screenshots was another obvious omission. DataHero was a gorgeous product with a UI that blew away every other BI tool at the time, yet we leaned on illustrations instead of showcasing the product itself.

A third missing piece was a competitive slide. We alluded to legacy competition in slide #3, but there’s no mention of any other analytics tools for SaaS services (DataHero was the first horizontal cloud BI tool, but there were service-specific tools already in market at the time, such as Baremetrics for Stripe).

Ironically, we had all of these slides — we just held them back them for after the first meeting. What we didn’t realize at the time (which I now clearly know), is that by holding back key parts of the story, we lost a lot of potential investors who never opted in to meet us.

In addition to the points above, the overall flow of the deck could be significantly improved. We should have led with the problem statement and market instead of starting with history to make sure we were hitting hard from the start. Revenue/traction definitely should have come earlier and with far more depth. Investors want to know what you’ve achieved (no matter how early in your journey you are), so don’t bury the lede!

This tweet from Paul Graham sums it up nicely

Finally, the deck was way too long. A good Seed deck should be 10 - 12 slides long (14 slides max). In our case, a number of the slides could easily have been combined, which would have made the deck far more concise and impactful. If all the user data we didn’t include made the deck too long, we could have put those slides into an appendix without sacrificing flow.

The Ugly

Including Foundry’s verbal commitment on the slide deck was a monumental error on our part. Instead of having the intended effect of demonstrating strong support from our existing investors, it gave the misconception that the lead investor was already decided and we were only looking to fill out the round.

So What Happened?

In October 2013, we launched our fundraising campaign, with our investors supportively sending out introductory emails to everyone on our target list. A significant majority declined those introductions, which I now believe to be in large part due to (a) the lack of metrics in our deck and (b) the manner in which Foundry’s verbal commitment was framed.

We still met with a good number of investors, several of whom went deep into diligence. Ultimately, the fact that we were so early into monetization at the point of fundraising was a challenge for net new investors (particularly given the amount we were looking to raise). After a few weeks, we pulled the plug on our process and finalized the internal round with Foundry leading:

DataHero Raises $3.1M and Revamps its Analytics Service

- GigaOm, December 10, 2013