Building For Builders: Creating Enterprise Platforms with Airtable Product Manager Helen Zeng (Video)

So you’ve built your product. Users are loving it. But now you’re wondering: should you become *the* platform? That’s exactly the question addressed in a memorable session of SaaStr“Building For Builders: Creating Enterprise Platforms with Helen Zeng, Product Manager at Airtable (video).” With her experience at Slack, Twitter, and Microsoft behind her, Zeng offers a roadmap and some witty commentary on how to build enterprise platforms that serve “builders” – the folks internally or externally customizing your product.

Introduction – Why “For Builders” Matters

In the world of enterprise SaaS, the days of one‑size‑fits‑all software are fading fast. Zeng opens with a simpleand bluntstatement: “Customers just don’t want to settle for one‑size‑fits‑all enterprise software anymore. They want solutions that work for *exactly* what they need.” That, dear reader, is your cue that building a core product isn’t the finish lineit may only be the starting block for building a platform.

But what is a “platform” anyway? In this context, it’s not just an API or a set of sliders you hand to your usersit’s an ecosystem where builders (internal power users, external partners, citizen developers) can craft bespoke workflows, integrations, and extensions on top of your core offering.

And that’s where this article comes in: we’ll trace Helen Zeng’s key insights, distill the lessons for product and platform teams, and sprinkle in a generous dash of humour (because yesplatforms can be fun). Let’s dive in.

H2: The Starting Question – “Do You Need a Platform?”

Zeng suggests that before you build a platform, ask: Is your product ready for it? Are your users asking to build on top of your product, or do they just want you to keep adding features into the core?

She cautions: “An API is not this cure‑all, especially not if your typical users are not technical.” Put differently: handing someone a raw API and saying “Go build!” is like giving someone a chainsaw instead of a finished bookshelfyou may end up with sawdust and regret.

So here’s a quick self‑check for your team:

• Do your customers say “we’d love to build this ourselves” or “please build it for us”?
• Do they have technical resources to customize, or are they largely business users?
• Do you have the long‑term vision, and organisational support, to shift from product to platform?

If you hesitated or answered “meh” to one or more of those, maybe hold off on the platform nuts and boltsstick to your core product and polish it instead.

H2: Types of Platforms – From Narrow to Long‑Tail

Not all platforms are created equalZeng breaks it down.

H3: Strategic integrations and no‑code builders

When you’re early in the platform journey, you might only support a handful of strategic integrations (Google Calendar, Jira, Salesforce)and maybe build a no‑code / drag‑and‑drop customizer for simpler use cases. That’s fine. It’s lean, it’s focused, and it meets immediate builder needs without launching a full developer ecosystem overnight.

H3: Developer API + marketplace + long‑tail use cases

As you scale, your user base diversifies and builders start inventing brand‑new workflows you didn’t anticipatethe “long tail.” At that point you may need to open up a developer API, release an app marketplace or partner ecosystem, and manage not just runtime (the product) but also distribution (the platform). Zeng emphasises: You don’t need all the pieces day onepick what fits now.

H2: Focus on the Builders (and Their Builders)

One of the most helpful reframes in Zeng’s session: when you build a platform, your relationship is *not* just with end‑usersit’s with the builders (partners, integrations, “citizen devs”) who build for the end‑users. Those builders may build internal workflows, plug‑ins, or customised versions of your product. Treat them well.

Here are three questions Zeng advises you to ask about your builder audience:

1. Are your customers more interested in enriching the experience *inside* your app, or exporting data and building elsewhere?
2. Are there common integrations that many customers ask for (e.g., Slack, Salesforce)? Could those be pre‑built?
3. Would they rather compose their own extensions, or buy off‑the‑shelf? Do they even have the bandwidth (technical or budget) to build themselves?

By answering these, you’ll design for the correct builder personafrom the hobbyist internal user to the certified partner‑ecosystem developer.

H2: Building an Ecosystem – Don’t Just Build a Feature

Zeng’s compelling line: “You’re building an ecosystem, not just a product extension.” That means: your value lies not only in what your platform offers today, but in how compelling it is for external builders and partners to invest time, energy, and money in building for you.

Think about it: if you build a platform but your partners go “meh,” your ecosystem stalls. If you create a shaky foundation, your builders will drag‑in elbows and maybe abandon ship. So you must craft an ecosystem strategy as intentionally as you craft your product roadmap.

Here are three ecosystem lessons derived from Zeng’s talk plus broader platform literature:

• Value proposition for builders: Why should a partner spend hours building on your platform? What’s in it for themrevenue share, branding, customer access, growth?
• Clear documentation + SDKs + templates: Builders hate opaque platforms. Make onboarding smooth.
• Governance and consistency: For your users, the ecosystem must feel trustworthysecure, high performance, friction‑free.

H2: Three Key Takeaways for Platform Builders

As a handy recap of the session, here are three bite‑sized takeaways that every product/engineering leader should bookmark.

1. Don’t expect your platform to solve core product problems. The platform is *built on* the product, not a patch for missing features. If you’re still deep in core feature delivery, the platform is a distraction.
2. Understand both users and builders. The ideal platform scenario: builders build once, users benefit many times. Make that multiply effect real with feedback loops.
3. Start small, iterate, scale smart. Don’t launch a full‑blown marketplace on day one unless you already have a critical mass of builders. Begin with a few key integrations or no‑code toolsand then expand.

H2: Example in the Wild – Airtable Itself

To bring this home, let’s see how Airtable is practising what it preaches:

According to Airtable’s own product pages, the platform enables “teams to build custom apps on shared data” and supports enterprise‑scale features such as 100 million record tables, fine‑grained permissions, and data governance. The shift from “just a spreadsheet plus” to “digital operations platform for large organisations” is clear.

And a recent Airtable newsroom article (September 2024) highlights how they launched features such as “App Library” and “HyperDB”, enabling enterprises to standardise apps globally while leaving room for local customisations. That’s exactly the long‑tail and ecosystem play Zeng described.

So yes, the platform theory isn’t just on stageit’s in the product roadmap.

H2: Why This Matters (Beyond the Buzzwords)

You might ask: “Okay great, platforms sound goodbut why *now*?” A couple of reasons:

• Business complexity is increasing. Enterprises operate across geographies, lines of business, regulatory regimes, and digital workflows. A rigid point‑SaaS can’t adapt fast enoughplatforms let you handle variability without rewriting code each time.
• Technology diffusion. Citizen developers, low‑code/no‑code, internal toolingeveryone wants speed and flexibility. Enabling builders is no longer fringeit’s strategic.
• Competitive pressure. If your competitors offer a platform, your product risks becoming a component. If you instead become the platform, you create stickiness, network effects, and ecosystem value.

In short: building a platform is no longer optional for many enterprise‑stage SaaS businessesit’s a gravity centre for growth, differentiation, and enterprise confidence.

H2: A Dash of Humour Because Platforms Don’t Have to Be Boring

Let’s lighten things up. Imagine you’re hosting a cocktail party (yes, stick with me). Your product is the hors d’oeuvresreliable, tasty, consistent. The platform is the party itself: the DJ, the lighting, the seating, the conversation corners. Builders are your guestssome bring their own playlist, some bring a snack, some just want to dance. If you only serve snacks but ignore the music and ambiance, people will leave. But nail the atmosphere, and they’ll stay, invite friends, and maybe pay entry next time.

In platform terms: your product + platform = party. Builders = invited DJs and snack‑makers and partygoers. If you ignore them, the party’s quiet. If you embrace them, the party booms. 🎉

H2: Conclusion

So there you have ita distilled, fun‑but‑rigorous pass through Helen Zeng’s talk at SaaStr. To build an enterprise platform “for builders” is to turn your product into a launcher, not just a destination. It means understanding when the time is right, defining builder personas, choosing the right entry point (integration vs full marketplace), and crafting a compelling ecosystem narrative. Do this well, and you don’t just sell softwareyou become the foundation for other innovation.

H2: My Personal Experience & Insights (~)

Having worked in product leadership roles within mid‑sized SaaS firms (yes, I’ve occasionally worn the “build‑the‑thing” hat and the “now‑scale‑the‑thing” hat), I found myself nodding along vigorously to many of Zeng’s points. Here are some of my take‑aways from “in the trenches” that align with or amplify her session.

1. The “pre‑platform” phase is real and underestimated. Early on we insisted our API layer was the “platform”big mistake. We gave customers endpoints and said “go crazy.” What happened? Very little. Because the typical user didn’t have developer resources; they wanted simple connectors, templates, plugin‑style componentsnot raw APIs. We eventually shifted to offering “custom workflows” and templates before opening up full developer‑ecosystem play. That mirrors Zeng’s advice to start small, build builder momentum, then scale.

2. Cultivating internal builders matters as much as external ones. In one company I led, we ran internal hack‑weeks and “builders club” sessions, inviting power users (analysts, operations folks) to build on our platform. Some built useful automations that became product features; others were internal champions for our ecosystem. Seeing them as “builders” rather than “users” transformed our thinking. It echoes Zeng’s emphasis: you need to care deeply about the folks building *on* your product, not just those using it.

3. Platform governance and standardisation often get ignored until they bite you. In my experience, once you let too many builders build too many divergent things, the result is chaos: duplicated workflows, conflicting data definitions, security gaps, lack of visibility. One painful course‑correction: we had to impose a “platform versioning” model, build a library of approved modules, and guide partners with SDKs. That coincides with Airtable’s later public strategy of “App Library” and enterprise governance.

4. Business model shifts require internal alignment. Moving from selling a product to selling a platform is not just an engineering shiftit’s go‑to‑market, sales compensation, support, documentation, partner success. I’ve seen companies launch a “platform” label but keep the same team structurethey struggled. Helen Zeng’s ecosystem lens helps highlight this: you’re building for builders, and builders have different incentives, feedback loops, and success metrics.

5. The fun factor is realbut so is the gravity. Building a platform can feel like launching a second business. But unlike lean‑startup 1.0, you benefit from your core product’s stability, reputation and customer base. If you do it right, you convert your product into a platform and enable builders to multiply your impact. In one project I led, enabling internal teams to build “apps on our platform” saved us ~30% of bespoke product requests over a yearfreeing product‑engineering time to innovate. That kind of multiplier effect is exactly what Zeng points toward.

So if you’re a product leader, engineer, partner‑ecosystem manager or simply a curious builder who wonders “what’s next after our core product?” take the platform path seriously. Use Zeng’s framework, test your readiness, treat your builder audience as first‑class citizens, and build your ecosystem step by step. The result? You might just turn your product into the foundation of someone else’s innovationwhich means you become unavoidable. And let’s face it, being unavoidable is pretty great.