VC-Funded SaaS Startup: Valuable Lessons from Intalayer's Journey [Case Study]

This is the story of how we founded and ran a venture capital (VC)-funded SaaS 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.

However, we recently made the difficult decision to close down Intalayer.

This is quite a detailed story of our journey,  but we believe in transparency and that lessons lie in these details.

If you’re a former, current or aspiring founder, we hope this benefits your journey. 

Let’s start with our basic stats: 

Founders: 3

Fundraising: $480,000 (AUD)

Operating timeline: 19 months

• V1: April 2020 - April 2021
• Pivot: April 2021 - May 2021
• V2: May 2021 - November 2021

Next, let’s dive into what we learned.

10 Valuable Lessons We Learned From (And You Can Too)

Of the countless lessons we learned, these 10 shape our SaaS startup story.

1. About Our Founding Teams: Don't undervalue the energy a co-founder brings to a founding team. Founders cannot rely solely on intrinsic motivation when facing months or years of challenges and setbacks. Co-founders must energize each other.
   
2. About Our Founding Teams: Co-founder vulnerability is a strength. Like any great, long-lasting relationship, co-founders have to be emotionally transparent and honest. The more you share, the more you can support each other.
   
3. About Problem Spaces: 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.
   
4. About Problem Spaces: Some painful problems are very difficult to solve. Aim to understand the ecosystem deeply you’re operating in and seek out “contained” problems instead.
   
5. About Solutions: 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.
   
6. About Solutions: Try to manually solve the problem before coding anything. 
   
7. About Feasibility: 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. 
   
8. About Feasibility: 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 realize value.
   
9. About Difficult Times: 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 repeating mistakes. A startup is as much about growing yourself as it is about the business.
   
10. About Difficult Times: 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.

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

Antler Startup Program Origin

In January 2020, we joined Antler Australia’s startup generator program. 

Antler is an early-stage venture capital (VC) firm that also supports new generations of entrepreneurs through a startup generator program. 

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

Our cohort was made up of the following:

• 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, and Ph.D. scientists.

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

We all had the drive to find compatible co-founders, start a technology company, and pitch for pre-seed investment from Antler.

Forming our founding team

The 10-week Antler program 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.

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

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

It felt like a huge win.

The problem we set out to solve

We recognized that as software companies start to grow rapidly, communication and collaboration become increasingly inefficient between R&D (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.

We identified that this problem was most acute in software companies pursuing product-led growth through extensive research.

Product-led growth relies on using a company’s product as the main vehicle to acquire, activate, and retain customers. Product-led Growth guided the success of companies like Zoom, Slack, and Dropbox.

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.

This includes

• 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.

Quantifying the impact of this problem:

• 89% of B2B and B2C software companies say it is not easy to gather and organize customer feedback.
  
• 63% of companies say there is no clear communication and collaboration between the R&D and customer-facing teams.

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.

3. Our vision

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

4. Ideal customer profile

We defined our ideal customer profile as:

• Software companies pursuing product-led growth.
• Between 50 and 200 employees.
• Formalized R&D and customer-facing teams.
• Recently entered a period of significant growth driven by:
  • The 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.

5. Identifying Customer Support as our beachhead

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.

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

In many cases, Support leaders are 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.

6. Our initial value proposition and solution

Our initial value proposition and solution were based on the four core jobs 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.
• Contextualize: Consolidate customer data from tools like Salesforce, Gainsight, and Jira to contextualize the feedback.
• Analyze: Assess if the feedback could impact business goals and prioritize the feedback that could have the greatest impact.
• Advocate: Present the prioritized feedback in a compelling way to R&D teams to inform product decisions.

Here's a quick look into the product:

(Demo video highlighting how our beta product helped Support leaders)

7. Building a waitlist and launching our beta

We engaged 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 worldwide.

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.

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

8. Encountering challenges with acquisition and onboarding

Despite validating our priority ‘Desirability’ hypotheses, 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.

Let’s take a deeper look into why some of these were invalidated. 

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

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. Intalayer integrated with Salesforce to contextualize and prioritize feedback based on customer data like annual contract 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.

To acquire customers, we had to meet their requirements. Initially, this led to immediate rejection by high potential customers.

Most worryingly, we faced these challenges before Intalayer could deliver any value. We had very limited testimonials and social proof to build confidence.

We believe Support leaders will drive their Support agents to adopt the Intalayer Zendesk app in their workflow: Invalidated

While Support leaders were undeniably excited by our proposition and the impact Intalayer could have, it was clear that their priority was still the daily productivity of their Support agents. Therefore, Support agent workflows have often been finely optimized by Support leaders and Support Operations specialists.

This created an adoption and onboarding challenge as, to see value in Intalayer, Support leaders would first need to drive change in their agent workflows.

Similar to Security objections, we had limited testimonials and social proof to build confidence in the benefits that Intalayer would bring. 

While we successfully built confidence in the Support leaders that joined our beta, the in-person guidance needed to convert and onboard each beta customer highlighted a scalability risk for us.

We believe Support leaders will influence Jira admins to install the Intalayer app on Jira without needing buy-in from Product leaders: Invalidated

Majority of conversations where Support leaders expressed excitement in Intalayer ended with “I’d like to run this by our product leads to get their buy-in on the approach.”

While Intalayer’s proposition filled Support leaders with optimism, this optimism was quickly replaced with trepidation when faced with the reality of the next steps to onboard our beta.

This indicated cultural challenges that would be difficult to overcome.

???? Ironically, despite targeting product-led companies, selling Intalayer required an Enterprise sales approach. The barriers to moving to a self-service model put us at risk of landing in the ‘Startup Graveyard.’ 

We believe Product leaders will agree feedback items prioritized by Support leaders using Intalayer should be investigated further: Invalidated

Product leaders need to consider feedback from all customer-facing teams when deciding what feedback to investigate further.

This objection further decreased Support leaders confidence that Intalayer will help them to advocate for customers effectively and inform product decisions.

We believe most companies fitting our ideal customer profile use Zendesk, Jira, and Salesforce: Invalidated

For Intalayer to deliver the value promised in our value proposition, customers needed to use Zendesk, Jira, and Salesforce.

While these tools are widely used across companies fitting our ideal customer profile, there was a much lower probability that a company used all three.

To deliver the value planned in our product roadmap, we would also need to integrate with customer success and analytics tools. 

9. Identifying a new target buyer and user - Product Operations

After 7 months of iteration and testing, we decided to make fundamental strategic changes.

During our Customer Development process, we learned about a promising role that first emerged in leading Silicon Valley product-led companies and quickly spread globally – Product Operations.

Product Operations is an operational function within a Product team that helps the Product team build better products. Alongside other activities, like managing Product team tools and experimentation, Product Ops is responsible for helping Product leaders make more reliable decisions by equipping them with data.

Our secondary research highlighted that customer feedback from Support, Success, Sales, and Marketing teams was a priority source of data. With this learning, we defined an initial hypothesis. 

We quickly planned research surveys with ~50 Product Ops leaders and interviewed ~20.

We learned that Product Ops leaders are often highly analytical but rely on manual analysis across various tools from Excel to Tableau to collate, contextualize, and analyze customer feedback. They often searched for ways to automate these jobs.

This validated our initial hypothesis.

Evolving our solution

Interviews with Product Op leaders built our confidence that we had identified a significant pain they would pay to solve and that our solution was compelling.

Product leaders need to consider feedback from all customer-facing teams when deciding what feedback to investigate further.

For Intalayer to deliver value to Product Ops leaders, our solution would need to collate feedback across all customer-facing teams.

We began designing evolutions to our solution to solve this gap in existing Product tools and collate feedback across all customer-facing teams.

10. An evolving competitive space with high entry barriers

Unfortunately, these existing tools announced evolutions in their products, propositions, and roadmaps. They were evolving to meet the needs of Product Ops leaders and capitalize on the opportunity to improve how R&D and customer-facing teams work together in product-led companies.

While we were pleased we had arrived at the same conclusion as major players with greater access to the market, this also presented a major risk for us.

In further interviews with Product Ops leaders, we tested evolved solution prototypes. We received concerning feedback:

• “How is this different from where Productboard is heading?”
• “Why would I switch from Productboard to Intalayer?”
• “If Intalayer also did X, I would consider testing if it works better for us”

What previously appeared as a gap in the market, had evolved into a space with high competitive barriers to entry.

11. Time to pivot

The overarching and most significant challenge we faced was that we hadn’t focused on a 'contained' problem to solve.

We realized our previously defined problem and solution covered numerous interconnected jobs-to-be-done, processes, and teams.

These factors meant we had been focused on a more “wicked” problem that is much harder to solve. 

This was a significant risk for an early-stage startup that should be focused on developing the best solution to a contained problem in a market niche.

A modular approach

"While we remained committed to our vision and ideal customer profile, we decided to define and focus on a contained problem within the broader space we had been operating in. We defined four contained problems that could be solved and deliver significant value to Product Ops leaders in product-led companies."

To focus, we decided to select one contained problem to solve first. Our ambition was to then sequentially solve the remaining three problems. 

Prioritizing contained problems

We re-interviewed our Product Ops contacts to validate the contained problems against the following criteria.

• Can we very clearly describe the problem in granular detail?
• Can the negative impact of the problem be quantified and measured in isolation?
• How painful is each problem relative to the other?
• How important is solving the problem relative to their full role and responsibilities?
• Do we have evidence that target buyers are willing to pay to solve the problem?
• Is the problem experienced consistently across companies? (Problems that aren't consistent might not have a scalable solution)

12. A new contained problem: qualitative feedback analysis

Through these interviews and our assessment, we discovered the most promising contained problem:

???? Product teams in fast growing product-led companies do not have an easy way to analyse and find actionable insight in qualitative customer feedback.

We learned that Product Ops leaders and Product Managers and Design Researchers spend days every month manually analyzing qualitative feedback.

Particularly challenging are open-text responses received across sources, including:

• NPS & CSAT surveys
• In-app surveys

A common example is open-text responses to NPS questions like:

The ‘Thematic Analysis’ process is manual, time-consuming and frustrating but is seen as a necessary step to identify problem statements.

13. Our new solution 

Through an intensive Design Sprint process, we designed multiple potential solutions. We applied strict constraints to ideation based on previous customer acquisition challenges.

1. Solution must not use Personally Identifiable Information (PII).
2. It must be possible for only one individual to discover, test, and realize value.
3. Solution must not require any workflow change before it can be tested.
4. Solution must not have to integrate with other tools before value is delivered.
5. Solution must demonstrate value in less than 30 minutes from when the solution is discovered.
6. Solution must provide measurable value within a user’s first session.
7. Solution must be compatible with or complement existing tools such as Productboard, Aha, and Canny.

Potential solutions were tested with 15 target customers from product-led companies.

We identified the solution with the greatest demand. 

The Intalayer Google Sheets app

Our proposition was focused on time-to-value. With Google Sheets, Intalayer could analyze any CSV export from well-known survey tools.

By focusing our solution around the Google Sheets platform, we avoided integration and multiple stakeholder buy-in issues we had encountered previously.

(New demo video of the Intalayer Google Sheets app)

We positioned Intalayer as a lightweight, lower cost, faster time-to-value alternative to Qualtrics and Chattermill. These are enterprise-focused products with a broad feature set and require significant setup before performing accurately.

Within one month, we built a waitlist of 100 product-led companies eager to test our beta product.

14. Technical feasibility challenges faced delivering a proposition

Despite the confidence we gained from building the beta waitlist, we began to encounter technical challenges throughout solution development and testing.

The most significant market risk was that demand for a solution was based on the perceived accuracy of the automated Thematic Analysis.

Having used existing automated tools and perceived them to be of low quality and accuracy, target customers were skeptical, had high expectations, and low tolerance for inaccuracy.

This led to the challenge of Intalayer needing to meet high expectations while solving a complex problem.

Technical challenges and solution evolution

Version 1:

Our initial solution was an interactive Word Cloud designed to help customers explore the most common words appearing in feedback at a high level.

However, trial customers did not perceive this as valuable as common words may not be contextually relevant or nuanced to the subjects related to their business. 

Version 2:

V2 was an interactive table of extracted subjects, showing count and sentiment. Trial customers could "dig deeper" into subjects by clicking on a subject and then clicking on associated words, automatically filtering feedback that contained the subject and associated words. This user experience was still largely manual and ultimately didn't sufficiently ease the burden of reading through every feedback item to identify high-level and low-level themes.

Version 3:

Through more user research and previous product iterations, we noticed common patterns in how our target customers' end-users provided feedback in surveys. 

v3 used a form of grammar matching and subject extraction and extracted low volumes of 'useful' themes. However, as more extraction patterns were added, volume increased, but accuracy and quality of themes decreased significantly. We quickly lost confidence in this solution's ability to quickly scale to an accurate and reliable product.

Version 4:

V4 aimed to create themes by clustering high "importance" snippets of information based on "similarity." Ultimately, we were unable to create such a complex solution to a high degree of accuracy.

Key overarching challenges that emerged

• The MVP to enter the market and meet expectations was complex and required NLP experts and R&D effort extending beyond our runway.
• There was no scrappy way to deliver value against target customer expectations.
• The complex nature of NLP products which requires R&D effort to make significant improvements, decreased the chance of creating fast feedback loops for quick product iteration.
• Given the technical complexity, there were likely 'unknown unknowns' and solution roadblocks that we couldn’t imagine.

15. A new go-to-market strategy: Rapid Reports

Given the complexity, we decided to implement a “Service as a Product” strategy in the form of a Rapid Report. Customers would provide us with raw feedback data. Within 24 hours, we would deliver a complete report using a combination of our Google Sheets app and manual effort to shortcut the process. 

Our goal was to deliver a recurring service where target customers would share their feedback data every fortnight or month, and we'd conduct the analysis.

Although we generated revenue by creating reports for three unicorn product-led companies, the Rapid Report service quickly ran into challenges.

Key overarching challenges that emerged

• Customers wanted a self-serve solution and only agreed to Rapid Reports as an interim value add. They weren’t willing to commit to recurring agreements.
• Companies had internal resources available (e.g., Product Ops team, Analytics team, Design Research team). They were unable to secure a budget for an external party to conduct the analysis, as opposed to a self-serve tool that could augment their capability.
• Companies that didn't have internal resources lacked the required volume of feedback to perceive a significant pain and justify outsourcing feedback analysis.

16. Co-founder departure

At the end of September 2021, after nearly two years of hard work, the challenges we faced left us with no clear path forward in the company and a dwindling capital runway.

Because of this, Dain decided to leave Intalayer.

17. Assessing our position and direction

We totally understood Dain’s reasons. We agreed we needed to take another step back to assess our position and direction.

At a high level, we had two options:

1. Pivot inside our current problem: Explore new approaches to overcome feasibility challenges.
   
2. Pivot outside our current problem: Turn our attention to the other contained problems we defined or a problem we experienced while building Intalayer.

18. Deciding to close down

We decided to pivot outside the qualitative feedback analysis problem space. 

Our biggest consideration was respecting our investor relationships. Our investor and advisor network is invaluable, so we wanted more than anything to protect our professional and personal relationships with them.

Some of our investors backed us, the team. Others backed the problem space. Because of this, we believed that it wouldn’t be fair to use investor cash until we could validate a path forward.

So, we decided to stop taking a salary from Intalayer. We believed it might be best to return the remaining cash to investors and reconnect with them in the future when we have an investible opportunity.

We realized:

• It takes founder energy to get a rocket into orbit.
• We were worried we wouldn’t be able to give opportunities the energy they need without recharging first.
• Recharging is difficult without financial security.
• We’re in no rush. When we’re ready, we want to thoughtfully and diligently apply our learnings with clear minds and full energy.

19. Did we fail?

This is a difficult and painful question, likely with no right or wrong answer.

But, here’s our answer:

???? Intalayer might have failed, but we haven’t.

We believe that failure is never pursuing a dream or giving up that dream.

We are proud of ourselves for taking a risk, trying, facing repeat challenges but always trying again and again.

Over two years, we had long, painful periods with no wins that felt like a grind. To get through them, our mindset became:

???? If we keep trying every day, we win every day.

Now, despite Intalayer ‘failing’, we have many exciting opportunities and still have the same ambition as when we started the Antler program.

So, we will recharge and try again. And that, in itself, is succeeding.