One of the most difficult challenges I’ve faced in my career is figuring out product-market fit. I’d wager most of us have gotten there through sheer dumb luck. What do we do if we’re not lucky, if we don’t strike gold on our first try? I don’t know if I have the answer. What I can do is try to break down what worked for Sentry’s error monitoring - a reverse engineering of sorts - and reason about how we’d apply that to new products.

Before we do that, we need to address what product-market-fit (PmF) means. I have a simple way of reasoning about this. It’s not Math. It’s not some jargon from business school.

PmF is when customers sell your product for you.

It’s when you’ve solved something in a way that gives people a visceral, emotional reaction. It’s when they champion - and more importantly defend - your product. It’s when you begin to understand why cold sales are an inefficient use of resources. Sounds great, right? So how do we get there?

There’s a lot that goes into achieving this goal, but I’ll break it down into a few things we look at with Sentry. Specifically I’m going to talk about fit within the context of Sentry’s business and goals. We did an analysis on some of Sentry’s newer investments to try to understand why they weren’t hitting the level of success we wanted. We knew PmF wasn’t there, but we weren’t quite sure why. That was clustered around our second product: Performance Monitoring.

We went into it with a simple thesis: when your app breaks, it’s pretty damaging for customers. Errors were great, but it didn’t encapsulate every developer-generated bug, and users don’t care if the bug is an “error” or some other kind of telemetry. We decided that we’d take our approach with errors and apply it to these other similar problems, specifically latency issues. There were a few important (correct) decisions here:

1. We knew our Ideal Customer Profile was the individual software engineer, and we intended to keep building for that ICP (vs a PM or a VP). ICP, if you don’t know, is basically your dream customer.
2. We have a market share business, so we knew our best approach was to build something that we could sell to every existing customer (not just enterprise accounts).
3. We knew we wanted to be in the same rough domain (production monitoring, problem detection) vs expanding into an entirely new market (e.g. platform as a service).
4. Lastly, we knew there was a TAM associated with APM, which traditionally is associated with addressing latency of applications (APM and RUM both).

With all of those effective-truths, we figured performance monitoring would be a great way to build into the next stage of Sentry. We were wrong. We built a product, it generated 8-figures in revenue pretty quickly, but it never achieved PmF. There’s a lot of reasons that we explored - pricing and packaging, community domains (e.g. javascript vs mobile vs python), or even the product functionality itself.

Take a pause before you continue. If you’re familiar with Sentry and the general software domain, what do you think was wrong about our thesis? What do you think we got wrong?

It wasn’t until a couple years later after we repeated some similar failures with another investment that we really understood what was going wrong. You see, we were approaching PmF from the wrong angle. We were approaching it from an expectation that the thing we were building could ever possibly achieve our original goals. That is, we made a false assumption that every technology company, big and small, had performance concerns. This is the first, and biggest mistake we made.

When you reason about it, it becomes way more obvious. Sentry’s value - and our ICP - has always been with emerging technology. You build a new application and you need something like Sentry. You need it because your application is in a state of change. This is the same reason technologies like .NET and Java have never been big for us. Often those applications are in maintenance mode, and without continuous change you won’t get a lot of value out of Sentry given we mostly tell you when you introduce new bugs.

The second level of depth here is understanding really what our ICP looks like. Emerging technology typically means early stage companies, or early stage products. That primarily translates to startups being our target customer base but it also includes some teams within enterprise companies where new development happens (such as within mobile apps). Given the core audience is startups, it’s pretty obvious they aren’t going to have a ton of performance concerns. They don’t have any users yet!

The third trap is one that continuously exposes itself. Our Error monitoring product established PmF years ago and that gave us the time to grow its capabilities and ability to scale. It’s allowed us to succeed with customers of all shapes and sizes. We can’t do that with a brand new product however, and for those to be successful we have to avoid servicing those customers at first. We have to bias towards our true ICP, and build something that won’t scale (and won’t sell!) to many of our customers.

Bringing this back to our performance monitoring effort, the fundamental issue is we were building a product that only a subset of our audience could find meaningful value in.

It should have been plain as day. We disrupted the entire APM industry by focusing on a niche category of telemetry, one that plagued us - the builders - every day. We had to recognize we needed to get back to that, back to approaching product the way we originally did with Sentry. We made a wrong bet, it happens, and it might happen a lot. The trick is recognizing it more quickly.

My fingers are itching today, so to really help cement this next point I want to focus on a more recent example.

I was sitting through a conversation about one of the new products we were working on. Someone showed a chart suggesting - because our growth was flat, no sign of an exponential curve - that we needed to build more awareness to sell the product. We needed to put out some more tutorials, or maybe a few more webinars (sigh). Fool me once…

I immediately recognized the issue: was there even an addressable market for the thing we were building? No one had even considered the question. It’s an easy one to diagnose: is there a TAM here? Do our 65,000 customers NEED this product? Who’s excited about what we’ve built? It was pretty easy to guide the conversation to considering maybe the problem isn’t marketing, but a lack of PmF. That leads me to a common bit of feedback I could give most founders, as well as many team members at Sentry (of which, we’re around 200 in Eng, Product, and Design alone).

You should be selling.

I don’t mean running drip campaigns. I don’t mean running ads. I don’t mean pitching. I mean authentic, meaningful, organic selling. You should talk to the people you want to be your customers and go deep. Find their objections. Find the thing that sparks excitement. Don’t settle for “that sounds useful” - that’s a bullshit phrase that means your idea is garbage. Find a new customer or find a new idea. Find the customer where it clicks, the partnership and excitement is there, and they represent your early TAM. That is selling.

The recognition was we were relying too much on “data” - analytics - and enterprise conversations. They were the easy solutions. Both are easy access. Both are wrong in our case. Analytics tell you almost nothing, and for most things Sentry does, enterprise customers are not our core ICP. The only way you solve for this is by meeting your customers where they are and being extremely critical of your takeaways.

I think this is what (some) folks mean when they say founder-led sales, but it took me a long time to understand that. It took me so long because I didn’t actually connect that what I was doing early days at Sentry was sales. I was hanging out at conferences, sharing my opinions, sharing beers with my peers. I was giving presentations talking about how we approached Open Source or how I glued some of our database infrastructure together. I didn’t connect it to sales because I wasn’t shilling bullshit. I was selling my values, my beliefs, my expertise. At the same time I was validating and improving Sentry in these organic conversations.

This is also fundamentally why sales and marketing are not the solution to your problem - just the same way as abstract analytics aren’t going to tell you why a feature doesn’t have engagement. You only truly understand what is or isn’t working when you obsess over your customers. I did that via IRC, GitHub, and most importantly in-person events. Most of those channels still exist and are still one of the easiest solutions, albeit IRC has been replaced by Discord and Twitter for me. You can’t outsource it to field sales, you can’t outsource it to digital ads. You’ve gotta do the work, find the right customers, and meet them wherever they are.

Ultimately, the main lesson I’ve taken from the last few years is pretty simple here. It’s up to the product team - PMs, engineers, designers - to do the selling, to go deep, to be critical, and to sell the product until it sells itself. Your account reps will assist when you get there, but they’re not going to get you to PmF.

tl;dr

• Product-market fit isn’t about revenue or analytics
• It’s about customers selling your product for you
• You can’t outsource finding it to sales or marketing
• Focus on your true ICP, even if it means building something that won’t scale initially