← back
· 10 min read

My Onboarding Journey at Chainflip

It's been already over 6 months since I joined Chainflip Labs, but it feels like a year. There's so much to learn about this industry and it moves so fast that you need to become really good at getting signal from noise. As a Product Manager and enthusiast of this industry, I'm enjoying every bit. There's nothing like working in the industry, as an insider.

Let me share what's different about onboarding into a web3 company as a Product Manager, particularly Decentralised Finance (DeFi).

Since we are working with people's money, working at a fintech, will give you a good head start. However, working on decentralised projects is a completely different sport.

My first three months

Every time I had to onboard a new company, I've been using an "onboarding template" for my first three months at any company. You can think of it as a blend between a checklist list and a journal. I'd use this template to go deep into three main areas:

  • The Product: What exactly is the product? What problem does it solve? Who is your audience? Learn every detail
  • The People: Who is part of your immediate team? Who are your key stakeholders? What are their goals? Build relationships
  • The Process: What are the core processes? What's working and what's not? What needs immediate attention? Get the big picture

In addition, I'd also include anything that is worth writing for future reference, including what doesn't fit in any of the main areas. This could be literally anything from observations, reminders or action items.

The Product…and the Protocol

I always like to start with the product strategy. Do we even have one? How does that connect with the business strategy? In the startup world, is unlikely to find a nice document describing the overall strategy. That doesn't mean there isn't one. It's just that it's living in people's heads.

As a Product Manager, my job is to get all that context, digest it, and come up with a product strategy we can use to launch successful products.

My first weeks were a combination of 'read everything you can find' and 'talk to everyone'. Pretty standard advice, but in a crypto project you will find a lot more technical docs, including a whitepaper. Almost all on-chain projects have one.

Hold on, but what is Chainflip again? You may ask. Chainflip is a cross-chain decentralised exchange. There are a couple of things that make the protocol unique like a novel Automated Market Maker (AMM) using Just-In-Time (JIT) liquidity, but essentially, the benefits are great pricing, low slippage and native assets (no wraps). Chainflip is not yet another bridge.

Why it matters? Because major spot markets involving different chains are still dominated by centralised exchanges — like Binance, Coinbase or FTX. Chainflip's ultimate goal is to do what Uniswap did for ERC-20 tokens. If you want to know more about Chainflip, check our docs.

In this case, the protocol is the heart of the company. The "products," as we know them, are built on top of the protocol. Although the protocol itself could be considered a "platform product," for simplicity we will discuss them separately. Furthermore, the protocol is open to anyone who wants to build upon it. This is the beauty of open source and composability, and it is my favorite thing about web3.

Does this sound a bit too technical? You're not wrong. It's important to understand that any blockchain project will require a bit more technical knowledge than the average role. As a former developer myself, I had to push myself to better understand how blockchain protocols work. The implications are very different from what I was used to, and it's been a while since I've had to invest this much time in connecting the dots on the tech stack. But I really enjoy it. After all, Im still an engineer at heart.

In summary, our overall business strategy involves both end users using the product portfolio and other projects building on top of the protocol as well.

Here is a list of the products I am now responsible for:

  • A Decentralised Exchange (DEX) Aggregator
  • A Block Explorer app to monitor our own app chain, the State Chain
  • An Auctions app for those operating nodes in the network
  • An SDK for devs to build on top of the protocol

The People

This area is as critical as any other company. If you did your due diligence during your interview process then you got a good grasp (or you should) of the quality of humans you will be working with. This is the chance to see them in action. You want to start building relationships with your immediate team, your peers and key stakeholders. This is what I did:

  • Set 1-1s with everyone: Not just to introduce yourself but also to learn as much as you can about them as a person. You need social capital to get things done and to get it, you need to invest in relationship building. I also asked what they thought my role was, but this one deserves a full post.
  • Listen, listen and listen again: Stop talking. This one is particularly difficult for many PMs. I often seek feedback from my peers so I don't fall into the trap. Listen to understand, not to reply. Learn where the team is coming from as there might be recent changes that might be too hard to change, again. If it's not broken, don't fix it (for now). You can always revisit that topic later. Be curious and understand people's goals. Only then you can support them effectively.
  • Don't try to 'fix' anything yet: Another tough one. Don't try to suggest any solution and avoid at all costs to 'judge' the status quo. I find this one the hardest personally. Remember, you are at the listening phase at this point, but don't forget to take notes! You will need them later.

After some time, you will have a good overview of your environment and can make an assessment on how to proceed with making changes.

Now that's about the people within the company. Overall, nothing very different from any company you would join. However, there's another side to consider here and that's the community.

In web3, the community can break or make a project. There are plenty of examples where the community stepped up to contribute, pushed back or just voiced their opinions. The teams often reach out to the community to test the waters on critical decisions.

During the hiring process, you can already join the community in Discord and get an idea of the project 'vibe' beforehand. You can learn about the behaviours the team rewards and punishes, the level of engagement, and the level of enthusiasm. That's very revealing about a project.

Having a community you can reach out to for feedback is the best thing it can happen to you as a Product Manager. You can always lean on the community to get feedback on ideas, features, prototypes, etc.

The Process

When it comes to processes, it varies a lot depending on the company, the team and the role you have. It is expected that a small startup would have loose processes, as the need to adapt to change quickly is greater than well-defined processes.

During my first week, I soon discovered some good practices were in place and others were tried but failed. Some of the existing processes were introduced very recently as well. I also had the opportunity to be the 'fly on the wall' during a post-mortem session about a failed launch attempt of our testnet. This was gold for my onboarding since I could understand how decisions were made, what 'ready' meant, and the key roles during the process. I could quickly recognise what improvements we could apply immediately and make sure the next time was successful.

I had very little understanding about this testnet but I knew how to launch things so I gathered the key people in a room and start asking questions:

  • What's the purpose of this release? What does success look like?
  • What's the scope? What is still missing? What are test cases?
  • What's the comms plan?
  • Who is accountable for what? What did we learn from last time?

We came up with a good plan (that became a template), that included a schedule, action items and owners. That was enough for us to successfully launch Perseverance 0.5 early November 22'.

Beyond launch-related processes, there were a few key meetings. There was a session to discuss the overall engineering roadmap. The team leads will come together and talk about what's ongoing, and what's missing and sometimes agree on tentative dates. This session would also cover any planning and dependency aspects. The purpose of this meeting was clear to me but the format needed some love. I had little context at first, so I refrained from pushing for changes. However, over time, we were able to move away from using GitHub issues, created templates for spec-ing out work, established better milestones, and addressed technical discussions separately. One of the biggest pain points was the lack of details captured during these discussions, leading to a misalignment of expectations after a few weeks only. We are still running and improving these sessions and they are key to our planning process.

Another session to discuss communications and marketing efforts. With a clear agenda, we align with at a company level what is coming up. Engagement with the community is key, so it's important to keep them informed and involved. Take the testnet as an example. We wanted people willing to run validator nodes to help us test the network. If you don't have a strong community you will struggle. This is quite different from the typical web2 application. Keeping the community involved and engaged across all our channels (Twitter, Discord and Telegram) is part of our day-to-day activities.

Finally, what caught my attention was a meeting dedicated to discussing company affairs. This meeting would include leads and the executive team to align and calibrate decisions, such as investor updates, milestones, 360 review processes, company trips, holidays/remote requests, among others. Once again, this was gold for my onboarding as it was a perfect place to absorb context.

All these meetings will often end up with action items on different task boards. Very lean.

To be continued…

So far, I covered my onboarding at a very high level. After all, when I joined, my job was to learn everything I could. However, I'd focus on the formerly known as the 'web' team after a few months in. This squad is closer to the typical web2 team but with a stronger dependency to the protocol team. My job is to introduce a better planning and discovery process, making sure the scope is clear, dependencies are sorted and design is ahead of development. Involving our community members in product decisions was also missing and so I began making them part of our development process via surveys, Discord groups, and usability tests.

Once we officially launch the product, the party will have truly started.

I could continue but I want to keep this one short. I think some of the topics I mentioned deserve their own post, so let me tell know if you want to dive deep into a specific topic and I'll do my best to share my experience so far.

Working on a blockchain project like Chainflip involves concepts like decentralisation, open-source collaboration, market knowledge and community. This makes Product Management a completely different sport here, but a very fun and exciting one.

Until next time 👋🏼

David