Do Protocols need Product Management?
It’s no secret many protocol teams are missing deadlines and struggling to find product-market fit. Shipping on time and pleasing users are typically the responsibility of a product manager, which begs the question, “Should protocols establish product management?”
In pursuit of this question, I had conversations with 7 protocols and the groups who work closely with them. To my interest, devs, VCs/investors, product managers, CTOs, founders, & foundations¹ working on the same protocol had differing opinions, anecdotally shown below².
Note that the roles responsible for building the technology believe problems should be solved with technology. In contrast, disciplines adjacent to the technical disciplines see a wide range of problems that need to be solved when launching protocols and advocate for product management as a way of resolving the challenges.
Three of the five years I spent at Coinbase focused on founding engineering-adjacent roles, including project management, incident response, and backend technical product management. Each time the engineers objected. They felt having non-technical team members would be more work than help. Furthermore, they feared solutions suggested by a non-technical person would be suboptimal given they didn’t come from an engineering-first mindset.
As we hired 26+ product managers (PMs) and hundreds of engineers across Coinbase, I had the unique opportunity to observe when product management was useful and when it was damaging. For my part, I decided to custom build the role with our engineers, openly evaluating what worked so we could iterate together over time.
What is Product Management?
Product management is more art than science, which is where problems with attempting to define it begin. Jeremy Henrickson, who was Chief Product Officer at Coinbase, once told me “to understand a good product manager you have to see it in action”. Yes, you can take art history and study the greats, but understanding art requires experiencing the phenomenon.
As a community, our first step should be to acknowledge the product discipline is, by its nature, nebulous. Acknowledging its nebulousness is important, as engineers are often skeptical of product management given its lack of universal definition. Proceeding with the idea that you have to see product management in action to know what it is, Mat Belaz lays out specific nuances of product management to describe the difference between a net positive and net negative PM. Yes, there are bad PMs.
Below are a few things inspired by Mat, as well as some of my own inspiration :)
1. Product management is a custom build for each product, team, and period
- Product management is intended to be multifaceted, fitting what each team needs over time. Hence, product management is specific to teams, products, and points in time.
- The openness in the role ensures the PM is responsible for seeing, raising, and following through on the fuzzy problems that arise in software development.
2. To be everything is to be nothing
- Custom building a role does not mean doing what everyone wants all the time. This is where I’ve seen many PMs (and at times, myself) go wrong.
- To be a good PM, you prioritize what matters. Like a CEO, the buck stops with you. If the product fails, no matter the reason, it is your fault.
3. PMs have no direct power; they win people over with reason and results
- PMs have no direct power meaning engineers do not report to them.
- PMs solve problems for the engineering team that are non-engineering problems. For that reason, they have to sit amongst the engineers as part of the team.
- Good PMs observe broadly and are the best listeners. They identify problems in the product and team before anyone else does and then work to co-create solutions with the engineers. PMs win engineers over with reason and results.
Common Challenges Protocols Face
From a product management perspective, there are two traits amongst protocols that are most relevant:
(1) Technical vision tends to be the first priority, and the “customer” a second priority. (2) A protocol’s customers are other developers.
(1) At Coinbase, we were passionate about Bitcoin technology. So much so that we rarely asked if the customer would be motivated to use what we built. After launching 20+ integrations, we pivoted out of merchant tools because we found customers had no reason to spend their bitcoin: if they used BTC instead of a credit card they sacrificed credit card points and no longer had that BTC available to realize gains when the market went up.
A friend, and software developer, bluntly put it “We’re idealists. We think everyone should want privacy and decentralization. But in reality, most people don’t care.” Robust core technology is critical to the success of cryptocurrency, but so are products that solve customers’ needs or are delightful to use. Products built just for our ideals can often go nowhere.
(2) Protocols primarily think of other developers as their customers, but they have other stakeholders to consider: miners/validators, employees, open-source contributors, applications, application-users, investors, traders, and more. Understanding these stakeholders, their concerns, and discovering the variety of solutions which can resolve their needs, is one of the main challenges at protocols today.
Identifying and addressing the problems facing different stakeholders is crucial. If a team dismisses the issue, or hand waves a solution when a problem is brought up, the community continues to lose faith until eventually there is no network left.
Each protocol should honestly and openly acknowledge the challenges they face in order to integrate a custom build product management department in the new world of protocols.
Integrating Product Management at Protocols
Discussing this with a good friend, and director of engineering, he summed up: “Developers are human too. There are some things we’re good at and some things we’re bad at, but I always seem to forget that. That’s where product management comes in.”
Like all complex problems, what product management looks like at each protocol will be uncovered through evaluation and experimentation. As mentioned above that’s a custom build, but below I’ve included a few things I recommend avoiding, as well as principles I employ:
To avoid:
- Engineering reporting into product management: product management should be a separate reporting line into a Chief Product Officer or similar, and engineers report to the VP of engineering or similar³.
- Creating an us-vs-them culture between product management and engineering. Product management exists to make engineers’ lives easier, not harder.
- PMs as sole decision-makers. Instead, they give context to engineers, winning them over with reason and results, but staying out of engineering specific decisions.
Key Principles of a PM:
A PM establishes trust
- Ultimately, a PM earns trust through reasoning and results. When evaluating potential PMs, it is crucial to ensure the current team and the future PM share a core set of values and have a sense of alignment so trust has the correct conditions to be developed.
- A key part of trust is transparency. PMs should lead by example and be willing to openly acknowledge reality, even when it is not a comfortable thing to say.
The best PMs will be the best listeners
- PMs need to synthesize data across all stakeholders, which can only be done through active and continuous listening.
- A PM is responsible for listening to the problem from the broadest perspective, which includes understanding what category of problem the team is facing (I recommend leveraging the Cynefin Framework for this).
PMs co-create solutions
- Co-creating starts by deeply understanding the non-engineering problems the engineers face and then finding solutions in partnership with the engineering team.
- Beyond co-creating solutions for challenges, we should remember product management is a nebulous role, which in and of itself should be co-created with the team.
Good product management is about aligning incentives, something crypto should understand well. Implementing good product departments won’t happen overnight, as it starts first from a place of observing what’s missing, and then iterates to fill those holes over time. But to even begin observing, we need to openly start the conversation.
Special thanks to those who offered me an opportunity to see this question from many angles especially Maddie Callander, Fredrik Harryson, Ali Yahya, Matthew Werner, Jim Posen, Justin O’Brien, Nathan Wilcox, Chris Burniske, Joel Monegro, Justin O’Brien, Kathleen Breitman, Raj Gokal, Layne Lafrance, Philip Martin, Rob Witoff, Jason Mintz, Diego Prats, Björn Wagner, Konstantin Richter, Steve Lee and the entire Coinbase crypto-payments team who built a team based on trust everyday. I’m looking at you Amiti Uttarwar, Jing Fan, Jake Craige, Dan Fan, Ali Fathalian, Eli Haims, Josh Ellithorpe, Mark Nesbitt, Brock Miller, and Breck Stodghill.
¹Founders & foundations input was received more often by proxy than directly.
²It should be noted this is a generalization of the common opinion by role and not meant to be a representation of every role or every opinion.
³In a small organization, PMs can also report into the VP of engineering or similar.
