top of page

Two years as a VC backed startup

Author: Written by Michael Wendland and Ian Glass, co-founders of Intalayer

This is the story of how we founded and ran a VC backed startup and why we decided to close down.

The past two years as startup founders have been the most intense, exciting and emotional learning experience of our lives.

Recently, however, we made the difficult decision to close down Intalayer.

We want to thank our 3rd co-founder, Dain, our early employees, investors, customers and everyone who supported us.

Now, we can reflect on our experience with the clarity of hindsight, recognise what we achieved and crystallise our learnings. We hope that learning from our mistakes will increase our probability of success when we start another company.

This is quite a detailed write up but we believe in transparency and that lessons lie in the detail.

If you’re a former, current or aspiring founder, we hope our story will benefit your journey. Please contact us (Michael & Ian) if you’d like to ask any questions directly.

10 hard lessons we learned

💡 Of the countless lessons we learned, these 10 stand out as shaping our story

Lessons about founding teams

  1. Don't undervalue the energy a co-founder brings to a founding team. When facing months or years of challenges, setbacks and tiredness, founders cannot rely solely on intrinsic motivation. Co-founders must energise each other.

  2. Co-founder vulnerability is a strength. Like any great, long lasting relationship, co-founders have to be emotionally transparent and honest. No-one in your life will understand what you’re going through like your co-founders. The more you share, the more you can support each other.

Lessons about problem spaces

  1. The problem you see or hear is rarely the problem that needs to be solved. Look deeper and ask ‘why’ to uncover root causes. Once the problem is correctly identified and understood, it is much easier to design a valuable solution.

  2. Some painful problems are very difficult to solve. ‘Wicked’ problems can have multiple stakeholders, be tangled with other problems and have roots in cultural challenges or conflicting human behaviours. Aim to deeply understand the ecosystem you’re operating in and seek out ‘contained’ problems instead.

Lessons about solutions

  1. ‘Time to value’ is the most important metric startups should design for. As an unknown entity, your target customers will have low confidence in your ability to change their lives. Focus on delivering value to them as quickly and effortlessly as possible.

  2. Try to manually solve the problem before coding anything. If you can repeatedly solve a problem manually and prove target customers are willing to pay, you will: understand the problem deeply, reduce risk and build confidence in how to gradually automate and productise a solution.

Lessons about feasibility

  1. Be cautious if veering outside your team’s areas of expertise. Don’t fall victim to the Dunning–Kruger effect and overestimate your ability to succeed in an unfamiliar industry, competitive ecosystem, problem space or task. Engage experts quickly to reveal ‘unknown unknowns’, plan for the ‘known unknowns’ and accelerate work on the ‘known knowns’.

  2. Don’t chase the ‘asymptote of death’, a target you get closer and closer to, but can never reach. Learn quickly how complete or accurate a solution needs to be before a target customer will realise value. If feedback leads your solution to become increasingly complex, before it can be perceived as valuable, consider changing approach or whether the problem is even solvable with your resources.

Lessons about difficult times

  1. Turn previous mistakes into constraints and criteria to guide future decisions. If you compound the knowledge you gain, you’ll continually make better decisions. This will help you evolve or pivot with confidence and avoid making repeat mistakes. A startup is as much about growing yourself as it is the business.

  2. Don’t allow failures to make you feel like a failure. There will be challenges, setbacks and even long periods of grinding without significant wins. Defining yourself by your company’s success will increase your suffering in difficult times. 💡

  1. Continue to our full story below and read how our experience taught us these lessons.

Our Origin in the Antler Startup Program

In January 2020, we joined Antler Australia’s startup generator program. We had never met before. Now, that feels like a lifetime ago.

Antler is an early-stage venture capital firm that also supports new generations of entrepreneurs through a startup generator program. Imagine a combination of Dragon's Den, The Apprentice and Love Island.

80 individuals from a broad range of backgrounds were brought together for a 10 week program in Sydney.

Our cohort was made up of:

  • Technology Leaders: software engineers, data scientists and machine learning experts

  • Business Leaders: management consultants, product managers, marketers, sales and operations experts

  • Domain Leaders: experts in financial services, healthcare, energy, corporate HR as well as Ph.D scientists

Antler also carefully selected a cohort that represented a diversity of cultures, genders and life stages.

Despite this diversity, the three things we all had in common were the drive to; find compatible co-founders, start a technology company and pitch for pre-seed investment from Antler.

This felt like a once in a lifetime opportunity.

Forming our founding team

The 10 week Antler program was was defined by three main goals:

  1. Find co-founders and form a team

  2. Validate a problem and gather early evidence of a business model that could represent a big market opportunity

  3. Pitch as a team for pre-seed investment

Our program started on Monday 13th January 2020. The first two weeks were made up of founder skills training and daily Design Sprints with mini-pitch challenges. In week 1, Antler defined the daily challenge topics and structured the cohort into new cross-functional teams of 5-10 individuals every day. The goal was to help us meet and work with as many potential co-founders as possible, as quickly as possible.

In week 2, we defined our own challenges and picked our own teams. It may sound ruthless, but we needed to mentally eliminate members of the cohort so we could focus the following weeks on working with the most compatible potential co-founders.

One Antler partner likened selecting compatible co-founders to how the military select special forces units, tasked with performing the most complex, classified, and dangerous missions.

We needed to select co-founders with; complimentary skills and experience that overcome individual weaknesses, personality types that energised us and character traits that we could commit to working with for the next 5+ years. Ultimately, we needed to trust relative strangers with our dreams and success.

Weeks 3-8 played out like a reality TV show with; co-founder courtships, tension, jealousy as potential co-founders still 'dated' other teams, the excitement of teams forming and individuals reeling from team break ups.

Antler often reminded us that the pressure was on because in week 8 there was a pre-investment committee pitch. Those without a co-founding team had a very low probability of being invited to pitch for pre-seed investment and teams without a validated problem or compelling solution might also not be invited.

We (Dain, Ian and Michael) were one of the last cohort teams to form, one week before the pre-investment committee pitch.

We had all been through team break ups but came together because of our complimentary skills and our shared experience with a common problem in fast growing software companies. Equally as important, we had compatible personalities and we energised each other.

Becoming a fully remote, global team

Based on our strong team, validated problem and compelling idea (covered in detail below), Antler invited us to pitch to the Investment Committee for pre-seed funding. We'd present to Antler Australia partners, Antler Global partners, Antler VC fund Limited Partners as well as a selection of Partners from other local venture capital funds.

However, only a few days before we pitched to the Antler Investment Committee, Sydney began to enter lockdown as the threat of Covid-19 spread.

Fearing difficulties eventually returning to his home and family in New Zealand, Ian decided to catch a next day flight to Auckland.

We were now a fully remote, globally dispersed team, operating across time zones.

Receiving pre-seed funding

On Tuesday 24th March 2020 we pitched to the Antler Investment Committee.

After an anxious wait, we were ecstatic to hear that Antler decided to invest in us.

It felt like a huge win, even though it was the very start of our journey together.

2. The problem we set out to solve

In our previous Product Management and Software Engineering careers, we recognised that as software companies start to grow rapidly, communication and collaboration becomes increasingly inefficient between R&D teams (Product, Design & Engineering) and customer facing teams (Customer Support, Customer Success, Sales, Marketing). This can cripple a company’s ability to make fast, customer centric product decisions, while delivering the best customer experience.

Through extensive research, we identified that this problem was most acute in software companies pursuing ‘Product-led Growth’.

Product-Led Growth is a go-to-market strategy that relies on using a company’s product as the main vehicle to acquire, activate, and retain customers. Product-led Growth is the strategy that guided the success of companies like Zoom, Slack and Dropbox. What makes ‘product-led’ companies unique is that all teams leverage the product to hit their goals.

In product-led companies, efficient data sharing, transparency and communication between R&D and customer facing teams is essential to drive growth. Support, Success, Sales and Marketing teams should inform product decisions and receive product information that supports growth initiatives or helps improve the customer experience.

  • Essential data passed from customer facing teams to R&D: customer usability issues, software bugs, new feature requests, sales objections, product improvements to drive growth and market insight

  • Essential data passed from R&D to customer facing teams: product knowledge and benefits, use cases, product roadmap, product fixes and new feature releases

The big problem in product led-companies is that the excitement of rapid growth leads to scaling pain:

  • Customer growth accelerates

  • More product teams are spun up to work in parallel

  • Products become increasingly complex

  • All R&D and customer facing teams expand headcount

  • Teams work across different systems and tools

Soon, silos emerge and processes that were once effective fail. Essential data sharing, transparency and communication between R&D and customer facing teams breaks down.

Quantifying the impact of this problem:

  • 89% of B2B and B2C software companies say it is not easy to gather and organise customer feedback.

  • 63% of companies say there is no clear communication and collaboration between the R&D and customer facing teams. (Source: 2019)

Ultimately, R&D teams in these companies cannot make customer centric product decisions and customer facing teams cannot leverage the product.

  • The result is 80% of released product features are rarely or never used. (Source: 2019)

Our Vision

Our vision for Intalayer was to become ‘The operations platform for product-led companies’.

We wanted to build the operations layer to enable efficiency between R&D and customer facing teams in rapidly growing product-led companies.

Ideal Customer Profile

We defined our ideal customer profile as:

  • Software companies pursuing product-led growth

  • Between 50 and 200 employees

  • Formalised R&D and customer facing teams

  • Recently entered a period of significant growth driven by:

  • Organic surge in demand: including demand triggered by influences such as Covid-19

  • A recent capital raise: most likely Series A or Series B

  • Rapidly hiring across R&D and customer facing teams, especially for operations roles

Identifying Customer Support as our beachhead

Due to the nuances in communication and collaboration needs between R&D and different customer facing teams, we identified a ‘beachhead’ to guide our go-to-market.

Our initial focus was the inefficiency in communication and collaboration between Customer Support and R&D teams.

The reason for this focus was that, from our research, we identified the pains of scaling are most intense for Support teams. Inefficiencies threaten the primary KPIs of the Support team and leave them feeling unheard, undervalued and under-utilised.

As customer growth accelerates, the volume of customer feedback received by Support teams surges from dozens of ‘items’ a week, to hundreds, to thousands. Overwhelmed by volume, Support leaders are unable to easily collate the customer feedback trends they need to advocate for customers and inform product decisions.

They can spend days every fortnight sourcing customer data across disparate Support, CRM, Customer Success and analytics tools, in an attempt to build strong business cases for R&D teams to resolve issues and requests quickly, or to investigate root causes that will reduce support volumes.

In many cases Support leaders are simply trying to stop their teams from buckling under pressure and they do not have the time or resources to effectively advocate for customers to R&D teams. This leads to unresolved customer needs and Support leaders feeling they have ‘lost their seat at the table’.

We decided this specific problem would be our starting point.

Our ambition was that once we successfully solved the problems between Support and R&D, we would expand to sequentially enable efficient operations between R&D and Customer Success, Sales and Marketing teams.

6. Our initial value proposition and solution

Our initial value proposition and solution was based on the four core ‘jobs to be done’ that Support leaders have to complete when building business cases to advocate for customers.

  • Collate: Collect and collate all customer issues and requests into one place and group by similarity

  • Contextualise: Consolidate customer data from tools such as Salesforce, Gainsight and Jira to contextualise the feedback

  • Analyse: Assess if the feedback could impact business goals and prioritise the feedback that could have the greatest impact

  • Advocate: Present the prioritised feedback in a compelling way to R&D teams to inform product decisions

Framing hypotheses to test

Our solution and go-to-market strategy was based on a number of assumptions that we framed as hypotheses to test with our prototype and beta products.

7. Building a waitlist and launching our beta

We focused on engaging with Support leaders in companies fitting our ideal customer profile to test our hypotheses and acquire companies to join our private or public beta.

Through a combination of direct outreach, community engagement and content marketing, we arranged conversations with dozens of Support leaders from leading product-led companies around the world.

Through these conversations, we validated our priority ‘Desirability’ hypotheses.

We started to grow a waitlist of Support leaders excited by our proposition and the impact Intalayer could have.

From this waitlist we successfully onboarded 10 private beta customers from Australia and the USA.

Encountering challenges with acquisition and onboarding

Despite validating our priority ‘Desirability’ hypotheses, while working to acquire and onboard our first beta customers, we encountered common sales objections and worrying patterns in our sales cycle and onboarding process.

These objections and patterns invalidated most of our ‘Viability’ and ‘Feasibility’ hypotheses.

We believe Support leaders have decision making authority to install the Intalayer app onto Zendesk without approval from additional stakeholders - Invalidated

Security objections

The Intalayer Zendesk and Jira apps used an NLP algorithm to automatically analyse the content of Support tickets and Jira ‘issues’, then match and group them by similarity. Additionally, Intalayer integrated with Salesforce to contextualise and prioritise feedback based on customer data such as; annual contract value and strategic value.

While highly desirable, these features required Intalayer to store Personally Identifiable Information (PII). Perceived data privacy risks led to Support leaders needing to seek approval from Security and Legal teams.