[rickcnagy]

I've observed the same thing in the EdTech space (e.g. ClassDojo, Google Classroom), and I think a big part of that is being self-serve forces the company to build _actually good_ software, not just software that sells well to the district, state, etc.

What's required to sell software to large buyers is very different from what's required to make the product useful, but in the long-run, it's the utility of the product that makes it valuable to end-users, and the success of the end-users _eventually_ determines how the buyers make decisions. Self-serve software tends to prioritize the things that will make it easy to sell and improve in the future.

[wpietri]

Exactly. Serving people directly strongly encourages a focus on delivering real value, because the user and the purchaser are the same.

Serving people indirectly allows for all sorts of other approaches that work in the short term. If purchasing decisions are mainly driven by our sales guys and their executives, it slows and distorts a key feedback loop.

I once heard a story about SurveyMonkey that I love. They got their start very much on the self-serve end. But eventually the CFO of Oracle saw all these credit card charges from individual Oracle employees using it, went to SurveyMonkey, and said, "Create an enterprise tier for us." SurveyMonkey looked at what it would take in terms of engineering and said, "Sorry, we have other priorities right now."

The way I heard it, the Oracle CFO, not used to being told no, sent forth an edict: From now on staff were not to use SurveyMonkey, but some other product that Oracle did have an enterprise deal with. Sounds like bad news for SurveyMonkey! Except that the other product wasn't very good, and SurveyMonkey wasn't that much anyhow, so people just went on using and expensing it.

[fjp]

I'm at a company with a self-serve B2B API platform.

Our customers mostly build their own PaaS offerings on top of our API, which has some really positive effects I have observed.

1. Stickiness & seriousness of customer. When we land a big customer who is going to swap out competitor APIs from their platform and use ours, this customer is clearly very serious about building & growing with us, as the approval to rewrite huge amounts of core platform functionality to use our APIs is not made lightly, and is almost always made by a technical C-level person. The building phase often results in very close relationships with their developers. Their needs and demands help drive our roadmap, but with the understanding that we're not special-casing anything for them. If they need a feature, we're going to take the time to build it so everyone can use it.

2. Being API-first means satisfying the developer, which lends itself to focusing on building ergonomic software. If updating some configuration takes 2 seconds instead of 200ms, no developer is going to prioritize switching to our API when they need to make a 50k of those update requests regularly. If something takes two commands on our API instead of one on our competitors API, it better be damn clear what value that extra command is providing... etc etc etc.