---

We actually spent a few years working on Airtable before we launched publicly. We did tons of research on the space, talked to folks who had founded related companies in the past, did user studies/prototypes, etc.

Honestly, the things I most wish I had known couldn’t have been learned until after we launched and started getting an influx of real adoption across different industries.

What are the challenges you deal with in building out a horizontal product with unknown/varied use cases, and how does your team overcome those challenges?

Such a great question! It’s a challenge that percolates through to every role we have: from marketing to engineering to design to customer-facing.

Whereas vertical products can take a much more straightforward/linear approach to all of the above (at the cost of being reductionist, the vertical approach is to listen to customers, build the features they ask for, rinse and repeat), we have to always solve “meta” problems and try to think about what lego pieces we can build to solve not only one customer’s problem, but all other variants of that problem as well.

From a marketing standpoint, this means we also need to do a good job of speaking to the high-level value of Airtable, while also touching on the specifics of illustrative use cases to make those value propositions more tangible.

How different is it working as a product manager in an established company vs. a startup? What are the critical skills/experience/mindset that a product manager needs to develop if he/she wants to transition from corporates to startups?

I think the biggest difference is that a PM (well really, any employee) at a tiny startup must wear many many more hats than they would at a bigger company. There’s also less definition around what your role exactly is–both the company and your job are still in a formative, self-discovering adolescent phase.

I think the most important attributes to succeed in a transition from big to small company are: scrappiness, ability to quickly learn and adapt, and an indefatigable level of energy and passion.

What is your process like for telling a story on a website or landing page (Deciding what is most important, what order things should be shown, how to visualize specific elements? Would be very curious what rhetoric strategies you’ve discovered that work best.

This is a fun one because we’ve had countless internal debate about it. I think there’s a few competing philosophies, each of which has merit One is to try and frontload as much information on the splash page as possible–helping the customer make a highly informed decision before signing up.

All signups are then typically more qualified and more likely to convert to engagement/revenue. The other is to just try and intrigue the customer into signing up (Slack used to have a very simple landing page with nothing but a picture of a NASA rover on it, for instance).

We try to strike a balance of the two and provide a clear informational hierarchy (in both the header and footer, for instance) so that we can expose more information and backstory to those who want it, while not getting in the way of those who might rather just sign up and see what the product looks like.

What method of gathering user feedback have you found to be the most effective one?

Shameless plug for our own product – we use Airtable for everything, and user research and feedback collection are no exception.

We haven’t formally launched this platform yet, but here’s a sneak peek of the Airtable templates that Zapier and WeWork actually use for their own UX research (our own approach is fairly similar): https://airtable.com/universe/category/product-design-and-ux

What are the things to consider as a product manager transitioning from being a consumer technology PM to enterprise software?

Airtable, like Dropbox and Slack to some extent, sits at the intersection of consumer and enterprise, so it’s sort of an odd beast and the corresponding PM requirements warrant a longer discussion.

But in general (and comparing my co-founder’s experience as the Google Maps PM vs my own experience at Salesforce), it feels like enterprise software product management has more to do with balancing and triaging customer feedback, vs consumer product management relies more on a farsighted and cohesive vision (obviously enterprise also involves some of this, and vice versa).

Do you use any specific methods or frameworks to prioritize product features? Do you materialize your process in some way? (e.g. a weighted score table, a poster on the wall with value vs effort, etc.)

We use a combo of Airtable and open company discussions (sometimes live, sometimes asynchronous via Slack or a freeform Quip doc) to prioritize features.

We generally have a few cohesive themes that we’ve chosen (for instance, one might be “collaboration and growth enhancements”), and then the question is which features deliver us the most value vs effort within that motif.

How do you see enterprise sales evolving over time?

I’ve spent a fair portion of the past year talking to and learning from as many SaaS experts as I could (our advisors now include the CMO/head of sales from Slack and the SVP GTM from Zendesk).

We’ve seen a growing appetite for innovation via new technology platforms throughout all layers of an organization, from CIOs desiring rapid application development platforms, to end-users and team managers wanting to implement Airtable directly for their specific, team-level workflows.

IMHO what this means is that companies that can do a great job of serving both end-users via self-service adoption, while also having an effective sales process will benefit from greater sales efficiency and overall growth than those who do only one or the other well.

How much time do you spend with customers (IT and end-users) vs internal tasks (engineering coordination, stakeholders meetings, dashboard/ data interpretation)?

Probably 1/3 each for customer-facing, internal-facing, and non-customer external-facing interactions (recruiting, partnerships, PR, etc). But after a long enough day it all seems to blur together.

One thing I love about Airtable is how un-buggy and stable it is to me as a user, at least from my experience. How do you guys handle bugs at Airtable, especially with a platform that’s growing and adding in new features at a relatively quick pace? Do bugs get logged into Airtable and then prioritized? Is product involved in that prioritization in the backlog or is product hands-off with the process and lets the engineering team/others prioritize and dedicate a certain % of time to bugs?

Thanks! We do a few things:

1) We have a more rigorous QA process than probably most other startups. We have a weekly release schedule, and we have a full-time dedicated QA person who exhaustively tests every part of the product surface areas affected by a recent change. This does come at the cost of some agility vs startups that do daily releases, or even where you can push code directly to prod, but IMHO it’s well worth for us, since every second of bugginess or downtime could prevent our customers from getting their jobs done.

2) We use Airtable to keep track of issues. When an issue is surfaced, either by a customer who reports it to us or by someone internally, we log it in the issues base and flag any relevant parties internally. For instance, if it’s an Android bug, we’d flag the folks who work on our Android app. We have a person dedicated to triage to make sure nothing falls through the cracks, but for the most part it’s a very fluid, conversational process. We’ll often post it into an #issues channel in Slack if it merits discussion (i.e. “is this actually a bug, or just odd but intended behavior”)

What has your experience with freemium been like at Airtable? Do you think it is a good investment (supporting and nurturing free users)

To be honest, we did freemium partly as a matter of philosophy vs a purely pragmatic business decision.

Maybe we have our heads too high up in the clouds on this one, but we’ve always had a strong motivation to create a platform that creates as much value for as many people as possible–and if some of those people never pay us, but get real value out of the product and recommend it to others, we’re happy with that.

It’s hard to quantify whether we’d do better with a premium-only product, but IMO it’s been an extremely powerful driver for growth for us. It also lowers the barrier to entry by allowing people to experience the product value firsthand before paying. In our case, the value we provide may not be immediately obvious on day one, or at least we may not be able to articulate it 100%. Since we’re a horizontal platform, the value depends on each user’s own idiosyncratic needs. It also grows over time as users become more familiar with the platform and are able to apply it to even more use cases.

Your pricing model seems to center around retained revision history (and support at the highest level). How’d you get there?

There’s also space constraints, such as the free plan allotting a max of 1,200 records across all tables in a base. I think of it as a multidimensional space (where each dimension represents some variable of the tiered plans) and what we’re really trying to do is draw a boundary around pockets of usage that are more correlated with high business value, and therefore higher willingness to pay.

To that end, we’ve also added business-specific functionality such as SSO or administrative controls that are, for the most part, uniquely valuable to businesses.

What would you say a PM’s performance should be evaluated or measured on? Are there any benchmarks that would help determine they can move to the next level? (VP of Product or Head of Product)

I think this varies dramatically at different companies. At Salesforce, I’d say a big part of it was actually just experience–gaining more awareness of the broader enterprise playing field, becoming familiar with the nuances of an enormous product surface area, building mental models of and developing actual relationships with enterprise customers, etc.

In contrast, at a consumer company as well as at startups, I think there’s more emphasis on being able to step up and down the UX abstraction ladder.