6 Comments
author

Based on my experience, here's what I've learned -

1 - A light touch

This means knowing how much process to implement to be effective, yet not overbearing. Crypto projects are very suspicious of PMs creating work simply for the sake of creating work or to "justify their existence" 🙄😉

2 - Flexibility

This means not being rigid about processes. Implement a flexible structure that supports the team as they continue progressing. Slow them down enough to make conscious decisions (this is HARD!). Don't ask them to stop completely to reassess and implement a heavy-handed process.

3 - Lead from the side

Expect to do a bit more work that you would with a non-crypto project. This means doing hands-on kanban board or issue updating, based on info the team provides. Don't necessarily expect the team members to update the tool themselves. This is one example. Another is structuring the process along with the team, as it continues moving along. Run alongside them and keep nudging things in the right direction.

Use supportive requests. Don't use demands.

This is only a start. I'm wondering if I should do an AMA on this. Let me know if you'd be interested in that...

Expand full comment

Good question. There are surely lots of different thoughts here, but I’ll share mine:

As always, it depends what the “product” is.

A user-facing dapp is probably the closest to a typical software product role that exists today. But customer research is much harder because of the ethos of privacy and attendant lack of tracking for most dapps. On the other hand, on-chain transaction data can be helpful for user behavior analysis. Also, it’s crucial to understand the trade-offs inherent in a world where users fully control and are fully responsible for their data/property and the actions they take.

If your product is more of a protocol, then relevant skills will also include an understanding of economics and game theory as well as an ability to think cogently about unintended consequences. Even if you’re not the one designing the mechanisms themselves, to ensure that the protocol meets its users needs and achieves its goals (which is a PMs job), you’ll need to be able to think independently about what your project is building.

There’s lots more, but I’ll leave my thoughts at that for now. What do others think?

Expand full comment