[jamest]

The satire in the title is reminiscent of how Firebase was born.

We were previously working on a chat system called Envolve (https://www.envolve.com), that was 'Facebook Chat for any website'. A game that was using us for in-game chat created channels, used display: none on them, and passed game state through the chat.

We scratched our head, asked them why, and learned they wanted to focus on the frontend, not to deal with realtime message passing.

This led us to create a 'headless version' of our chat infra (re-written in Scala) that became the Firebase Realtime Database.

[bombcar]

This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.

[dylan604]

Nobody wants the product you want to make. They all want you to make the product they need, and will do things the devs of your product could never imagine with your product.

[fatnoah]

> This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.

One of the craziest cases of this I've seen was with a web-based survey application I was the principal engineer on in the mid to late 2000's. A big feature we implemented was the ability to create surveys to support multiple languages. To make translation easier for our customers to translate surveys outside of the application, there were ways to export/import the text strings as well as a standalone screen that allowed finding and editing them. Both of these were made easier by the fact that the strings had semantic identifiers like "/survey/question/choice" or similar.

Since this functionality worked so well, we also used it internally for all text in the application. As a convenience, both the import/export and edit screen were capable of editing these strings. One customer figured this out and, due to the naming, was easily able to identify the text for all screens and dialogs. They ended up completely modifying the application interface through this interface by editing text, adding HTML elements, and injecting CSS blocks. They added descriptive tutorial text, guides for users, and branded the application well beyond built-in functionality. It was pretty amazing.

[agumonkey]

I saw the opposite happen so often and every time it's very painful to see people have knee jerk reaction instead of thinking outside the box.

[NovemberWhiskey]

... and this is great if you're a business, but if you're an internal platform team then it really sucks.

[kitd]

Yes.

If people CAN do something with your tool, they will.

The moment you say "yeah, no one is stupid enough to do that", they will.

Be ready for it!

[1nighthawk]

It's amazing with how much creativity users will abuse your creations. ;) And in many cases, something new is born out of it. The problem is getting the information about just how people are using your service differently than you've intended. Sometimes it's impossible to tell from traces, analytics or logfiles alone. But finding out can be quite an advantage, especially if you're a startup probing for PMF. The best thing that can happen is that you have a channel to your customers that's constantly open. At WunderGraph, we use Slack for that, and it considerably lowers the barrier to just check in and have a quick discussion. The sooner you find out about use cases, the better - and ideally create a product around it. :)

[james-revisoai]

Did you detect this MixPanel or something?

[jamest]

We were talking to (and using the sites) of all our customers of any reasonable size. This was one of them.