One thing I've learned working with early-stage products is that a single customer can simultaneously be your biggest opportunity and your biggest distraction.

Some of the most valuable customer conversations we've had completely reshaped our roadmap. But we've also found that it's important to distinguish between a design partner helping define a broader market need and a customer asking for highly specific workflows that don't generalize.

That distinction is much easier to see in hindsight than in real time.

When I'm building, and get approached by large customers who have specific needs for them, those needs go at the end of our backlog. There's a hard and fast rule that unless it's an issue with authentication or accepting money, nobody gets to jump the line. We re-evaluate our backlogs periodically, and treat large-customer requests similarly to small-customer requests; who is this going to serve, what additional revenue could this generate, will this increase retention. If there are other projects that, combined, will move the needle more than doing one project for one enterprise client, guess what, that enterprise client doesn't get to jump the line.

> Chesky said no. Not politely declined. No.

Gaaaah please stop

Remember that there is an alternate universe in which AirBnB is the way that 70% of all corporate short-term housing gets booked, and they are telling the story of how they nearly didn't pivot correctly.

And a zillion alternate universes in which they never got big. Survivor bias is real, and everyone has just-so stories. The ones they choose to tell are partially an artifact of organizational culture, and partially of self-aggrandizement.

While I agree with the overall theme of the article - prioritizing a single large customer can be a deadly trap for a new company - the way it is presented that these companies held to their principles while barely escaping bankruptcy ("Sometime in 2010, Airbnb was hemorrhaging money and growing slower than Brian Chesky had promised investors") reads like BS revisionist history to me.

I'd be particularly interested in a separate source for the 2010 story about AirBnB. I worked in the short term rental space at that time and I remember AirBnB exploding into the zeitgeist at that time and being seen as a potentially potent new disrupter - not this "at grave risk unless they took on a big new customer" story that this article is projecting. Plus, AirBnB raised their Series A in Nov 2010, so it didn't seem like they were having issues with investors.

AI;DR?

IIRC, around 2016 or so, Slack invited us in their office to pitch us the enterprise version and ask whether we would be interested in becoming one of their first enterprise customers. Among other requests, one colleague asked me to ask them to not kill their IRC gateway. One of their PMs looked at me and told me “No, we are not doing this”.

Does anybody know how to write anymore?

slop

> Stewart Butterfield has talked about the pressure Slack faced from large organizations in its early days wanting features that would have fundamentally changed what Slack was. The requests were reasonable on their face: more administrative controls, different permission structures, audit logging. Each one seemed like a logical extension. Taken together, they were a blueprint for a different product aimed at a different user. Butterfield’s team had to repeatedly decide what they were actually building.

I'm pretty sure Slack has those things by now. So the question is, what did the team actually end up building? What features were prioritized over the enterprise compliance features? Would Slack have less revenue had they gone with the enterprise stuff first?