[Temperature Check] Growth Workstream


The setting up of a growth workstream was proposed by community members in our last governance working group call. Our go-to-market strategy is currently being developed and goes hand in hand with product development in pursuit of product/market fit. We need to agree on a strategy and then explore treasury funded initiatives.

About Author

A brief introduction of myself as a working group and core team member. My parents named me Nassar and then I grew up and started building digital platforms and marketplaces. I’ve joined Radicle to focus on adoption, partnerships, and growth. We’re working on a number of initiatives already and are keen to use this workstream to bring a broader range of strategic thinking into the mix.


The Radicle Treasury is a community owned and governed pool of capital that can be used to develop and grow the Radicle network and community. Using the financial firepower provided by the treasury, Radicle’s community of tokenholders can propose, vote on, and implement initiatives that make Radicle a core piece of internet infrastructure. - source

The Radicle foundation has also set out it’s objectives and strategy for 2021 (link), which we should use as a way to focus treasury initiatives. One of the key objectives in this strategy is focused on adoption (a pre-cursor to growth):

Get every DAO in the world using Radicle adoption - The objective here is for more and more decentralized communities to use Radicle on a frequent basis for community-critical operations. This could take the form of using Radicle as an active mirror for their Github/Gitlab projects, using Radicle orgs for organization management and releases or funding their operations through Radicle (which will be possible later this year when Radicle-funding officially launches).

The growth workstream should focus around this project wide objective and strategise to achieve it.

Where things stand

Our framework for GTM must consider two key variables that dramatically influence what will work for us:

  1. How the Radicle project is structured - Independent teams launching products targetting different segments with different pain points/value add.
  2. Current stage of pre meaningful adoption - GTM market at this stage in development of a product is pretty challenging as growth initiatives are deeply interdependent with product development.

1. Radicle project structure

Challenge of supporting independent teams launching products targeting different segments with different pain points/value add. Each team feeds into one another’s work, but is currently also operating with it’s own assumptions on target users and usecases.

Active segment and usecase focus:

  • Alt-client + Upstream teams are working to get adoption from DAOs that want decentralised code collab infrastructure
  • Funding team is working to get adoption from open source projects wanting to raise funding from crypto people
  • Link team is working to get adoption from developers that want a new development workflow/methodology inspired by mailing lists

2. Pre-adoption for networked product

2.1. Product development

Product input is currently coming from a few key channels and being developed iteratively based on user and market insight.

  1. Build for yourself - teams are building what they want themselves
  2. Dogfooding - core team testing and input
  3. Handful of early alpha users playing with what’s been built
  4. Proposition testing - Define propositions for partners and have the sign-up to the most compelling one to try get early signal on product assumptions.

We probably need a framework for this given the current divergent nature of product development. Do we embrace the broad number of usecases with teams working on all sorts of experiments or do we take a more narrow strategic hypothesis driven approach?

Also, we need to think about priority sequencing given team interdependence. Teams should prioritise roadmaps based on organisational objectives and then team objectives. How is this currently being coordinated? Foundation builds org wide objectives and reviews team ones? Is that also done on a roadmap prioritisation level?

2.2. Network building

In networked products a large % of the effort is bringing together the right set of complimentary users that want to interact with one another. We need to proactively identify who we believe these are for each product and then bring together a minimum amount of each type to have new behaviours emerge.

Particularly when this is a multi-sided network, it requires a lot of narrowly targeted onboarding to ensure sufficiently value is added to each side. This makes it hard to launch broad usecases targeting different segments at the same time.

HOFFMAN: A network isn’t simply a web of users. It’s a launching pad for more robust communication, deeper trust, and greater understanding. New behaviors emerge as they grow accustomed to one another in this unfamiliar new venue. And that’s when the true value of the network first comes into view.

If there’s one thing Ev wishes he could tell his younger self, it’s about this emergent power of the network. EV WILLIAMS: “It’s about the network. The value is in the network, the value is not in the software that the Internet enables, the value is in the network, because there are so many implications of that.”

2.3. Growth initiatives

Working through onboarding flows right now to get clear picture on what it will take to onboard, activate (aha moment), and retain (ongoing engagement).

Current Funnel:

  • Acquisition - Manual BD prior to having bottomed out initial pipeline and targets
  • Activation - focus only on on-boarding at this stage and start building and testing thesis for activation.
  • Retention - This needs to be a result of on-going non-financial value via product market fit.

We will look at building and operationalising a sales and marketing system that is suitable to a DAO driven both by core and community contribution. At this stage pre-PMF stage we need to be laser focused on initiatives that drive adoption.


Our strategy should focus on targeting one segment at a time with both product features and growth activities being prioritised around activating a segment before moving to the next one.


  1. showing interest - downloading upstream
  2. fully onboarded
  3. activated/retention - still using past onboarding split into cohorts. number of users still using at end of week 1 or two. after being successfully on-boarded - 60-80% is target. (ref)
  4. PMF score - % very disappointed if shut down.


The objectives, framework, and tactics within that framework can be challenged and iterated on together. Once we have this infrastructure in place for the growth workstream we can discuss initiatives that require treasury funding such as rewards for those that adopt. Keen to get feedback in comments below and then once we’re aligned perhaps the next step is for us to put a initiative proposal template together for more formal proposals.


I am amazed how this could get lost in translation that much. A better framing is that we’re working towards distributed workflows beyond mailing lists.

1 Like

Thanks for the writeup Nas!
This is awesome.

I worked in software sales in a previous job and do product marketing now, so a lot of these points clicked for me. Some quick thoughts below.

Network Building

We need to proactively identify who we believe these are for each product and then bring together a minimum amount of each type to have new behaviours emerge.

I think this point of proactively identifying which users fit (and like Radicle) is super key. I highly recommend anyone to read about the concept of a “sales champion.” Here is a good article on it.

To summarize:
“The Champion, simply put, is the person that sells you or your product when you are not in the room.”

I think applying some of the similar sales tactics used in software would help with Radicle in building out a network. Granted we’re not “selling” software per se. But we are trying to get people to adopt it, which is similar enough.

Another great strategy, especially when dealing with an organization, is to not always focus on getting an entire organization, DAO, etc. onboarded. In some cases, it can make sense to work with a very specific individual or group within an organization to get onboarded. Again, you can think of this individual or group as the “champion.” Getting them onboarded can be a “success” even if the entire Org/DAO hasn’t onboarded (yet). Something useful to keep in mind when chipping away at a larger group of people.


I think those are good metrics that apply to all user personas.

I think it might be worth thinking about secondary metrics that are unique to each different persona. Basically, what does a successful user journey look like for each persona?

For example:

  • DAO: 2+ users onboarded to Upstream, multisig onboarding complete, …
  • OS Devs: funding feature turned on, wallet connected to funding, …
  • Local First Devs: project started, CLI configured, code saved in Upstream, code pulled from remote node, …

These more detailed goals for each persona can help us find gaps in documentation and product (i.e. if a user has trouble with reaching the goal, the problem is maybe with Radicle’s docs/product and not them).

What else might we add?

1 Question/Recommendations

  • What is “PMF”?
  • I’d recommend always putting the acronyms you use next to the full word the first time you use them, then use the acronyms later. I lost track of a few like Go-to-Market (GTM), Business Development (BD), and PMF (still can’t find this one).
1 Like

Figured I would draw a line in the sand based on my current understanding. Apologies if I missed the mark on this one. Agree that this sounds like a much better framing. Happy to have a chat or call to download how you’re thinking about this side of things.

With regard to the funding team I think besides the web3 projects there is a very long tail of successful OSS that are not monetizable by subscriptions or can raise money but still are used by millions think all the js/react plugins for example.

Ofc DAO + crypto funding seems like the perfect beachhead market. It is very timely that Angellist announced USDC-enabled syndicates.

Would you target existing DAOs that are still early in the development or prefer to attract the ones to be formed? I guess here we would need to provide the template/HOW-TO for the industry.

Very grossly described as:
FORK (or similar)
Changes these basic attributes
Connect your wallets

1 Like
  1. Agree that we need to learn from sales orgs and processes that came before. We’ve started putting personas together that I’m happy to share with you.
  2. Yup. Agree re aha moment. With the DAO segment moving into the adoption phase we’re doing a lot of thinking focused specifically on what success looks like there and should be able to share details as we progress.
  3. PMF = product market fit.

We need to decide on how to prioritise our targetted experiments. I’m currently focused on existing DAOs and testing how they respond to positioning Radicle as both decentralised infra and optimised workflows for attracting, onboarding, and funding contributors.

Interesting re how we simplify creation of new productive DAOs. Definitely think that’s something we should work on.

Thank you for starting this conversation @nas.

You are right that the key here will be for any growth initiatives to be in sync with where the tech / product is at.

Concerning metrics, I think that it’s important to remember that this is a peer-to-peer network so some of the definitions of these metrics or the way to measure them will be very different than traditional web2 networks & marketplaces. Generally it’s very hard to approximate actions on the p2p network and you might want to rely more on actions on Ethereum instead.

Concerning the actual proposed metrics:

  1. in terms of showing interest, not sure that downloading upstream is the right metric given that more and more folks will likely interact with Radicle through app.radicle.network and / or the cli when that launches
  2. for “fully onboarded” you could use a) has an ENS name b) has checkpointed something on Ethereum, as actions on the p2p network will be hard to reason about
  3. for activation / retention, again it would be beneficial to focus on Ethereum related activities.
  4. PMF score comes usually from a survey, but of course the challenge is that Radicle being a decentralized network means that there is a database or user data. So you would need to think of different ways to approach that without introducing too much bias.

In terms of frameworks, I don’t think that we need to innovate and we should use an existing one. There are lots out there, the most common one being: Awareness → Adoption → Engagement → Retention → Evangelism

1 Like

Thanks. Agree with above. Will have a think re metrics - pretty sure the right ones will be relatively obvious once we start seeing usage.

1 Like