What lessons did the early Shortwave team members learn from building Firebase, and how are they being applied in developing Shortwave's products?

We learned a lot of lessons during our time at Firebase—a few we've carried over. 

One is to talk to customers. Generally, a lot of developer tools made it  really hard to interact with any sort of community if you were a user of that developer tool. We started very early on saying we wanted to talk with customers at every stage of the development process and have really good support for our existing customers. We’ve brought that to Shortwave as well by trying to have great support, replying to users quickly, and making sure we include them throughout the process. 

Very early on, we started an alpha, where we brought in a bunch of users, even when the product was still very rough. We have been iterating with them for years. By the time we launched a few months ago, we already had many years of users trying out our product and giving us feedback. 

Another lesson we learned is you have to design a workflow, not just a disparate set of features. This goes back a little bit to what I mentioned about Gmail. I would say Gmail is a product that has a disparate set of features, and it's a build-your-own-workflow. We think that it’s better to have an opinionated workflow that makes common things easy and intuitive and then makes hard things possible.

We thought about this in Firebase—of designing APIs so you could do real-time sync really easily. If you needed to do something that was really complex, it took a bit more code, but it was possible to do. Similarly in Shortwave, we want the common actions—pin, snooze, done—to be front and center. If you want to do other things, we want to make them possible, but those are the things that might be hidden behind an overflow menu or a bit less in your face.