How to build business development and growth teams

Founders often ask how to structure go-to-market teams as their startup grows. There’s no single answer — but there are patterns that tend to work (and common traps to avoid). 

This section covers the questions we hear most often and what we’ve seen work across L1s, L2s, apps, and infrastructure projects.

Should BD, growth, and marketing report into the same person?

Maybe early on — especially if there’s one strong GTM lead. But over time, it makes sense to split these functions. BD is deal and partner-focused, whereas growth is funnel and product-focused, and marketing is brand and comms. Each has different team rhythms and metrics.

Do you need a customer success or integration support function early?

For clarity, customer success refers to managing relationships with existing customers, including helping with and troubleshooting existing product setups, and ensuring they continue to find value in a product and stay engaged (even buying more) over time. This function becomes more important for teams with complex, highly customized, or SaaS products. 

Early on, nimble product and development teams — who are often already entrenched in customer conversations — can handle customer success. However, if your product is implementation-heavy — like infrastructure, developer tooling, or protocol integrations — it may be worth investing in a dedicated customer success function (even if it’s not called that) sooner than later to ensure customers can fully adopt and benefit from what you’ve built.

When should founders split the BD function by segment or vertical?

Some teams organize around sectors: DeFi, NFTs, gaming, banks and financial  institutions, etc. This works after you’ve found traction in a core use case — not before. Otherwise, it’s easy to overindex on a single focus area before it’s proven out.

If you’re pre-product or pre-user base, keep the team flat. There’s no need to introduce complicated hierarchies at this stage. One experienced BD lead can cover multiple verticals at once.

What works with Layer 1/Layer 2 protocol teams?

For protocol teams, business development often comes with a unique set of challenges — largely driven by the underlying technology and the fact that these teams are building a network, not just a product. This often means that BD isn’t a single function, but a mix of complementary roles working together to grow the network.

Here are common segments that often work in unison:  

• Core BD: focused on growing the community of devs and projects building on top of the L1/L2.
• Ecosystem team: focused on grants, community, governance.
• Technical integrations team: support launches of partner projects deploying on the network 
• Geographic teams: handle in-language, in-region motions to grow local regional support for the network and address regional specific nuances

How should teams think about geographic expansion?

Unlike traditional product launches, crypto is often global from day one. So it’s important to prioritize regions where you’re already seeing adoption. Don’t force a full time regional GTM hire, until you’re seeing meaningful traction or interest in that region. 

That said, depending on your product, a junior community manager based in a country where early interest is emerging could strengthen your visibility and local user engagement. The right timing depends heavily on how much real product adoption you’re seeing in that region, and how much more growth you foresee there.

How should teams handle governance/community GTM?

Governance — the process of coordinating decision-making through a decentralized community —  is specific to crypto, and is also only relevant for certain projects. While traditional BD relies on hierarchical decision-making and direct negotiations, governance-led BD emphasizes community participation and blockchain-enabled transparency. 

For example, when expanding protocols across blockchain networks, community governance plays a starring role by crowdsourcing decisions through decentralized autonomous organizations (DAOs) or protocol governance mechanisms. DeFi protocols like Uniswap or Aave for example operate via DAOs and token holders who vote on proposals ranging from multi-chain deployments and protocol upgrades to treasury management and token emissions parameters.

To be successful, a BD leader will need to run proposals, activate delegates, and rally governance voters — it’s part BD and part community evangelism, including communication and campaigning. 

Below are some of the nuances when it comes to BD and governance that candidates should be aware of.

Not just sales, but product too: Governance forums are fraught with proposals at various stages, often aggregated over years of building and iterating; each vote will require that you understand the historical context of your specific proposal as well as how it fits into the evolution of its subject matter. So candidates can’t just bring sales expertise, they also need the product expertise to tell a compelling story and triage post-vote activity (e.g., communicating why a vote did or did not pass and implications for the protocol etc.).

Governance and whale influence: Candidates must excel in relationship and community building as well as explaining value to stakeholders. This is highly dependent on the governance proposal, but often entails a combination of garnering support from the larger holders (whales) via direct outreach and getting buy-in from the disparate smaller token holders through governance discussion boards and other community channels, like X and Discord.

Onchain vs. offchain dynamics: Like many successful community forums that are as much about picking up the phone as they are what happens online, proposals usually start offchain for feedback but culminate onchain for binding votes. This hybrid approach creates deeper relationships and trust but also invites scrutiny from the broader crypto community. 

The key is transparency and ensuring that even if much of the conversation happens offchain, all potential voters can clearly see where the conversation is happening, and how certain decisions were made. In many cases it’s critical to engage with the community during the discussion phase. Candidates must be able to craft clear and data-driven approaches to how they either propose or respond to a given governance proposal, while also having the skills to field and dispense public rebuttals.

Coordination hurdles: Unlike seemingly streamlined traditional negotiations, crypto  governance involves several different kinds of stakeholders, also across time zones, leading to decision fatigue or stalled progress. Candidates must be patient, organized, and have an acute attention to detail.

Common mistakes:

• Bundling BD, growth, and marketing for too long instead of giving each its own focus. Eventually one or another will suffer, since each requires deeper skills and priorities, once you have traction.

• Splitting by vertical or geo too early, before clear product-market fit. Specializing too soon comes with the risk of chasing the wrong markets before you know where demand is strongest.

• Hiring without technical support for integration-heavy products.