Building an effective business development (BD) and growth function in crypto isn’t straightforward. Crypto introduces a unique set of dynamics that make it impossible to simply copy a web2 organizational chart or hiring playbook. And as fintech and financial services push deeper into the space, the landscape continues to evolve. The right BD profile depends entirely on what your company is building and what outcomes you’re targeting.
For instance, are you building on a public chain, focused on growing TVL and users? Or are you an infrastructure provider targeting fintechs and neobanks looking to embed crypto into their core products? The answers to these questions are going to vary, and so should your approach to business development and growth.
Before hiring, be clear about what your company is building, how you’ll measure success, and how a new BD or growth role can help you get there.
This article isn’t meant to be a step-by-step guide for every kind of crypto company. Instead, our goal is to share some guidance and a set of practical lessons drawn from firsthand experience building in, and working closely with founders across, the crypto ecosystem.
Several factors make BD and growth in crypto fundamentally different from web2:
Token design: Knowing when and how to use tokens as part of a partnership or joint incentive structure requires deep context of your target ecosystem, and a strong understanding of your own tokenomics. When applied thoughtfully, these initiatives can drive meaningful user acquisition from partner products. When misused, they can become costly experiments with little return.
Distribution: This often happens onchain, which means you’re thinking in terms of wallets, airdrops, and quests — not email lists or paid ads.
Decentralized governance: In some cases, deals can also run through decentralized governance, requiring buy-in from DAOs rather than a traditional executive team. This often means managing a broader and more complex set of stakeholders involved in the governance process.
Open source: Crypto often runs in open, permissionless ecosystems where much of the code is open source, so competition is usually more visible and successful strategies can be quickly copied.
These points aren’t relevant for all projects, and some may be more important than others, based on your product. But they represent levels that simply don’t exist in traditional web2 playbooks. If any of them are core to your product’s growth, they’ll directly shape what kind of talent you need, what experience to prioritize and how quickly that person can start doing real work.
Understanding which of the above dynamics matters to your product is critical and can shape everything from how you go to market to how you structure partnerships and measure success.
First, understand the need and what you’re trying to accomplish with this hire.
Before kicking off the hiring process, it’s critical that teams clearly understand why this new role will help drive success for their business.
A key part of this is understanding the exact function they’re looking to hire for. Below we outline a few common specialties, and their differences, within the umbrella of business development and growth as a starting point:
Note that these roles are not interchangeable. While they may sit under the broad umbrella of “business development” or “go-to-market,” they each require very different skill sets and success metrics. Expecting a single hire to do it all can lead to misalignment or underperformance. A common mistake is to assume that “a strong BD hire” will also own growth loops, revenue operations, and ecosystem building; in reality, spreading someone too thin across these roles usually means none of them gets done well. So before labeling the role, get clear on the impact you want it to make, and then use precise titles to avoid confusion. We’ve highlighted just how critical this step is for any role in other posts on hiring. This baseline step often gets overlooked at the start of the hiring process, and the oversight can snowball. If you’re not clear on what you actually need, it will affect everything downstream, from sourcing, screening, and setting candidate expectations to compensation structure.
Early on in a company’s lifecycle, hands-on execution matters most. Fast-moving startups need people who will make the most of limited time, budgets, and teams, and actively engage with potential customers and users — not just strategize, but actually do the work. This often means running outbound, sourcing and qualifying leads, leading discovery calls, becoming fluent in your customers’ problems and how your product solves them.
It’s also important to set clear metrics and goals for this first hire that are directly tied to your product. Examples could include: number of signed pilot agreements or integrations with relevant protocols, number of warm leads across priority verticals, or securing an important partnership in a key category.
The right BD targets, for example, will heavily depend on your product, which can be tricky before product-market fit. At this stage, it’s tempting to chase a major partnership — but that can backfire. Landing the wrong “big customer” too early may push your team to focus too much on a single feature request or bespoke integration, when another part of the product might be more important for broader market adoption. While strategic deals can provide distribution, credibility, or early revenue, they can also distract from the iterative learning needed to find product-market fit.
Of course, BD targets will evolve as the product matures, but without defined metrics and milestones, it’s hard to measure progress for any new role. Tie these metrics to compensation, aiming to set goals that are ambitious but achievable (and if you’re working with a token, see our post on how to approach token-based compensation).
After defining the expectations of the role, teams can then also consider timing, seniority, and experience, which we’ll cover in the next section.
First, a quick note on timing: Hiring a BD or growth lead can be a force multiplier, but only with the right profile and timing. Before product-market fit, you need someone scrappy who can help explore use cases, test what sticks, and co-develop your product features if needed. After product-market fit, it’s about scale: repeatable systems, clear metrics, and sticking to what works.
So how can founders make this first hire count?
| Before PMF | Hire someone scrappy who can explore use cases and validate what works. |
| After PMF | Hire for scaling. Someone who deeply understands pipelines, repeatable systems, and team management. |
Below are a few questions we get all of the time on who to hire, from seniority to crypto experience. Every company will answer them differently, but there are patterns worth knowing to avoid expensive missteps.
When hiring senior leaders, remember that, early on, being able to do the work matters most. Hiring hands-on resources is critical as you start to talk with potential customers and users. For this reason, bringing in a Chief Revenue Officer (CRO) or Chief Growth Officer (CGO) too early can be a costly mistake.
A true CRO/CGO needs a team to lead and a mature go-to-market (GTM) engine — one that includes repeatable sales processes, established customer success motions, marketing support, and a reliable pipeline — to fully thrive. Most pre-product-market fit projects don’t need all of this. If you’re unsure whether you need a CRO or CGO, you probably don’t. These roles are far more valuable once you have scaled. The line between needing a hands-on employee and a true executive isn’t always clear. Early on, you may need someone who can both lead and do (who can close deals personally and start building a sales or growth organization). Stay disciplined and wait until the business/GTM engine is ready.
This really depends on the nature of the product, and who you’re selling to. Are you selling to a developer-focused user base? Or are you selling a consumer-facing application? If you’re infra-heavy or protocol-first, then yes, technical experience is often required and very useful, even at the CRO/CGO level.
If you’re operating at the app layer, familiarity with technical concepts is important but a technical background is not necessary.
This depends on your product. For some categories, crypto experience is critical. If you’re building something like a Layer 1 or infrastructure protocol, prior experience in crypto is typically non-negotiable. This is because the underlying tech is complex, crypto-specific, and deeply intertwined with other foundational components of the ecosystem. And for certain projects, cultural fluency — understanding crypto-native norms, memes, incentives and community dynamics — can make all the difference.
That said, don’t overlook talent from outside the crypto industry. For many roles, crypto experience isn’t a hard requirement — candidates can learn the basics of wallets, protocols, and onchain activity. What you can’t teach, however, are the intangibles: customer empathy and strong communication skills.
The crypto industry is still maturing, and experience can be thin. The right hire from fintech, open source, gaming, or another frontier tech might bring a fresh playbook, precisely because they aren’t steeped in conventional crypto thinking. Some of the strongest strategies come from people who aren’t constrained by what’s always been done.
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.
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.
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.
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.
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:
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.
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.
Hiring for BD, growth, or marketing isn’t just about resumes — it’s about seeing how candidates think, communicate, and operate under real-world conditions. The best interview processes are structured enough to compare candidates fairly, but also flexible enough to adapt once you’ve met a particular candidate. For instance, a candidate may have highly relevant experience or a unique perspective that’s worth spending more time exploring, even if that shifts the process from what you originally planned.
Why this works:
A big part of business development is being able to learn quickly, focus on what matters most, and dig in when needed. In interviews, don’t expect candidates to already know your product. Instead, look for qualities that show they can adapt, problem-solve, and handle a fast-changing environment.
As a final note, take the time you need to assess candidates thoughtfully, but always respond promptly. Your hiring process reflects on your company, and even small signals compound over time to shape your reputation as a founder and team.
–
The key theme here is timing: hiring the right person at the right time can move your company forward quickly, while the wrong hire can set you back.
Before product-market fit, you need hands-on hires who can test, learn, and close early deals; after PMF, the focus shifts to scaling repeatable systems and teams. Clarity matters too: BD, growth, and marketing each demand different skills, and bundling them together is a common pitfall. And in crypto, added complexities like tokens, governance, and open source dynamics make it even more important to hire intentionally for your product and stage.
If you’re hiring or thinking through GTM org design, we’re always happy to chat.
***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.
