1 year of building a new product analytics tool

Introduction

It's been 1 year since we first invited a few friends to try out Squeaky, a privacy-friendly session recording tool we'd been piecing together for a few weeks. It was an incredibly basic product, but Squeaky was born(!), and that makes August 2022 Squeaky's 1st birthday.

We thought we'd mark the occasion by writing down what 12 months of building the Squeaky product has entailed. It's not been easy, especially as there's only 2 of us, but it's surprising how much can be achieved in 12 months!

This isn't a 'How To' article, or anything about growth and marketing, this is about 1 year of product development and evolution.

Squeaky's origins: There's a decent chance you've come across this blog post but haven't yet heard of Squeaky…we're only 1 year old after all! If you'd like to know more about our mission visit our About Us page here.

The 5 phases of Squeaky's first year

Proof of concept

When starting a new project people often use a proof of concept (POC) to validate that there is a market for their idea, test technical feasibility, or to attract investment. During the proof of concept phase people are trying to prove that an idea is valuable, and/or that it is deliverable.

In our case, we were less concerned about market validation. We were entering a diverse and established market, with other players already building exciting new businesses in the privacy-focused analytics space. Naturally there are separate concerns when entering an established market, but during our POC phase we were more concerned about technology.

This wasn't because the problems we faced were inherently unsolvable, but due to time constraints, and the fact that only one of our two-man founding team was an engineer, we knew we'd need to rely on some existing libraries to deliver on our goals. We decided the most important questions to answer were:

• Could we find a reliable open source library that would help us capture session data during a user's visit to a website?
• Could we then pair that with client-side data masking, and avoid the need for cookies and IP tracking?

At this stage we didn't care about the user experience or product-market-fit. If we could validate these two problems were solvable, we could commit to tackling the problem.

In practice, this was much quicker than we'd anticipated. Within a few evenings we had found or developed the required tech to answer both questions with a resounding yes; the technology did work, and could work.

Why use a POC? Because you should always test some of elements of your project before going full steam ahead. I've read so many horror stories about people who've gone headlong into a 12 month project before realising they'd bitten off more than they could chew. Or, built in the dark, failing to validate a simple POC with their target audience, it turned out nobody wanted what they'd built.

A proof of concept protected us from the first of those problems. It encouraged us to stop and ask fundamental questions about our project's viability, formulating simple tests we could run that helped us to build the confidence we needed to commit to the project. The next step was to determine whether we could turn our idea into something people wanted and needed.

Minimum Viable Product

So, we knew we could make the technology work, but what did users actually want? That's where the MVP came in. 'MVP' stands for Minimum Viable Product, and it should be the most basic version of the core value proposition that could be built in order to get feedback from users.

The scope of an MVP will vary per project, but building the bare minimum features that would allow us to get actionable feedback from users was paramount - not getting caught up in aesthetics, or nice-to-haves. Bugs were to be expected, along with a fairly tame user experience, but the core value of the product needed to be tangible.

For Squeaky, the ability to capture the session data when people visit a customer's website or web app was always going to be the backbone of our product, so this is what we decided the MVP should include:

• Users can sign up and log in - even this is unnecessary for many MVPs.
• Users can add their site to Squeaky and generate a tracking code.
• Users can add the tracking code to their website or web app, and verify it's working.
• Data is collected in a table on a per-session basis.
• Users can click on any entry to play back a session.

At this stage we didn't really have any preconceptions about what the app should look or work like, and we ended up with some very basic screens like this:

Aside from a very narrow and precise scope, it was also important that we chose our first few users carefully. Picking the right users means you only really need 5-10 people to learn from at this stage, so these were our criteria:

• Find at least 10 people who would agree to use Squeaky's tracking code on their website and play back some sessions.
• The target users should have either (a) expressed the need for a tool like Squeaky but with no current setup, or (b) have direct experience using similar tools to support their business.

How long should the MVP testing phase last? In my experience that's really up to the specifics of the project at hand, but for Squeaky it took us about 4-5 weeks. This involved inviting 10 people, allowing them time to meaningfully engage with the product, and scheduling and undertaking interviews.

Building and testing Squeaky never really happened in independent, time-boxed phases. Interviews could take us weeks to schedule and often, rather than waiting until we'd heard from each participant, feedback from user interviews fed directly back into the product within days or sometimes just hours. These short feedback loops meant that Squeaky was evolving at a rapid pace, but that also made it hard to say when the MVP testing had ended. In hindsight, this made the whole process a bit scrappy.

Perhaps enthusiasm got the better of us, but it was also rational to prioritise momentum over a perfectly executed process. By the time we'd concluded testing our MVP we'd made lots of improvements already, and we knew the feedback we'd gathered offered a wealth of information and ideas that could materially shape where Squeaky went next.

It's worth saying though, that overall people didn't love the product yet. People were impressed with how easy it was to set up and liked that it was cookie-less. The consensus was that we needed to really expose the data in more meaningful ways that could better inform decision making or discovery.

Minimum Loveable Product

Not everyone uses the term Minimum Loveable Product (MLP) but I'm a big advocate, especially when it comes to new tools entering established markets - it's just not good enough to simply be 'viable'.

In the first article I came across on the subject, Laurence McCahill describes the MLP as the natural successor to the MVP, saying:

MVP = The version of a new product that brings back the maximum amount of validated learning about your customers with the least effort.

MLP = The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort.

Often the MVP just validates you're on the right path and provides a framework for driving the project forward. The MLP on the other hand should leave you with an array of positive signals that evidence that your end users are starting to love what you are building.

Based on the user feedback from our MVP testing phase, we earmarked the following opportunities to help us transition from viable to loveable:

• We needed to capture more data types within sessions and surface that data in new ways. Several users mentioned this and it aligned with our original thesis i.e. there are basic privacy-friendly web analytics tools on the market - we could differentiate by offering users a broader array of insights from the data they were capturing. For the MLP we decided this should mean adding Analytics and Heatmaps (and eventually, due to popular demand, that expanded to included user feedback widgets).
• We needed to add Visitor Profiles. Visitor data was anonymous in Squeaky - however, just because a person is anonymous it's still valuable to aggregate the data across their various sessions under one Visitor ID.
• We needed to add data-linking functionality. This would enable companies (who have the consent of their users) to de-anonymise visitors by linking important data from their own systems with the analytics data in Squeaky. This is something we'd avoided for privacy purposes but it made a lot of sense if the visitors have granted consent.

Whilst developing the MLP it also became clear that we needed to update our user interface to accommodate the growing product and allow for a more scaleable product offering in the future. We didn't even have a website at this stage, so we built our first site too.

Below I've included a few example screenshots showing what our app, first website, and new features looked like by the time it was at MLP stage (if you're a fairly new Squeaky customer, even this might look very alien!):

As you can see, it was a much more comprehensive product by the time we'd finished the MLP! Naturally things didn't stop there. Along with talking to users and iterating over the product, we had spent that time period looking out for signals that would give us the confidence to incorporate and turn the product into a real business.

Around November 2021 it felt like those signals were coming thick and fast. What represents a signal is going to be different for each business - these were all things that had started happening at Squeaky after around 4-5 months of building the product:

• People were independently sharing our product within their network.
• Users were returning and usage was increasing.
• In demo calls people started saying 'wow', and comparing us favourably with other tools they'd used.
• Users started asking when they could pay for the product.
• Investors began reaching out because they'd (somehow?) heard about what we were building and it aligned with their own investment theses.
• We planned to test the MLP with around 50 users and ended up with 80 users across 40 companies as more people requested access to our product.

All-in-all, we were starting to feel confident the product was ready for public/commercial release. The boundaries between each phase of product development are naturally blurry, but we were way past the level of features any reasonable team would have included before charging money. This was partly because we were being patient and listening closely to our early users and waiting for the right signals, and it had become a labour of love (which is sometimes dangerous territory to be in!).

Public Release

How do you ever really say you're finished testing an MVP and officially launched? After all, in startup-land you're told to 'keep launching'.

For us, a public release meant we'd identified enough positive signals from our users and the market that we were ready to finalise our pricing strategy, incorporate, and set up banking and payment processing. Once these were completed we'd consider ourselves publicly/commercially released.

One of the key difference between being publicly released, compared with our MPV and MLP testing, was that we'd be switching into an active phase of marketing the product and letting anyone sign up. To support this we also refreshed our brand, updated the colour palette in the application, and rebuilt our website. Prior to this we had a very basic website that barely showcased a fraction of our functionality, and didn't speak to any audience in particular.

Many of the steps involved in public release might not be conventionally considered 'product development'. That said, the practicalities of making Squeaky market-ready, and framing our proposition for commercial release, were important elements of the process. This also took more time and effort than we'd anticipated, so I think it's worthwhile documenting our public release as a self-contained phase.

Incorporation

Setting up a limited company in the Netherlands is not for the faint-hearted. We always knew this was going to be one of the more painful parts of launching Squeaky, which is why we delayed incorporation until we had enough confidence in the product.

When incorporating a B.V. in the Netherlands (similar to an Ltd in the UK or Inc in the US) you're legally obligated to do so through a notary. This entailed several hundred Euros in legal costs and because we have a cofounder in the UK and one in the Netherlands it was even more expensive. We could have saved time and money by incorporating in the UK, but we could only initially incorporate in one location. We chose the Netherlands because (a) I'd be the first founder working full time on Squeaky and I'm Netherlands-based, and (b) Brexit makes the Netherlands a better option due to easier access to the European market.

Ultimately, the barriers to entry for incorporating a limited company in the Netherlands are incredibly high for somewhere regarded as 'business friendly'. There are too many upfront legal costs that just aren't required elsewhere. Take the UK as an example, where everything can be done online in a few minutes and it only costs around £15. You realistically can't start a B.V. unless you have a few thousand euros on hand to cover costs. Good luck if you're a young or low-income entrepreneur who's pre-revenue.

Anyway, we made our decision after careful deliberation, and in the long term it will likely prove the right one, but it sucked.

Our New Website & Brand

User feedback told us that our website was no longer doing our evolving product justice. As we were entering an established market we couldn't afford to underrepresent our offering. We decided to really push to our brand further visually and update our whole marketing website. It was a pretty big project and the primary goals were to:

• Introduce a new brand aesthetic and visual language.
• Showcase each of our core features on standalone pages.
• Use benefits-first language and speak to the aspirations of our target customers.
• Add a straightforward and compelling pricing page.
• Segment our audience and offer content specific to their use cases.
• Add a blog with an SEO-friendly structure.
• Showcase plenty of screenshots of the app.
• Provide clear calls to action and a simple way to sign up.

Here are a few screenshots of the website after we'd finished the redesign:

Pricing Strategy

The best way to validate that a product is valuable is to charge for it. However, because the costs and implications of incorporating in the Netherlands were non-trivial, we waited until we were really confident we'd built a viable, lovable and competitive product. This meant Squeaky had been free for the entire time that we'd been testing the product pre-launch.

When it comes to pricing there are a lot of examples in the analytics market. This told us something we already knew upfront - it's an inherently profitable space to be in and there's more than one successful approach. To help refine our strategy we undertook 3 initiatives:

1. We spoke to loads of people! We discussed the topic of pricing with almost every MVP and MLP user we interviewed, and we spoke to department heads and decision makers in a variety of different companies.
2. We undertook research into the pricing strategy of the 10 tools most comparable to Squeaky and how that related to the market segment they were targeting.
3. We spent a long time researching the various approaches, benefits, and pitfalls of SaaS pricing strategy more broadly. I found this article from cobloom, and several of their other articles, to be particularly useful.

The key takeaways from our research were:

• Our pricing approach needed to be flexible, in terms of model and payment processor. Pricing isn't something you set-and-forget, it needs to be built in a way that allows you to tweak your strategy based on new evidence.
• We needed to be free at the point-of-entry a.k.a using a Freemium Pricing Model. The market is too competitive for a new entry to be stonewalling people.
• The amount of time people and teams commit to these tools ebbs and flows throughout the year, depending on projects, support volume, marketing campaigns etc. With that in mind we needed to allow customers to easily adjust their plan relative to their needs.
• Our tool meets the feature and compliance requirements of many larger businesses, but because Squeaky is a new company it's unlikely we'd get through their procurement process. With that in mind it was important that our pricing better reflected the needs of SMB's rather than enterprise customers at this stage.
• We needed to keep pricing conceptually simple for customers. There's no sense in having a complex pricing matrix that people have to spend 30 minutes interrogating before they understand what makes most sense for them.
• There should be a range of self-service plans at this stage, with the option for custom pricing for enterprise customers.

All this input resulted in us opting for the following pricing strategy at launch:

• Freemium pricing with paid tiers and enterprise plans
  • Self-service plans that are based on the number of visitors a customer's site or app has in a given month.
  • Enterprise tiers reserved for anyone needing things like SSO, Audit Trails, higher support levels, self-hosting or private instances etc.
• Customer can cancel or change their plan at any time.
• We use Stripe for flexible payment facilitation and processing.

Note: We've learned a lot in the past 5 months using this strategy and we'll likely update our approach in the coming months to reflect knowledge we've gained so far. This hopefully won't be super painful, which is why flexibility was so key.

Release

Release sounds like a precise moment, but really it was a rolling sequence of events over the course of April 2022. Many of the activities are outside the scope of this product-related article, so I'm just going to list the main things we did:

• We emailed our existing users to inform them that we'd be switching to freemium pricing with paid tiers for higher usage volumes. We also offered discount codes to all pre-public release users as a thank you for all their incredible feedback.
• We announced our public availability via various social channels and forums like Linkedin, Twitter and Indiehackers.
• We soft-launched on Producthunt.
• We started experimenting with paid advertising as there was now a realistic chance of a return on that investment.

It wasn't a big-bang release, but the change was obvious - within the first 2 months we'd doubled our customer base, started generating revenue, and went from having captured 70,000 visitor sessions to 1 million!

Product-Market Fit

We'd come up with our idea, built a product people were starting to really like, and made it commercially available, and now we had to find product-market-fit (PMF).

'Finding product-market fit' would describe when we've found a repeatable and scalable way of targeting the right customers for our product offering.

It's only been 3-4 months since we've entered the PMF stage of our product development and it can take 1.5-2 years after v1-release to achieve PMF, so this phase is very much ongoing. It's too early to share outcomes, though we're on track and growing steadily in terms of revenue and users.

We'll loop back to this topic in the coming year once we really feel we have achieved PMF (they say that when you've achieved PMF, you know), but in the meantime maybe it's nice to share a bit about what we're doing…

Firstly, we're sticking to the methodology that's served us so well up until now: regularly talking with as many users as possible. We're then driving their feedback directly into our product, and focusing on growth.

Naturally we're also experimenting with things like paid advertising, content marketing etc, but we're trying to play to our biggest strength: building great software and sharing it with our customers and audience.

So far, that's meant continuously updating and improving our product by shipping the features that matter most to our users and target market. In the last few months some of the major upgrades included:

Adding Event tracking

Adding user journey mapping

Creating a help centre

Improving our filters and search capability

• Multiple new and powerful filters have been added.
• Users can now quickly search Squeaky recordings and Visitor databases for specific profiles or recordings.

Adding Javascript Error Tracking

Lots of upgrades to our feedback features

• Multi-language support for NPS® Surveys
• Custom triggers so users can define when a survey is shown to their users - Sentiment and NPS® Surveys.
• Updated interface to help users better manage the settings for their feedback widgets.

You might also have noticed there have been some big updates to the interface - these were designed to improve the readability of an increasingly data-rich interface, along with clearer navigation controls to better organise the features on offer. You can read more about all the post-public-release improvements in our Q2 2022 Product Update and our July 2022 Product Update.

We share these blog posts across our various social channels and we send email updates to all users. We also separately send direct emails to the users that requested certain features to inform them they've been added.

Without going into lots more detail, here are some other things we've been working on during the PMF phase:

• Refining our sales pitch for demos.
• Improving our website and positioning.
• Working on our SEO.
• Exploring partnership programs and startup programs.

What we're measuring

Each company will have different key metrics that they're using to measure their success. To begin with, our most important metrics are:

• Number of verified sites and the ratio of verified-to-unverified sites. This is a measure of how many users add their site in Squeaky and then go on to install (and verify the installation of) the tracking code in their application. The reason this is so important for Squeaky is because it represents (a) whether we're bringing the right users to the app, and (b) whether the onboarding experience is effective.
• Monthly active users. This is a classic SaaS metric and it helps us to directly measure what proportion of our users are actively getting value out of our product each month - the higher this number, the better.
• Ratio of free-to-paying customers. This was important to measure alongside our commercial launch as we want to make sure our product is at least converting users at a similar rate to a typical freemium product, if not better!

Conclusion

Gates' Law says that 'Most people overestimate what they can achieve in a year and underestimate what they can achieve in ten years'. I like this phrase, and I've seen the compounding effect of continuous progress play out in many companies over the years. That said, I also think it's just as easy to underestimate what one year's progress can look like!

Squeaky has changed almost beyond recognition over the past 12 months. We've become a legitimate alternative to some of the biggest product and web analytics tools around, and our feature-set, user-base, and revenue have been growing steadily since our public release in April 2022.

It's hard to imagine what Squeaky will look like by the time of our 2nd birthday, but whilst we find PMF our rapid pace of evolution and refinement will continue unabated. It's been an incredibly energising and rewarding first year and that's in huge part thanks to the invaluable feedback, feature requests, and input we receive from our users - without that, you just can't go from one line of code to where Squeaky is today!

We're looking forward to another year of doing what we love: talking to our users, building cool products, and experimenting with what it means to provide privacy-friendly analytics for the modern web… hopefully next year we'll tell you all about how we 'found product-market fit'.