Coinbase five-year veteran: how the excellent blockchain product "Koi" was made

Note: The original author, Kristen Stone, is a 5-year veteran of cryptocurrency at Coinbase. She is currently the product manager of the company.

(Photo: Kristen Stone, Coinbase Product Manager)

The following is a translation:

• In-depth analysis: about the new Filecoin mining solution, you need to know these
• Ant S9 reached shutdown price. Earned 90 yuan a day, now it is 6 yuan.
• Despite the plummeting price, most Bitcoin investors lost less than $ 200

It's no secret that many protocol teams are missing deadlines and struggling to find products that match the market. Delivery on time and pleasing users are usually the responsibility of the product "Koi" (PM), which raises a question:

"Should the agreement establish a product management team?"

In order to solve this problem, I talked with the developers of the 7 agreements and related personnel. It is interesting that developers, VC / investors, PMs, CTOs, founders and foundations ^[1] will have different opinions on the same agreement.

Please note that the role (developers) responsible for building technology believes that technology should be used to solve problems. In contrast, those who are adjacent to the technical staff (PM, etc.) saw a series of problems that needed to be resolved when the agreement was launched, and advocated product management as a way to solve the challenge.

During the five years I spent at Coinbase, three years have focused on roles adjacent to engineering, including project management, incident response, and back-end technology product management, but every time engineers will object, they feel that the team has non-tech Members, this is more trouble than help. In addition, they are concerned that solutions proposed by non-technical personnel may not be ideal because they do not come from an engineering-first mindset.

When Coinbase was hiring more than 26 products "Koi" (PM) and hundreds of engineering "Lions", I had a unique opportunity to observe when product management was useful and when it was harmful. In my case, I decided to customize this character with our engineering "Lion" and publicly evaluate what works so we can iterate together over time.

What is product management?

Product management is more about art than science. Former Coinbase chief product officer Jeremy Henrickson told me:

"To understand a good product manager, you have to see him in action."

Yes, you can learn art history and gain good knowledge, but to truly understand art needs to experience this phenomenon.

As a community, our first step should be to acknowledge that the nature of product specialty is vague. It is important to acknowledge its ambiguity, because engineering "lions" are often skeptical of product management because it lacks a common definition. Mat Belaz put forward the idea that you must see the actual situation of product management to know what it is. He listed the specific details of product management to describe the difference between good PM and poor PM, yes, There is bad PM.

Here are some things inspired by Mat, and some of my own inspiration 🙂

1.Product management is the custom creation of each product, team and period

1. The purpose of product management is multifaceted. It is designed to meet the needs of each team. Therefore, product management is specific to teams, products, and time points.
2. The openness of the role ensures that the project manager has the responsibility to see, ask, and implement ambiguous issues in software development.

2. Doing everything will result in doing nothing well

1. Customizing a role doesn't mean always doing what everyone wants to do. This is a problem that many PMs (and sometimes myself) I have seen have problems with.
2. To be a good PM, you must prioritize important things. It's like a CEO, the responsibility ends with you. If the product fails, for whatever reason, it's your fault.

3. PM has no direct power. They use rationality and results to win people's support.

1. PM has no direct authority, which means that the engineering "lions" are not reporting to PM.
2. PM solves non-engineering problems for the engineering team, so they must sit in the middle of the engineering "lion" as part of the team.
3. Good PMs will be widely observed. They are the best listeners. They discover problems in the product and team first, and then work with the engineering "lion" to create solutions. PM won the support of the engineering "Lion" with reason and results.

Common challenges facing blockchain protocols

From a product management perspective, there are two of the most relevant features in a protocol:

(1) Technical vision is always the first priority, and "customer" is often the second priority;

(2) The client of the agreement is another developer;

Regarding the first point, at Coinbase, we are so passionate about Bitcoin technology that we rarely ask customers if they have an incentive to use our products. After launching more than 20 integrated applications, we no longer focus on merchant tools because we found that customers have no reason to spend their Bitcoin.

A friend (software developer) told me straightforwardly:

"We are idealists. We think that everyone wants privacy and decentralization. But in fact, most people don't care."

Strong core technology is critical to the success of cryptocurrencies, but it is equally important to address customer needs or enjoy the product. And products made solely for our ideals often don't work.

Regarding point 2, we actually need to consider other stakeholders, such as: miners / validators, employees, open source contributors, applications, application users, investors, traders, and so on. Understanding these stakeholders and their concerns, and discovering solutions that address their needs, is one of the major challenges facing today's protocols.

Identifying and addressing the issues facing different stakeholders is critical . If a team dismisses the problem, or rushes to come up with a solution when asking a question, the community will gradually lose confidence until the network finally dissipates.

Each party should honestly and publicly acknowledge the challenges they face in order to integrate custom product management in the new world of agreements.

Integrate product management in protocols

While discussing this issue with a good friend (an engineering director), he concluded:

"Developers are people. Some things we are good at and some things we are not good at, but I always seem to forget this, and this is where product management comes in."

As with all complex issues, what product management looks like in each protocol will be revealed through evaluations and experiments. As mentioned above, this is custom built, but below, I personally suggest some things to avoid, and the principles I use:

To avoid:

1. Submit engineering report to product management department. The product management department should report to the chief product officer (CPO) or similar person separately, and the engineer should report to the vice president of engineering or similar person ^[3] .
2. Create a "we vs them" culture between product management and engineering. Product management is designed to make life easier for engineers, not harder.
3. PM is the only decision maker. Instead, they provide an environment for engineers, winning their support with reason and results, but not participating in specific engineering decisions.

The main principles of being a PM:

1.PM needs to build trust

In the end, PM gains trust through rational perspectives and results. When assessing potential PMs, it is important to ensure that the current team and future PMs share a core set of values ​​and are consistent, so that trust has the right development conditions.

A key part of trust is transparency, and PMs should lead by example and be willing to openly acknowledge reality, even if this is uncomfortable to say.

2.The best PM is the best listener

PM needs to synthesize data from all stakeholders, which can only be done through active and continuous listening.

The PM is responsible for listening to issues from the broadest perspective, including understanding the types of issues the team faces (I recommend using the Cynefin framework ).

3.PM co-create solutions

Co-creation starts with an in-depth understanding of the non-engineering issues facing the engineering "lion" and then working with the engineering team to find solutions.

In addition to creating solutions, we should also keep in mind that PM is a vague role and should itself be co-created with the team.

Good product management is the coordination of incentives, which should be well understood by those in the cryptocurrency industry. A well-implemented product department won't happen overnight because it starts with a place to look for missing content, and then iterates over time to fill these holes. To begin observation, we need to start the conversation openly.

Special thanks to those who gave me the opportunity to look at this issue from multiple perspectives, especially Maddie Callander, Fredrik Harryson, Ali Yahya, Matthew Werner, Jim Posen, Justin O'Brien, Nathan Wilcox, Chris Burniske, Joel Monegro, Kathleen Breitman , Raj Gokal, Layne Lafrance, Philip Martin, Rob Witoff, Jason Mintz, Diego Prats, Konstantin Richter, Steve Lee, and the entire Coinbase cryptocurrency payment team.

1. The input of founders and foundations is often more direct and easier to accept than agents; ↵

2. It should be noted that these opinions are general and not representative of every opinion of each role; ↵

3. In small organizations, PMs can also report to the Vice President of Engineering or similar personnel;

We will continue to update Blocking; if you have any questions or suggestions, please contact us!