Back to stories

How Software Companies Win: Rethinking Org Structure, Product Teams, and Priorities with Airtable’s VP Product Ilan Frank

By Grace GeJuly 26, 2022

This is part three of our series with Ilan Frank on the topic of Enterprise Readiness. Read the first two installments: The Five Requirements of Enterprise Readiness and Everything to Know About Customer Advisory Boards

The software business has changed dramatically—a transformation accelerated by the shift to remote work and hybrid offices many of us experience today. To “own” a category in 2022, requires a new approach. In conversation with Ilan Frank, it became clear that during his years leading product teams at market leaders such as Airtable and Slack, he’s learned a few lessons. In this final piece from our conversation on enterprise readiness, I’ve collected some of his advice for product teams and software startups. Connecting each of these ideas is the reality that the business has changed. To stay competitive, discard the old rule book and rethink your organizational structure, GTM strategies, and opportunities to win.

Move From the Org Chart to the Network Chart

In today’s information world, traditional org structures and management feel constrictive and outdated. According to Ilan Frank, VP of Product at Airtable (and previously Slack) this new world order requires a new approach:

“It used to be that the organizational chart was the most important. Now it’s the network chart. We’re moving from an industrial age to an information age, and the reason the organizational chart was so important–and the reason why top-down command and control was created in the first place–is because we lacked the communication tools 100 years ago to communicate throughout a large organization easily. As companies were scaling, they needed that command and control for information to go up quickly and then down, which was the best way to disseminate information. When you think about it, that is exactly why the organizational chart was created: to help organizations scale. Now, as we move to an information age, we have projects where development happens in the Ukraine and support happens in Mexico. Marketing happens in Silicon Valley. That type of communication and that type of org chart and structure for organizations no longer applies.

We’ve entered the PLG (product-led growth) era, where software companies win customers through a bottoms-up sales motion, selling directly to the user rather than selling broadly into the enterprise (known as top-down sales.) Today, software purchasing decisions no longer happen at the management/Director/VP/C-suite level. That means that today’s software must deliver immediate value to end users, who then evangelize it across their team and the broader organization. Eventually, the message gets to IT, who request a meeting with the seller. 

Divide Product Management into Enterprise and Self-Serve 

With PLG emerging as a dominant GTM motion, organizations must adapt their approach, structuring product teams differently as they scale and ensuring that products satisfy the full spectrum of users (from individuals to the largest enterprises).

“Slack did this really, really well, and I encourage all the companies that I consult to do this. We separate product management into enterprise and self-serve. We had four pillars: enterprise, platform, core, and growth. Self-serve was a combo of core and growth. The enterprise pillar was working with the largest customers and getting a thousand requests. It’s very difficult to say no to all those feature requests from the IBMs of the world if you have unlimited resources. It’s good to carve out a set of resources and say we’re going to invest as a company 25%, 35%, or whatever aligns with your company goals on enterprise. That’s our bucket. We’re not going to harm all of our other goals as a company for enterprise. It was a forcing function to focus. And now, even having lived through that and led enterprise, that’s my recommendation to most companies, is to have that separation and that rigor.”

—Ilan

Enable Autonomy and Iteration For Winning Product Teams 

As a team leader, Ilan prioritizes two things: Automaty and Iteration.

“Autonomy: I want to create a process that enables autonomy, so groups feel like they don’t have to come to me to ask questions or to make decisions. They can go, innovate, and run as quickly as possible on their own. Two things are important here: One is alignment because, without alignment, autonomy looks like anarchy. Second, there’s a lot of information dissemination: company goals, group goals, metrics, customer stories, examples of teams that are crushing it, etc. All kinds of things are shared to ensure everyone is aligned.

Iteration: Teams that don’t iterate are at companies that stagnate and don’t grow. So I want to encourage iteration, which can be everything from OKRs to quarterly goal setting, to roadmapping, to CABs, to sprints, to prototyping quickly. These are the things I want to reward. These are the things I want to see and encourage with all of my directs to create, and their directs as soon as possible.”

—Ilan

Focus on Your Customers Before Your Competitors

It’s easy to get distracted–and hard to stand out–if the focus is on competitors and feature matching their products. 

“You need to stay ahead of your customers, not your competitors. If you look at Asana, Smartsheets, and Monday.com, they support fewer rows than Airtable. Just by that measure, Airtable seems to be doing fine. But if you look at what our customers need (millions of records per table), it’s a completely different ballgame.”

—Ilan

Customers come first. As mentioned in The 5 Requirements of Enterprise Readiness, software companies need to anticipate where true value lies and know where customers want to go. Often, what customers think they want is different from what they need.

“Customer value is not delivered by saying yes to the customer. That seems backward to many people, especially CROs and GTM teams. Usually, what the customer is asking for is checkbox features that someone (i.e., security) put a policy together for. This is not going to deliver customer value.”

—Ilan

That’s why Ilan recommends using Customer Advisory Boards (CABs) to understand the core needs of the customer better and create alignment with key customers around the product roadmap. 

Measure What Matters: What Slack Learned From Building their Marketplace

The developer community often sends the first signal that a product can become industry standard. When developers embrace a product and start building on top of it, network effects can carry that product into hypergrowth. To encourage “developer love,” many companies (Slack, AirTable, and Salesforce, to name a few) build app marketplaces to showcase those apps. But, as Ilan learned at Slack, it’s important not to build a marketplace “for the sake of building.” A thriving marketplace must feature apps that add real value for end users. As a best practice, Ilan recommends that product teams build (then test and refine) the types of apps they want to feature before opening the marketplace to third-party apps. To measure marketplace success, make sure to track app engagement, usability, and utility. Marketplace growth metrics (alone) can provide a false signal without the additional context of app data.

“It’s dangerous to build a platform for the sake of a marketplace without also using that platform yourself. Slack hadn’t built that many apps and seen their usage the way that we wanted. The apps that were being built weren’t apps that were fundamental to what we believed apps could do, like workflow and data management. We were building APIs for a marketplace without having developed the features ourselves nor lived and breathed the necessity for these apps ourselves. As a result, those APIs exposed to the marketplace were a completely different set of APIs used internally. It all needs to be on the same API set.

For many years, we looked at the growth of our marketplace as a measurement of success rather than tracking the engagement, usability, and utility of those apps. If we had approached it more from first principles (our team building apps that were truly impactful), we would have made different APIs available, different discovery of apps available, and different UI paradigms available for those apps to use. I think there would’ve been a very, very different set of apps that you would’ve seen.”

—Ilan

Don’t Try to Win on Product Alone: The Importance of Distribution and Marketing

It’s naive to think you can win on a superior product alone. When your company is at a scale to sell to enterprises, bundling, distribution, marketing, and aggregating mindshare become just as important, if not more.

“When I worked at Plumtree, it was the leading enterprise portal. Then Microsoft SharePoint came around; it was arguably not the better product. But Microsoft distributed it for free on Windows 2003 server and beyond. When you look at the market share of enterprise portals, they had overtaken us within a year and a half. Within two or three years, it was game over for us. We were sold to BEA, and then later, BEA was sold to Oracle, and I don’t think there are any more Plumtree portals around anymore. 

Fast forward to Slack. When Microsoft Teams came out, it didn’t affect the company’s direction as much as it should have. Our product was significantly better but they still grew insanely fast because they mastered the enterprise channel. They have mastered bundling. They have mastered enterprise marketing. They don’t need to be as good or the best. All they need to do is be good enough for IT to say, ‘We already have something like that.’ The Salesforce acquisition was hugely positive for Slack in winning the enterprise fight. It wasn’t about PLG anymore. It was about winning at the CIO, CEO level.”

—Ilan

As this is the final post from our “Enterprise Readiness” conversation with Ilan, I want to thank him for sharing his thoughts. In my conversations with product leaders it’s become clear that the best insights come from those who have “lived the problem.” The opportunity to hear how experts like Ilan approach their work is instructive for any product lead, regardless of sector or stage. Thank you, Ilan, for sharing.