What I Learned as an Open-Source Product Manager

Notes on building in public

From 2018-2020, I worked as a product manager on an open-source project called MetaMask.

Our team builds a browser extension that lets people use Ethereum applications. It exposes an API for websites to interact with the blockchain, and it provides a UI for people to manage funds and approve transactions.

Our core team has 20 members, but our project has nearly 200 contributors from around the world. In past product roles, I’d been energized by collaborating with dozens of teammates in different functions and departments. But how could we collaborate with 10 times as many people, many of whom weren’t even part of our official team?

In my time at MetaMask, I’ve learned that PMing with a hands-on OS community can be vastly more complex and exciting. Here are a couple takeaways that will stick with me:

Community is a growth strategy

Community is powerful. I remember having my first “wow” moment when I realized how many people were answering questions on StackExchange and Reddit, responding to technical questions in our Github, and generally evangelizing MetaMask across the web. It was all work our team would have stretched to do ourselves, but there were people around the world helping us succeed. Why?

As I spoke with more contributors, I heard some similar things:

“MetaMask is useful for me, so I want it to be useful for others.”

“It feels like it’s my product and my team.”

“I want to help where I can, so you can keep building the product I love.”

When we quickly fix a problematic bug, or accept PRs from folks who need a certain feature, or even when we share the minutiae of our decision-making process, we’re giving community members a sense of trust and ownership. They trust we care about their needs, and they realize their contributions actually matter to the product (both true!).

This positive sentiment pays back a hundredfold. When developers used MetaMask to build their application, they’d recommend it to their users. As users had positive experiences with the product, they began helping others with how-to content and tutorials.

Community members were our best marketers, our brand ambassadors and a source of substantial product growth.

Feedback loops are good, but it’s important to avoid information overload

All our work at MetaMask takes place in the open. Anyone with an internet connection can see our backlog of issues, our current sprint, our design process and our work-in-progress prototypes.

This openness shapes our product process. There is no “feedback stage,” because we hear from users at every step. People open issues on Github, where we maintain our backlog. They advocate for certain bug fixes or feature requests to be included in the next sprint. They weigh in on our requirements docs and give feedback on in-progress designs, often sharing use cases we hadn’t considered. They QA, help us diagnose bugs, demand progress — it’s simultaneously overwhelming and helpful.

On the plus side, we’re able to source dramatically more feedback on our feature proposals, designs and test builds than we otherwise would. Good product management always includes this kind of feedback, but by conducting the process in public, it’s higher in volume and frequency than anything I’ve experienced.

On the other hand, this amount of feedback has a cost. It’s akin to inviting a small crowd to every meeting. Every team member must learn to balance the value of community input with the focus necessary to achieve their core goals.

I spend a substantial amount of time acting as an editor — distilling the noise to salient feedback that helps our developers and designers succeed without being overwhelmed.

Transparent decision-making keeps collaborators engaged

Product management is often about keeping focus. Keeping focus sometimes requires saying, “No.”

Inside my team, I always explain the reasoning behind a “no.” Perhaps another project is more likely to help us reach our company’s goals, or maybe we don’t have the resources to execute a project appropriately. That context can make it clear that prioritization decisions are made to maximize outcomes, not to play favorites.

With external contributors, those justifications can be harder to communicate. An outsider doesn’t have the same familiarity with our company’s business goals, strategic direction or resource constraints — which makes saying “no” harder to explain.

This has reinforced my need to have specific, evidence-driven reasons for making product decisions. If I say “no” to a community member’s feature request, the “why?” is quick to follow. To continue building an engaged community that trusts us, explaining rationale is crucial.

That sounds something like this: “No, we won’t remove that screen from onboarding. I know it’s redundant, but we saw a 25% reduction in password-related support requests after we added it.”

Or this: “No, we won’t add more network data to the home screen. Only 10% of users actually switch to test networks, so we don’t think that information is important enough to include by default.”

Plan for the unpredictable

Community members don’t follow the sprint plan. A rule follower might pluck an issue from the backlog we’ve declared needs help. A frustrated developer might fix a bug that’s been affecting her application. But it’s usually a chaotic do-gooder who drives by to introduce a new UI to our home screen or build out a feature we hadn’t yet had time to design properly.

As discussed, sometimes a “no, because …” is necessary. In all cases, we encourage contributors to pre-flight their new idea by opening an issue before they invest time in the code. But in the cases where a community member builds or fixes something with substantial value and little warning, our team must be flexible enough to accept a contribution while still making progress on our own priorities.

We’ve learned to budget this effort into our planning. If our development team has 100 fictional “points” of effort, anywhere between 10 and 40 of those points might be spent on community management each sprint (which includes code review, feedback on implementation, debugging, helping with build issues, etc). Each cycle, we review the in-progress community PRs and point the community management work accordingly, which lets me understand how much bandwidth we have left for other priorities.

On the design side, this planning is a bit harder. It’s very tough to “sprinkle some UI” on an issue that hasn’t had enough design thinking applied from the start. In some cases, we’ll add a community feature to our design backlog and implement the designs ourselves to complement the under-the-hood work done by an external contributor — a nice collaboration that respects their work without demanding more.

More than once, our team has let community PRs linger without code review or blocked new features on our design process. Contributors lose interest quickly when their work is ignored. Over time, I’ve learned to maximize outcomes by budgeting for the unpredictable contributions of our community.

Invest in productivity multipliers

How many people can you fit in one codebase? How quickly can you get a new contributor up to speed? The answer depends on how the team builds, documents, tests, and collaborates.

The good news is these are all variables the team can influence. Investing in infrastructure that can help a new contributor go from 0 to 1 will pay compounding returns over time.

If I have to answer a development question twice, it should be written down in our documentation. If contributors repeatedly have trouble with the test suite, we consider prioritizing a fix. Our design system lets folks build out suitable UI features without requiring design resources. By doubling down on these productivity multipliers, we’ve reduced the number of issues categorized as dev help by ~50% and freed up more of our core team’s time.

Inclusion requires intention

Inbound feedback is a gift, but it doesn’t reflect all users’ needs. It usually comes from the technical part of our user base — folks who are comfortable using Github and can express their needs in the specific language of a bug report or feature request.

This asymmetry might be OK for a proposed change to an API method. But for an update to our onboarding flow, or when considering broader product strategy and prioritization, it’s crucial to gather feedback from other user personas.

In conversations with community members, I’ve learned that online forums or Github issues are not welcoming to all individuals. Women and people of color in these spaces are disproportionately subject to harassment. We also have a large international user base, but most of our documentation and support is still only in English.

I’ve learned a lot from folks such as Coraline Ada Ehmke, an open-source developer and advocate who authored the Contributor Covenant, which sets guidelines for good community conduct.

Whether that means course-correcting a conversation that’s heating up or removing a repeat offender from our community, proactively building an inclusive space is both moral and productive.

Tongue-in-cheek, but still important!

That’s all folks! Thanks for reading. Get in touch: bobby.dresser@gmail.com.

Also, this post notably excludes discussion of business models and a product manager’s responsibility to build (and license) software that helps meet business goals. That is another article for another time!

Note*: The internet was built on open-source software and runs on it still today. Many of the most crucial projects are woefully underfunded. Consider supporting an OS team via Github Sponsors* or Open Collective!

Note2*: This article was originally published on Medium in 2020*

Subscribe to bobby
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.