Valuing already-solved problems.

Product market fit for business-to-business products hinges on when your customer first encounters the problem you solve. If you’re selling to a company that is newly encountering the problem, then you get to sell them on your product’s value. However, a mature company likely already has a working solution, and you’re stuck selling on reduced total cost of ownership, a much harder sale.

This can make it difficult to determine if you have fit for larger customers: you can’t validate against existing large businesses. Instead, you have to wait for early stage companies who adopted your product to solve their initial problem to become large companies.

This dynamic ends up shaping most business to business products, here are a few examples.

Metrics and dashboards

For a long time, companies that wanted to create metric dashboards had few options. Most ended up using Graphite or (slightly later) Grafana. These are complex systems to operate, and an IaaS ecosystem has emerged featuring Datadog and SignalFx.

Many new companies default to using one of those IaaS vendors, They need metric dashboards and don’t want to invest engineering time into provisioning, maintaining and scaling Graphite, so it’s an easy value proposition.

On the other hand, older companies have already built competencies around running Graphite or have developed their own solution like Uber’s M3. To consider shifting off, they have to make a believable case that this is a cheaper way to maintain the existing tooling’s value, including the opportunity cost of migrating to the new system.

Most can’t.

Request tracing

Anyone who’s read Google’s Dapper paper has dreamied of request tracing for the past decade. This has culminated in a rich opensource ecosystem featuring OpenTracing and Jaeger, as well as commercial attempts such as AWS X-Ray and LightStep.

However, fairly few existing companies that have succeeded in incorporating these tools into their debugging workflows. Instead, they already have homegrown solutions, which may not be elegant–filtering logs in ELK or Splunk by a request id passed through the request stack–but work well enough and don’t require their engineers learn a new tool.

Modern real-time request tracing differentiates from log-based solutions by storing traces in memory. Storing raw events in memory supports high-cardinality metrics with higher cost efficiency than metrics-based approaches that depend on pre-compiling data points. This is a novel capability, but it often makes these solutions have a higher total cost of ownership than companies’ existing log based solutions.

Mature companies have typically already solved these needs and the cost model makes it difficult for request tracing products to compete on the basis of total cost, which makes it unlikely that in-memory request tracing will ever penetrate today’s large companies, and also puts it at risk for fit with tomorrow’s large companies as well.

One potential exception is around companies moving to service oriented architectures, where debugging cross-services creates an opportunity for request tracing to be value-creating, even in a mature technology companies.

Applicant tracking systems

Applicant Tracking Systems (ATS) are a good non-infrastructure example of the same phenomenon. Many newer companies adopt Greenhouse or Lever for their ATS to good result. However, many older companies continue to use an internally created ATS, some of which are quite advanced and specialized to their needs (e.g. Google), but many of which–on closer inspection–turn out to be unversioned spreadsheets shared over email.

Most companies in the later category would benefit from moving to a modern ATS, often struggling to hire recruiters who want to work with effective tools, but because they’ve already solved the problem they can only value the offering on cost-savings, not on capabilities.

They typically end up not switching.

There are a bunch of other examples that we could go into:

• Slack’s early struggles to displace companies that had already adopted Hipchat, or even private IRC servers, that culminated somewhat surprisingly in Slack’s eventual acquisition of Hipchat.
• Adoption of ELK versus Splunk at various company sizes and ages.

They mostly retread the same patterns, so I won’t expand on them, but each of them is quite interesting in the particulars.

Summarizing: how companies value your product depends more on their lifecycle than on your product. Just because you can’t sell into large users today doesn’t necessarily mean that you don’t have product market fit for tomorrow’s large users. If you engage them early, you may very well be able to serve them well as they become a large user.

You shouldn’t assume you do have fit. You just don’t know either way.