How to Avoid Building a Beautiful Product No One Needs

Howie Liu on building Airtable: how talking to users and industry experts early kept the product from being beautiful but useless. De-risking product-market fit means iterating based on what people actually need, not what you think they should want.
Chapters
We certainly didn't want to just be so arrogant as to believe that, you know, we could stick our heads in a, you know, huddle down and like, Steve Jobs just come up with like a magical new product that for sure everybody in the world would want. So I would say that we were pretty iterative in terms of de risking the product market fit, even if it didn't entail actually launching the product. So early on in the earliest days, we were going out and just talking to lots of other people who had worked on similar products, right. Whether it's, you know, Stephen Sinofsky from Microsoft who had worked, who had overseen Office and Windows and, you know, kind of getting his feedback on our idea. Right. Or other people who had worked on similar products. Right. You know, there were a number of low code companies that, you know, existed 10 years ago, right. And never quite made it. And so we kind of wanted to go and talk to these founders and other operators and figure out why isn't there already a product like this that's mainstream, that's successful? Why did your company not, you know, kind of ever quite, you know, kind of hit that ubiquity, Right? And so we did a lot of that, that kind of early research, just like trying to figure out like, you know, what was the prior art, who else has thought about this idea in the space subsequently? You know, we kind of develop our own thesis or it kind of corroborated our thesis that, you know, none of these products were, were good enough. Like, I think there was a certain threshold we believed where, you know, if the product was hard to use, if it was too complex, and if it just wasn't a viable replacement for Excel or Google Sheets, then people wouldn't use it. Right? So there was almost kind of like, we believe that there was a binary of either your product is, you know, better enough and intuitive enough to kind of replace existing behavior, or it wasn't. And then if it's not, then you just kind of die this very slow death where, like, you have a few people who are kind of enthusiasts of your product, but it never quite catches on in a mainstream way. So that's kind of what the conclusion that we came to. And we had some validating conversations with people who did work on products like this and actually felt pretty strongly that this could be a thing, that we were onto something. I think Stephen actually had pretty positive feedback for us. And we also talked to somebody who had led Microsoft Access within Microsoft and kind of shared their perspective on this product genre. So that was kind of the first step. I think thereafter we just realized like, okay, it's going to really come down to our ability to distill a lot of the complexity behind kind of a relational database, low code app platform into something that feels effortless, intuitive, even delightful to use and has to be as easy or arguably even easier to use than kind of the status quo. Right. So the friction to adopt Airtable had to be minimal relative to using a spreadsheet. So we started working on a lot of client side or front end only prototypes. We were just prototyping the design of the product and some of the interactions and the UX and we would build these initially just mocks and then later functional prototypes, but fake the backend, right. So we wouldn't actually persist data, but you could kind of click around and we started testing those with different types of knowledge workers in different use cases industries and you know, saw how they use their existing tools and then asked them to kind of replicate a workflow or see if they could understand how our product worked. And you know, there were just kind of these subsequent milestones like that where you know, we would go and validate the next big risk. Right. Like can we design a product that actually is intuitive enough? Okay, if we can do that, then can we actually get people, even if the product, even if the UX is theoretically intuitive enough, can we actually get people to shift their data over to, to our product? Right. So then build a backend that's functional enough to actually persist data and like get people, you know, even on small scale to see if they can actually start using Airtable. And if, if not, then why? Right. So there, I mean, I would say like every three to five months we were probably de, risking a different question about the, the viability of this product market fit leading up to actually launching it and then just crossing our fingers and seeing if people, now that anybody could sign up for the product and it was out there whether people would actually come in and sign up and hear about and talk about our product.
More from GHION.AI

O processo de reconhecer limites, mesmo quando a vida parece exigir sempre mais.

Depois de tantas histórias, aprendizados e pausas necessárias, o @interior_iza está de volta








