Ecosystem design

Proof of Concept，Proof of Concept is a digital publication about creativity and experimentation for designers, builders, and entrepreneurs.关注

I love ecosystem design because it forces you to consider design beyond the product boundary and its interface. Instead, you work through the conditions and capabilities needed for people to be success on your platform.

I’ve ben fortunate to see this take different shapes throughout my career. At ExactTarget, the ecosystem formed around enterprise marketing teams and the client services agencies who helped them operate at scale. At One Medical, it lived in the care network between patients, providers, employers, and the operational systems behind them. At Webflow, we went 0-1 in building out the developer platform and marketplace. The ecosystem grew through libraries, partners, apps, and community builders. At Replit, the ecosystem was the creation environment itself: a place where people could learn, build, run, and share software. At Atlassian, it is a System of Work that now includes products, marketplace, partners, ventures, and agents. Each version served a different purpose, but they all taught me the same lesson: ecosystem design is about creating the conditions for mutual value exchange.

The next era of software will be both more decoupled and more integrated. To survive, the new moat is a bridge. We’re told constantly that taste and judgment will make companies unique; no doubt. I would argue that a skill just as important will be World Building. When you bring a world builder mindset to ecosystem work, the product becomes bigger than the company. It becomes a place where partners, integrations, and communities need to be intentionally tended.

Defining ecosystem

The word ecosystem itself is vast and loaded, so let’s define it in the context of technology companies and startups. It describes the world that forms around a core platform: the products it connects to, the people who build on it, and the partners who help it reach more customers.

Integrations
Integrations are the bridges between your product and the rest of a customer’s working life. The realistic view is that no company lives entirely inside one product, which is why integration work is so important. It helps value move across tools instead of trapping it in one place.

Examples: Jira, GitHub, Slack or Microsoft Teams apps, HubSpot, Shopify

Partnerships
Partnerships happen when your company collaborates with another company beyond the integration, often by finding mutual value exchange and distribution. This could be a branded partnership or an official commitment to a product integration. Partnerships are strategic levers.

Examples: Replit + OpenAI, Figma + Google, Stripe + platform/banking partners

Marketplace
A marketplace is the storefront for third-party value. It gives customers a place to find useful extensions of the product, and it gives builders a path to turn their knowledge into something reusable.

Examples: Apple App Store, Atlassian Marketplace, Webflow Marketplace

Developer platform
A developer platform is the workshop bench of an ecosystem. It gives builders the primitives, rules, and confidence to make something sturdy on top of your foundation.

Examples: Stripe APIs, GitHub Actions, Shopify app platform

Community
Community is the gathering place around the product. Done right, it is not merely a marketing motion. It is where people teach each other, organize around what matters to them, and carry the product into contexts the company may never reach on its own.

Examples: Webflow Community, Figma Community, Salesforce Trailblazer Community

Corporate development
Corporate development is a strategic arm of the ecosystem. The company may invest in, acquire, or strategically support startups to accelerate strategy.

Examples: Salesforce acquiring Slack, Figma acquiring Diagram, Atlassian Ventures investing in Figma

Simply put, ecosystem is what happens when a product becomes a place where other people can build a future for themselves.

Designing ecosystems

Designing for ecosystems is imagining the ceiling and taking the highest altitude approach possible in the experience. This is extensibility and ensuring the primitives and platform foundations you set are enduring over time; reducing unnecessary change management. I’ll share a few tips from my time designing for ecosystems that helped me with approaching it.

1) Design the whole customer loop
It is not enough to design the API, marketplace listing, or install button. A customer needs to discover what is possible, feel confident in what they are installing, understand how it fits into their workflow, and know where to go when something breaks.

A builder has a parallel journey. They need to understand the primitives, make something useful, get it into the hands of customers, and improve it over time. Ecosystem design is where those two loops meet.

2) Treat 3P as users with business models, not endpoints
Third-party builders are not abstract extensions of the roadmap. They are people and companies trying to build livelihoods on top of your foundation. When they succeed, the product becomes more valuable. When their path feels unclear or second-class, the ecosystem becomes fragile.

3) Build customer relationships and trust
Ecosystems create leverage, but they also create risk. Customers need to understand what they are installing, who stands behind it, and whether it will keep working. Trust design is ecosystem design because the ecosystem only works when customers feel confident enough to bring it into their real workflows.

4) Community is not just a marketing channel
I am an avid believer that community done right is about ecosystem, not only marketing. Community is where people teach each other and reveal what the product wants to become next. The best communities are not audiences waiting for announcements. They are co-builders.

5) Docs as a product
Anyone who works in developer relations or technical products know how important Docs are for the ecosystem. It’s the front door and first impression for people building on your platform. Developers notoriously don’t like being marketed to and want to get started. Building the right documentation, starter kits, and resources are essential for the right first step to build trust. If the examples are strong, the ecosystem gets a shared sense of quality.

Gaining experience

If you’re interested in getting into ecosystem design, the best way to learn is to get closer to the places where the product touches the outside world. You don’t a formal ecosystem role. Build the muscle by meeting the customers where they are; in the community, events, and meetings; the bridge builders to what your company makes.

Work near the extensibility layer
Look for projects near the extensibility layer: API work, integration flows, marketplace surfaces, app review, billing, or developer experience. These are the places where the product starts behaving less like a single object and more like a platform. Even if your role is small, you will learn how much design work lives in the connective tissue between product capability and ecosystem trust.

Shadow non-design teams
Ecosystem work is cross-functional by nature, so spend time with the teams closest to the edges of the business. Partnerships and developer relations are obvious places to start. Solutions engineering, customer success, support, corp dev, and community will also show you where the real friction lives. These teams know where customers are hacking around gaps and where builders are creating value despite the platform.

Emulate the 3P customer
The best ecosystem strategy makes customers feel like the product is bigger than the company. Talk to the people who depend on the ecosystem to keep their workflows running. Ask what they trust, what they avoid, and where the product should connect better with the rest of their world. Better yet, start building with them.

Gain fluency on primitives
You do not need to become an engineer, but you do need to understand the building blocks. Learn enough about API shape, webhooks, permission models, SDKs, sandboxing, versioning, and data models to ask better questions. Ecosystem designers are most effective when they can translate between technical constraints, partner needs, and customer outcomes.

The goal is to become the kind of designer who can see both the object and the orbit around it. Most designers are trained to improve the product surface. Ecosystem designers learn to improve the conditions around the product so other people can participate.

Ecosystems are grown, not built.

Economic empowerment is one of the pillars that influences me in building software. When you work in Ecosystem, you foster relationships with humans building their livelihoods on your platform. It’s a tremendous responsibility (and privilege) to build for them. There is no such thing as overnight success in the ecosystem. You must grow it through tending the garden together. This is what makes the design challenge of ecosystem so difficult yet gratifying. I couldn’t see myself doing anything else.

Hyperlinks + notes

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论