Core-or-Ecosystem Feature Rule
Build universal features internally and route specialized needs to partners
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 6
- Confidence
- 95%
The rule separates product capabilities according to breadth and frequency of demand. Features used by most customers most of the time belong in the core product because they define the shared experience. Features needed by narrower groups, or only occasionally, should be enabled through APIs and supplied by an ecosystem. This preserves a simple default product while allowing specialists to support subscriptions, payments, integrations, and other long-tail requirements. The mechanism requires disciplined product boundaries plus reliable extension points; merely refusing feature requests is not enough. Shopify applied this logic by keeping its merchant product minimalist while launching an API and third-party application platform that dramatically expanded the range of businesses it could serve.
Origin
Shopify's minimalist product philosophy grew from the Ruby on Rails community. In June 2009, the company launched an API that allowed third-party developers to extend merchant accounts without forcing Shopify to build every requested capability itself.
Core principles
- 01Keep the core product focused on common needs
- 02Let specialized providers serve the long tail
- 03Use APIs to expand capability without expanding complexity
- 04Protect clarity as the customer base diversifies
- 05Treat ecosystem breadth as a distribution advantage
How to run it
- 1
Map customer demand
Measure both the share of customers requesting a capability and how often they will use it. Distinguish foundational workflows from valuable edge cases.
Pro tip Use behavioral data alongside sales and support requests.
Watch out Loud enterprise requests can appear more universal than they are.
- 2
Protect the universal core
Build capabilities internally when they are broadly and repeatedly useful. Integrate them into a coherent default experience.
Pro tip Judge core features by whether their absence would impair the product's primary promise.
Watch out A large feature count is not evidence of a strong core.
- 3
Define extension boundaries
Create APIs, events, data models, and permissions that let external developers address specialized workflows safely.
Pro tip Design extension points around stable customer jobs rather than internal implementation details.
Watch out Fragile APIs shift complexity onto partners and customers.
- 4
Cultivate specialized providers
Recruit developers or vendors with expertise in underserved use cases. Give them documentation, distribution, and viable economics.
Pro tip Start with high-value gaps that repeatedly block adoption.
Watch out An ecosystem will not emerge solely because an API exists.
- 5
Govern ecosystem quality
Review security, reliability, compatibility, and customer feedback. Remove extensions that damage trust in the broader platform.
Pro tip Make installation, permissions, billing, and support ownership transparent.
Watch out Customers often blame the platform for partner failures.
- 6
Reassess the boundary
Regularly evaluate whether an ecosystem capability has become common enough to enter the core product. Preserve interoperability when changing ownership of a function.
Pro tip Use sustained adoption across customer segments as the promotion signal.
Watch out Copying partners opportunistically can destroy developer confidence.
In the wild
Shopify built an API that allowed developers to plug existing tools into merchant accounts or create new applications. Specialized capabilities such as subscriptions and payment services could then reach merchants without making Shopify's default product harder to understand or operate.
→ The platform supported more merchant types while its application ecosystem became a competitive moat.
A project-management company keeps tasks, permissions, and collaboration in its core product. Rather than building country-specific payroll modules, it exposes approved employee and time-record APIs to specialist payroll partners. Customers gain regional functionality while the core interface remains consistent.
→ The company expands internationally without maintaining every jurisdiction-specific workflow.
Common mistakes
Building every requested feature
Serving each edge case internally increases complexity and weakens the shared product experience.
Outsourcing the product's foundation
Core workflows that define reliability or trust cannot be delegated merely because partners are available.
Launching an API without incentives
Developers need documentation, distribution, customer demand, and sustainable economics before an ecosystem can form.
Is it for you?
Best for
It is best for extensible software products whose customers share a common workflow but require many specialized capabilities.
Not ideal for
It is not ideal for safety-critical functions or foundational workflows that the platform must directly control and guarantee.
From the transcript
“think about features that most of our customers use most of the time and build those, and features that some of our customers use some…”
“This just massively increases the reach of types of merchants that could use Shopify for anything or add functionality or do subscription sales or do…”
From the episode
The Shopify IPO