One of the hardest parts of working in open source projects is figuring out how to incorporate product management. In my experience, product management requires opinionated direction that doesn’t always seem to fit the open source ideals of “good ideas can come from anywhere” or the egalitarian ethos of a do-ocracy. Since any contributor can submit a patch, every contributor holds the very broad mandate of building and maintaining the WordPress software and project.

But—as anyone who did a group project in school can attest—when everyone is responsible for something, no one is responsible, and “death by committee” can really sneak up on you. Which is why a lot of projects (school or otherwise) end up with a manager.

Product Managers

It seems that there are as many definitions of a product manager as there are people who manage products. For many WordPress contributor teams, there’s historically been the expectation that each developer/wrangler/designer should function as their own product manager. Since the WordPress CMS’ project vision is generally done by the project lead and shared in the State of the Word, it’s sometimes hard to know how to manage products that relate to WordPress, and what it looks like in practice.

What if the individual work of being a product manager wasn’t about making decisions about what features are where, but instead the work is checking whether our suggested solutions are keeping track of their purpose? What if the work of managing a product is checking that identified and scoped features are still on the right track to the goal?

Questions to Start With

This all seems like a really big task, especially if you’ve ever read about my theory of care and influence in the WordPress community. But if this makes sense to you, and you would like to try, I have a quick set of questions that can help you get started.

1. What is the problem we’re solving? Your event wants to try printing name tags on-demand in the registration line, as opposed to ahead of the event. The problem being solved is allowing late registering attendees (users) to still have their own official badge.
2. Who does this solution benefit the most? There are three groups that should see benefits with this solution: Attendees who get to have their own printed commemorative badge; Organizers who can leave registrations open for longer; and Volunteers by making the registration line faster since you don’t have to sort/organize/find each badge.
3. How does the user’s experience improve with this solution? This solution seemed like a net benefit for the attendee (badge, longer window to register, shorter time in line), and that’s who we want to have the most benefit! 🙂
4. Is the impact well balanced with the level of effort to accomplish this solution? In this case, the level of effort is wrapped up in training on new machines and the cost, but that seems like it can balance so many benefits for the user.

Ta da! You did it!

Like so many things I share about leadership, this is something that requires consistency over time. Sustainable changes are best made through iteration, with the understanding that mistakes are opportunities to learn.

If this doesn’t work for your teams in the long run, it can still be a great starting point as you figure out what does work for you.