I periodically return to several ideas, as I talk to founders. One central one, that seems especially relevant with AI, is that your product threatens your product. This of course sounds a bit nonsensical when put that way, so let’s dig in.
Product Market Fit is a Moving Target Link to heading
Reaching Product Market Fit, or PMF, is obviously the goal of any product driven startup. However, most startups view PMF not as a starting line, but as a finish line. There’s nothing sadder that watching a company get traction, start to succeed, then have the market slide out from underneath them - but this happens frequently.
Often, founders take the wrong lessons from their success. Principally, most startups luck into PMF, and attribute it to their (frequently bad) process, or to one (frequently bad) individual. Now, around this time you might be saying “well, that’s not me!” - probably true, but if you’ve been around, you’ve seen this. This means that the founder spends time scaling problematic foundations, instead of tearing out the rot at the root. PMF slips, they’ve lost agility because they’ve scaled problems instead of solutions, and they double down into more of what didn’t actually help them succeed (in this case, throwing more darts at the dartboard would be “optimal”).
The counterpart here is also just bad luck. You can do everything right, and the market can move away from you. Now, it’s tautological, but I’d define great companies as ones to whom this doesn’t happen - they maintain high luck surface area, they stay nimble, they stay hungry, they stay humble. But the reality is that scaling a company and retaining those attributes is far from easy. The ones that persist are the ones the scale, but scale judiciously, and scale not only their culture, but the meta culture - the culture of their culture. This means judicious hiring and firing, and attending to culture with a severity.
A Customer Can Threaten Customers Link to heading
When I was at SalesLoft, one of the core values was “Customers first”. I don’t recall if it was official, but we would frequently say internally “It’s CustomerS first, NOT Customer First”. This is to say, individual customers are fallible and wrong, but you’d better damn well listen if a group of them are giving you feedback that even begins to rhyme.
A very typical danger (not outright failure, but severe danger) for startups in this category is the Golden Monkey problem (couldn’t find a citation, so sorry! not sure where this one came from). This is revenue concentration risk, or a result of “elephant hunting”. If you land a single large customer early, you naturally are incentivized to tend to their needs to keep the money flowing. This has a number of downstream effects - your solution becomes over-fit to the market, so it tends to their needs and not those of the larger (potential) ICP base. It’s also a massive risk - if you champion in the customer leaves, they may churn, leaving you with less than nothing - a product that requires quarters of work to adapt to another ICP persona.
So what is to be done? Well, first off, don’t walk away from a great deal just because of this risk. It’s future risk, and you probably have more acute risk in the form of solvency / roadmap. What you do need to do is service CustomerS not the Customer. That is to say, understand you customer deeply, and ship to their needs. That means saying no to misaligned asks from large customers, so you can say yes to roadmap you need. It’s tough! But it’s doable.
If You Build It, You Must Support It Link to heading
A third category is an emerging area called Product Debt. It’s Product’s ugly twin to Technical Debt. There’s a number of facets where it appears, but the most acute one I see is with experimentation, features, and the bridge between them - feature flags.
Feature flags can go very right. As I’ve previously covered, Ship to Learn is vital for learning more about what you can and should be building. A great way to do that is with small in-app prototypes, hidden by feature flags, and shown to interested, warm, or friendly customer. In an ideal world, you roll out, test for a few weeks or months, and commit to GA (General Availability) or axe it and roll back. In this case, several tests might be in flight to different demographics, allowing you to compare metrics and get feedback.
Of course, reality is rarely so clear cut. What frequently happens is this - you have 3 demographics. The largest section is more or less apathetic. A section of customers is rabidly opposed to the feature, and threaten to churn if it is rolled out. A third section is equally zealous for the feature, and threaten to churn if it is removed. Now we reach a classic lose/lose: If we leave it as is, we accrue product debt that compounds each time we do this. Or, we toss the dice, and piss off some customer cohort.
The reality is was and will be - not all your customers are ICPs. In the above scenarios, if you treat a Customer the same as your CustomerS, you risk your business. Part of product is making those hard tradeoffs - building for customers that don’t yet give you revenue, to decrease risk. Taking things away, since they’re the wrong thing, even if customers leave. Scaling your organization in a way that feels unnatural, despite past success. Building successful products is frequently (well, sometimes) simple and straightforward, but it certainly is rarely easy. Choosing to endure and build for resilience and repeatable business does require you to compromise, repeatedly.
But you have to stay in the game to win.