From feature factory to platform product: why every PM should think about APIs

The reality check

Let me share something that took me a long time to truly understand: your engineering team will never be big enough. And that’s actually a good thing.

I’ve worked in companies ranging from startups to enterprises like Amadeus and Miro. No matter the size, whether you have 10 engineers or 1,000, you’ll always face the same brutal truth: there are more valuable features to build than there is capacity to build them.

Take any successful SaaS product today. They serve dozens of industries, each with unique needs. They need to integrate with hundreds of different tools, from mainstream CRMs to obscure industry-specific software. And that’s not even counting the thousands of proprietary internal tools enterprises have built over decades. You’d need an army of engineers just to build integrations, let alone innovate on your core product.

The traditional response? Hire more engineers. Scale the team. Sprint harder. Create more scrum teams. Optimize velocity.

But there’s a better way. And it starts with changing how you think about your product.

"You can continue playing the feature factory game, hiring more engineers, sprinting harder, and still falling behind customer expectations. Or you can change the game entirely."

Anthony Roux, Head of Product, Developer Platform and Ecosystem @ Miro

From building features to enabling builders

When I started working on developer platforms, I witnessed a fundamental shift in how successful companies think about product development. Companies like Salesforce and Atlassian showed that the most powerful products aren’t those that build everything; they’re the ones that enable everything to be built.

Their leadership understood early that internal teams should focus on core product innovation while creating the conditions for an entire ecosystem to extend the product’s capabilities without limitations. This isn’t about outsourcing development. It’s about multiplication of value.

This isn’t just semantic gymnastics or Silicon Valley buzzword bingo. It’s a completely different mental model that changes everything about how you approach product development.

Think about it this way: when you build a feature, you create value for users who need exactly that feature, no more, no less. When you build a developer platform, exposing the technical components that allow others to build on top of or with your product, you enable potentially thousands of developers to create features you never imagined, couldn’t prioritize, or didn’t know existed.

Here’s a powerful example from the Atlassian ecosystem: apps like ScriptRunner and Tempo Timesheets started as simple marketplace apps but now have millions of users. Many enterprises wouldn’t use Jira without them, they’ve become that essential. These partners built multi-million dollar businesses while making Atlassian’s products incredibly sticky.

The multiplier effect

Here’s the oversimplified math that changed my perspective:

Traditional approach:

1 engineer → 1 feature → X users served

Platform approach:

1 engineer → 1 capability → 100 developers → 100 features → 100X users served

(Ok, it’s oversimplified, but you get the idea. The leverage is real even if the numbers vary.)

During my decade at Amadeus, I saw this play out repeatedly across different platform initiatives. We started with simple READ APIs for flight data, and suddenly thousands of travel startups were building innovative experiences we never could have imagined. From carbon footprint calculators that helped airlines meet sustainability goals to accessibility tools that made travel booking possible for visually impaired users.

The multiplier effect isn’t just about quantity. It’s about innovation velocity. External developers aren’t constrained by your company’s priorities, politics, or processes. They can move fast, experiment wildly, and serve niche markets you’d never prioritize.

Why “we can’t build everything” is your strategic advantage

I used to see our inability to build every requested feature as a weakness. Now I see it as our greatest strategic advantage. Here’s why:

1. It forces focus

When you can’t build everything, you must identify your true core value. For Miro, the visual collaboration and innovation platform, that’s the infinite canvas that helps product teams think and build together. Everything else? That’s where partners come in.

2. It enables specialization

A partner building exclusively for the healthcare industry will always understand HIPAA compliance and medical workflows better than a generalist product team. They can build deeper, more specialized features because it’s their entire business.

3. It creates compound stickiness

What keeps customers isn’t just effort invested, it’s a combination of deep configuration and unique value. When teams extend your product with custom apps, workflows, or industry-specific integrations, they’re not just adopting a tool, they’re building on top of it. That creates both technical switching costs and functional lock-in. Even if competitors offer similar features, they often can’t match the embedded, personalized setup the customer has already built. The result: 20–30% higher retention for customers using multiple integrations (ProfitWell, RollWorks).

The “never say no” strategy

One of my favorite outcomes of platform thinking is what I call the “never say no” strategy. Here’s how sales conversations transform:

Before platform thinking:

• Customer: “Can I integrate with Product Lifecycle Management tools?”
• Sales: “No, but it’s on our roadmap” (translation: maybe never)
• Result: lost deal

After platform thinking:

• Customer: “Can I integrate with Product Lifecycle Management tools?”
• Sales: “Yes. We have three options: check our marketplace for existing solutions, use our comprehensive APIs if your team wants to build it (our community and developer relations team can help), or work with one of our certified partners who can build it for you”
• Result: deal closed

This isn’t just theory. This pattern has helped close enterprise deals worth millions where customers needed integrations with internal tools, long-tail products, or industry-specific software.

For example, many retail and fashion customers use Product Lifecycle Management systems (PLMs) and need to manually copy and paste hundreds of product references to create new product lines. This isn’t Miro’s core product, but with the developer platform, customers can automate and integrate with the PLMs of their choice or work with a partner to do so. This creates incredible stickiness in the retail vertical. The same applies to automotive companies needing 3D model viewers integrated with their visual collaboration: not core, but platform-enabled.

The cultural shift: from protection to enablement

The hardest part isn’t technical. It’s cultural. Your team needs to shift from thinking “these are our features” to “these are capabilities everyone can build on.”

I’ve seen three common resistances:

1. The competition fear

“What if partners build better features than us?”

My response: fantastic. Your customers get more value, and you can focus on your core differentiators. Plus, it opens doors to collaboration or even potential acquisitions.

(And yes, don’t worry, we’ll still count the DAUs toward your team’s OKRs.)

2. The quality concern

“What if they build crappy apps?”

My response: that’s why you need proper governance, review processes, and certification programs. But remember, users will ultimately vote with their usage. The best apps rise to the top, the poor ones fade away, just like in any app store. Don’t let perfect be the enemy of good.

3. The revenue anxiety

“Shouldn’t we monetize this?”

My response: it depends on your strategy. You can monetize access to the technology (API usage fees), take a percentage of marketplace transactions (Atlassian takes 5-25%, Apple takes 30%, Salesforce takes ~15%), or choose indirect value over direct monetization. The key is understanding that retention improvements and ecosystem growth often far exceed direct revenue.

The executive conversation

Here’s how to pitch this to your leadership.

Don’t lead with the technology. Don’t talk about APIs, developer portals, or technical architecture.

Lead with the business outcomes:

• We can serve new verticals and use cases without expanding our engineering team
• We can increase customer stickiness by 20–30% through deeper integrations
• We can enable sales to never say no to a customer request
• (Optional) We can create new revenue streams through direct monetization or revenue sharing with partners

Show the precedents with verified examples:

• Atlassian’s marketplace has generated $3B+ in sales so far
• According to a study published by EA Journals, every $1 of Salesforce revenue generates $6.19 in partner-generated revenue, rising to $6.84 by 2028
• Shopify powers over 2 million merchants through more than 13,000 apps
• Stripe reached a $95B valuation in 2021 by being the API-first payment infrastructure

These aren’t just platform companies. They’re platform economies.

The long-term vision

Platform thinking isn’t just about building APIs. It’s about fundamentally reimagining your product’s role in the ecosystem. Instead of being a destination, you become infrastructure. Instead of owning all the features, you own the platform that enables all features.

There are two paths for product managers here:

• Feature PMs can build specific features while also exposing the underlying APIs, multiplying their impact and enabling new use cases
• Platform PMs focus on being capability providers, enabling both internal teams and external developers to build

The most successful products find the right balance: PMs focused on building the most critical features for their core business and ICP, while simultaneously enabling others to build and innovate around the edges.

Building a successful platform takes time. Typically 3 to 5 years to see significant impact and 5 to 10 years to reach full maturity. Atlassian’s marketplace took 7 years to hit critical mass. Salesforce’s AppExchange took 5 years to become a major revenue driver. But once the flywheel starts spinning, the compound effects are incredible.

I’ve seen this transformation at companies like Monday.com and experienced the journey directly while building platforms at Miro and other organizations. Every day, you see the compound effects: partners building solutions for industries you’ve never targeted, customers getting value you couldn’t deliver yourself, and products becoming increasingly essential to how entire industries operate.

The choice is yours

You can continue playing the feature factory game, hiring more engineers, sprinting harder, and still falling behind customer expectations.

Or you can change the game entirely.

Stop thinking about what features to build next. Start thinking about what capabilities to expose. Stop trying to build everything yourself. Start enabling others to build on top of your product.

The future of product management is about finding the right balance, building core features that define your product while enabling an ecosystem that extends it infinitely.

And that future doesn’t start with a grand transformation or massive investment. It starts with one simple question: what if we gave developers access to this capability?

One API. One developer. One solution.

That’s how platforms begin. That’s how ecosystems are born. That’s how products become indispensable.

Most successful software companies eventually become platforms. It’s not a question of if, but when. The question is whether you’ll start that journey intentionally today or be forced into it by market pressure tomorrow.

I know which path leads to better outcomes.