Lessons from Co.Lab Fellowship - Part 1

"What is that beautiful house?"

For the past month, I have been spending several hours a day with Co.Lab Fellows who have been selected by RnDAO and ArbitrumDAO. We are at different stages of creating new projects, scattered throughout the world, and jump on a Zoom call twice a week to share updates from our user research. I highly encourage you to check out their work here, here, and here.

As part of the process, I’ve been focused on how Ourmada can learn more about its users. I wrote this piece about questioning assumptions, and we recently spent time on Twitter Spaces discussing market sizing. Since the start of Ourmada, I’ve talked to dozens of people about what it takes to bring transparency to off-chain activity in the Web3 space. I’ve conducted about a dozen formal user research interviews using Dovetail. Ourmada started out as DRM, a decentralized CRM, and has been evolving into different products while remaining rooted in transparency.

In the spirit of taking stock, this blog post outlines how things have been changing and the process of collecting feedback from customers, prospects, and fellow builders.

"Where does that highway go to?"

At the start of Ourmada, there was a rough sketch of how crypto companies can leverage their community to grow at scale. Having worked with several crypto projects - some with DAOs and others without - there was a clear similarity: a couple of dozen people work as a core team and many more people want to help the core team do more work. The connective tissue between the two types of people - what I call the Core Team and the Community - is usually a couple of asynchronous forums, an occasional community call, and maybe some governance for those who vote. It can be fine at times, but is fraught with unproductive tension at others.

For anyone who has ever had a problem trying to do something proactive in a web3 community, Ourmada wants to be your best friend.

In order to do this, we need to deeply understand, empathize and build for the needs of this end user. The first time I tried illustrating the opportunity set, as part of the Co.Lab fellowship, I used the following problem statement to encapsulate what Ourmada would solve:

• I am an internet-native interested crypto hobbyist
• trying to figure out if a new web3 project is legit and growing
• but I can’t make sense of what the core team is working on
• because there is a lot of noise and not enough live data from the core contributors
• which makes me feel despondent, like I want to bail before I even join.

The problem with this problem statement is that it is hard building for such a vague customer persona. In particular, 3 questions stand out.

1. Does this persona come from the Community or the Core Team? My working assumption is to stick with the former. This is an assumption that I regularly revisit as it informs the product, the sales cycle and who is the ultimate customer.
2. What does this person look, talk, and feel like in 2024? In 2017, I think I could have a vivid illustration of this persona; not so much anymore. Ultimately, this is a forcing function to really listen to prospects, users, and what people new to the space expect.
3. What market size does this persona have? This is important, but not particularly urgent at this point. I am going out on a whim and aiming to delight web3 communities without exactly knowing how large they will grow on the whole. This is a risk that I am willing to assume in the short run, but it is a risk nonetheless.

Part of this process is researching, interviewing, and testing any idea that I have about the end users, and then ultimately solving their problems.

"Am I right, am I wrong?"

So far this user research has been oriented towards the Community, and this may be a fallacy.

For starters, it is the Core Team that has been the decision-maker in purchasing new tools for the community, so they are the most direct path to revenue. Additionally, the Core Team adopting a tool like Ourmada will face the most thrash to their daily workflow, so they feel the change that any new product brings.

This natural bifurcation of the people that I interviewed during user research of Core Team and Community led me to outline explicit assumptions. As an example, I laddered them up as:

1. Weak form assumption: Web3 Project Core Teams are willing to spend money to grow their Community.
2. Semi-strong assumption: Web3 Project Core Teams are willing to spend tens of thousands/year of dollars on tools to grow their Community.
3. Strong assumption: Web3 Project Core Teams are spending tens of thousands of dollars/year on tools to grow and engage with their Community actively using this tool.

I’ve found evidence of the first assumption being true. Moving to the third assumption, there is less certainty that Web3 organizations are willing to invest money in transparency AND many hours of their day to use the tool.

The reality seems to look more like this:

What could be a cool new transparency tool for the Community could simultaneously become a productivity drain for the Core Team if it doesn’t seamlessly fit their existing workflow.

This can be a real deal-breaker in the sales cycle and a key part of my research. User research, prototype feedback, and sales pitches act as evidence to what kind of assumptions we should be working with.

This is only one of the lessons, we’ve learned from Co.Lab Fellowships and user research interviews. There are other important parts of the process such as learning in public, fine tuning business models, understanding the market size, etc.

"My God, what have I done?"

Based on the user research findings and as a milestone for the Co.Lab Fellowship, I’ve updated the problem statement to the following:

• I am a knowledge worker
• trying to get a real-time transparent view of a web3 project
• but there is a divide between the Community and Core Team
• because there is a lot of noise and not enough live data from the Core Team
• which makes me feel frustrated enough to not be part of the Community

Without going into each part of the statement, I found a couple of things useful for Ourmada.

Give the persona a name: Bifurcating personas into Community and Core Team is inexact but extremely convenient. If you are part of a web3 project, you know if you occasionally checking in or contributing (Community) or whether you are actively working everyday to solve urgent problems (Core Team). Making my customer profile simple gives the team an efficient way to talk about the needs to be met.

Zoom out a little bit if you are having trouble focusing: The “who” of my problem statement went from an internet-native interested crypto hobbyist to a knowledge worker. With the former value, I really had trouble pinpointing what the persona was. With the latter, I may be dinged for being too general, but our team knows what a knowledge worker is. It may be a Western-specific corporate lingo but it is easy for us to picture. Additionally, it is inclusive to a web3 people today as well as those who will join in the future. It is also excludes some of the shallow and ephemeral participants in the space like air drop hunters, token speculators, trolls, etc.

Don’t try to try and fit it all in. The updated statement is illustrating the problem as being one of retention. That is not really what Ourmada is all about. Our vision is to make web3 projects better. A large part of that is to grow projects by bringing in more revenue with smarter treasury analysis, sales leads qualifications, and more transparent operations processes among other things. Trying to fit all of this product as a solution to a single problem is kind of tricky. In order to avoid being verbose, it is okay to just illustrate an easy to understand problem. The crux of this problem statement is that the end user will leave the Community and the project if there aren't basic transparency tools. That is enough of a problem. Sure, you could talk about how difficult it is for projects to generate revenue, or what level of transparency is useful for different types of projects, but you don’t need to.

“Letting the days go by

Before I wrap up this post, kudos anyone who understands the reference in the section headers. Sometimes when writing posts like this, I feel like a talking head. 🙂 But seriously, there will be follow-up blog posts on how user research is doing, product development is taking shape, and general thoughts on what Ourmada is seeing.

‍