Building Intuitive Enterprise Software
3 findings on early product decision making from Coda, Airtable, and Twilio
In our first post, we presented a framework covering the key ingredients we believe most Product-Led Growth (PLG) startups need, to be effective in scaling their business. Unsurprisingly, Product is the nucleus of the framework, and frankly the most fundamental component to nail.
Over the past few weeks, we met with Execs and Founders at Coda (Shishir Mehrotra, Co-founder & CEO), Airtable (Andrew Ofstad, Co-founder), and Twilio (Mark Gilbert, VP of Product) to discuss some of the critical early product decisions they made. Here's what we learned👇🏽.
When building your initial product...
Develop a simple product thesis
Adopt decision-making frameworks matching your product thesis
Seek the initial 'Aha moments', not the initial revenue
When deciding on your go-to-market approach...
Pick your personas
Build even playing fields
Understand how your organizational design enables your go-to-market
On identifying when you have achieved initial product-market-fit (PMF)...
First, understand your product category (high vs. low differentiation)
Next, figure out the right measure for initial PMF (NPS or Disappointment Score)
Bonus Finding: On dealing with mistakes made along the way...
Embrace experiments
Listen to your users and iterate fast
#1) What do I focus on while building the initial product?
Develop a simple product thesis
Shishir Mehrotra (Coda): If there's one common theme of my product philosophy it's that it always starts with a simple and clear product thesis that everything builds around. It is the statement that bleeds through all your product design decisions and to the users and community that's built around it. They'll repeat it back. Having clarity on your product thesis early on is extremely helpful. At Google, it was the idea that search was nowhere near fast or relevant enough. For YouTube, it was about doing to cable what cable did to broadcast, going from 3 channels to 300 channels to 3 million channels.
At Coda, our product thesis is that anyone can make a doc as powerful as an app. This was central to what we decided to build and how we built it. Coda is deceptive in its early simplicity, while there's a lot of power-packed under the hood. While users get the familiarity of a blank page doc when they open Coda, they can iteratively build their own tools from the ground up using buttons, packs, automation, and more.
Andrew Ofstad (Airtable): At Airtable, we had the idea of taking something really complex (a database) and making it accessible to anyone. Airtable looked no different than a typical spreadsheet initially, but that vision guided us to make our most important product decisions in the early days.
Adopt decision-making frameworks matching the thesis
Mark Gilbert (Twilio): Twilio has always been very maniacal in driving decisions with a customer-first mindset. Jeff forces us to gather user evidence, to show that a real need is there from our users. It translates into how we frame everything, including most of our internal initiatives. Jeff sometimes has us reword internal memos to explicitly surface how those projects tie to our customers' needs.
Shishir: The core way we think about decision-making at Coda is around what I refer to as 'Eigenquestions'. The basic idea comes from the term eigenvector in linear algebra (the eigenvector is the most discriminating vector in a multidimensional space). Eigenquestions are the questions that, when answered, likely answer a series of related subquestions as well. This framework helps us focus on asking the right question when we have to make a hard decision, not on getting the right answer. Identifying the right questions has been a core part of our product decision-making philosophy.
For example, we have people using Coda to take simple notes in meetings, others using our product to run their entire company. For the latter group, we serve as the CRM system, the inventory management system etc. A hard choice we get faced with constantly is on whether to lean into those powerful use cases or to start with the simple use cases? After framing the right eigenquestions, we decided that we win the rights to the complex cases by winning the simple cases first.
👉 Template: Eigenquestions: The Art of Framing Problems
Seek the initial 'Aha moments', not the initial revenue
Andrew: We didn't publicly launch Airtable for the initial 2-3 years. It paid dividends for us. We had beta customers and spent a disproportionate amount of time listening to our users' feedback. Our product was initially very alike to what you'd expect a spreadsheet to be. We started noticing huge changes when we started making them a lot more visually appealing and customizable. We honed into those 'aha moments'. Airtable Views was one of those ‘aha moments’ in the early days. Our users realized you could create these different kinds of views with the same underlying data, and all of a sudden envision richer contextualized use cases for their data. Another one was introducing "linked records". Our users would link tables together and realize you could have a single source of truth for data, and efficiently power a lot of downstream workflows which you couldn't envision in competing products. Those 'aha moments' made our users willing to give us a chance and keep using the product, and we knew we were creating a lot of value for them.
Mark: The hardest tension in PLG startups is to remain focused on the user and usage patterns as the leading indicators of value, instead of revenue. Initially, it is fairly easy to be self-service and bottom-up, but as you start hiring sales (or raising capital), it can become very hard to keep that mindset. Sometimes, sales teams prefer if the product category is complicated to sell as they can be more consultative and add more value to the customer. Sales teams at Twilio are designed so that marketing, product, and engineering continue to build our top-of-the-funnel pipeline. This tension doesn't go away as the company drives towards revenue, wins bigger deals, and overlay top-down enterprise sales. It remains through all phases of growth.
#2) How to decide between horizontal and vertical go-to-market?
Pick your personas
Andrew: Initially when we launched Airtable, we cast a very wide net on user acquisition, and started seeing pockets of users adopting the product. For example, we started seeing companies in Entertainment, Tech, Financial Services, and Apparel using Airtable. We started to focus on those personas that demonstrated clear product validation. Beyond traditional industries and job titles, we found that our early users were "tinkerers" - individuals who are ambitious, push their team forward, question the status quo, and like playing around with new products.
Shishir: You want to find the right balance between the type of personas who naturally responds to your product initially and the personas to who you explicitly want your product to respond. Coda is a very horizontal product by design, but initially responded the best to the two personas we were focused on: the Founder/ CEO, and the Product Manager (PM). For the Founder/ CEO, the value proposition was quite clear: "replace every tool in the company with Coda". For the PM, our value proposition was "built just for you". While the Founder/ CEO persona may be an obvious one to target, the PM persona was just as important. PMs are natural evangelists and dot connectors. It's a person that's heavily talked about but there's hardly enough tools to address the PM, and that's where Coda comes in.
Build even playing fields
Shishir: We like to think that even playing fields invite more players. The basic idea is, especially when you're running a business that has a marketplace dynamic like YouTube or Coda, your users will intend to grow their businesses on top of your platform.
It's the reason why YouTube has the same revenue share, whether you're big or small. Most of the product functionalities are available as much as possible across all customers, to try to make sure there's a level playing field. Oftentimes, lots of playing fields get tilted.
At Coda, we build horizontally such that our community can build vertically themselves, and go address very specific users and use cases. A key part of how our motion works is that we supply people with the building blocks. Users start not only building docs themselves, they publish them for others to use. The best compliment I hear for the Coda doc gallery is that it feels like a hybrid between Medium and an app store.
Your organizational design enables your go-to-market
Mark: Twilio is heavily a horizontal product and our organization is structured that way. If the ultimate end-buyer is vertical (for example Healthcare), or functional (for example the CMO or the marketing function), then you need to start with that. If the product can ultimately be used by anyone in the organization or a much broader set of personas, it's best to start horizontally. Over time, the persona you serve by default becomes easier. Twilio produces developer components. Our organization is designed to serve the developer.
In some cases, it comes with its set of challenges. Just last year we announced HIPAA compliance, which doesn't sound hard but it was really difficult for Twilio as it required every product team to collaborate cross-functionally to get it out the door, which isn't typical. It can be very hard to go vertical when your entire organization is designed for a horizontal motion.
#3) How do I know I've achieved product-market fit early on?
Shishir (Coda): I don't believe there's a single moment when PMF is established. Your product will always be unfinished. With YouTube, we had 100 million users and we still didn't believe we achieved PMF. I think what startups should aim for is InitialPMF. One of the most common methods for determining initial PMF is by looking at how happy your customers are.
Traditionally, this has been done through market research metrics like Net Promoter Scores (NPS), where you ask your users how likely they would be to recommend the product. Lately, a lot of startups have been looking at other market research measures like Disappointment Scores (popularized by Rahul Vora, Founder at Superhuman). Disappointment scores ask your users how disappointed they would be if they could no longer use your product, with a score at or above 40% indicating you've achieved initial PMF.
Rahul and I have had plenty of debates on where it makes sense to use each measure. My current perspective is that for products with low differentiation, NPS is a more critical metric — e.g. if you ask customers to compare BMW vs Mercedes, they may recommend one over the other, but they won’t be totally disappointed if they lost access to their first choice. On the other hand, in categories with high differentiation, disappointment scores tend to be higher — when you ask customers how they would feel if they could no longer use the product, they are especially upset, because they don’t view alternative products as reasonable substitutes.
At Coda, we looked at both and found that in the early days, we had very high Disappointment scores but very low NPS. This makes sense - Coda is a new model for documents and wikis, and is a small-strokes product with higher switching costs. In other words, it operates in a differentiated space and so we would expect higher Disappointment scores.
Over time, this has evolved and Coda now has high NPS and Disappointment scores. In the early days, I do believe it's important for startups to identify the measure that makes sense for their product category.
👉 Template: The Superhuman Product/Market Fit Engine
#4) Bonus findings: What's the best way to deal with mistakes along the way?
Mark: Embrace experiments. Lots of our experiments simply didn't work. You want to create a culture where getting the results of experiments is a success in itself. The most overlooked challenge with failed experiments is to properly set expectations with customers so that you can shut things down later. Larger customers typically want to try your new features and products and are also likely more willing to pay for them. We implemented two things:
Limiting services to make sure can't use it in production (not just beta) by design and;
When we eventually shut down a product or product feature, we give our customers 6-12 months for users to off-board. It's a long time for a startup so you want to be very thoughtful about rolling on customers too quickly on beta features. Customers have expectations they can use it forever, especially when they love it.
Shishir: Listen to your users and iterate fast. We ran into this when we started focusing on monetization. We decided on a pricing strategy whereby we charged for Doc makers with a fixed set of Doc Editors per plan. For example, our entry-level plan included a price per seat for a Doc Maker and included 2 Doc Editors. The response from the community was pretty overwhelming - our users weren't happy with the new pricing plan and found the caps on Doc Editors to be limiting. We were quick to iterate and re-shipped pricing 3 weeks later with no caps.
A very big thank you to Shishir, Andrew, and Mark for imparting their valuable lessons to us 🙏🏼.
Next up, we’ll be highlighting tips on user acquisition from the founders and early execs at Loom and Dropbox. Like what you’re reading? Hit this button to subscribe 👇