This year at GUADEC in Almería I was lucky enough to give a talk entitled “Product Management in Open Source”. I’ll give a text synopsis of the talk below but if you prefer you can watch the whole thing as delivered at the Internet Archive or have a look at the slides, which are entirely mysterious when viewed alone:

The talk begins like so: I’m Nick Richards. I’ve been a GNOME User for 20 years and a contributor and Foundation Member - 10 years (off and on). These days, the Free Software project I’m most passionate about is Flathub.

These days I’m a Product Manager at Endless. Endless OS ships a customised, forked version of GNOME shell and a plain version of the rest of the GNOME platform. It’s currently based on 3.26 but with plenty of activity going on upstream.

What is a Product Manager? Christian Knows!

“Product managers are responsible for taking information and feedback from everywhere and converting that into a coherent project direction and forward looking vision. They analyze common issues, bug velocity, and features to ensure reasonable milestones that keeps the product functional as it transforms into it’s more ideal state. Most importantly, this role is leadership.”

It’s often a role you grow into; Product Managers rarely start there. In the past I’ve been a User Advocate, Interaction Designer, User Tester, Localiser and messed about with Development and Operations. Having a diverse background helps you empathise with all the people you have to interact with although most Product Managers are deep experts in one area.

What does a product manager actually do?

• Integrate all the things. You should know everything about your project, know a bit about everyone’s job and be able to help wherever there’s stress.
• Maintain Standards everywhere. You don’t have to approve everything and become a bottleneck, but you should be able to keep on top of things and be aware if dubious code is about to be released.

A lot of this often boils down to saying no in an encouraging way. Doesn’t this sound like a free software maintainer? So why should you care? You do this already. Christian, again:

“For the past 3 years I’ve been working very hard because I fulfill a number of these roles for Builder. It’s exhausting and unsustainable. It contributes to burnout and hostile communication by putting too much responsibility on too few people’s shoulders.”

You might want to get Product Management involved so you can spend more time doing the things you joined the project to work on.

Which projects need Product Management? Not everything does, but if you’re working on these kinds of things it can help:

• Cross cutting initatives (GNOME Goals) like the App Developer Experience or Privacy. The kind of areas where you need a strategic vision and co-ordination
• “Big” projects likw the shell, builder, anywhere where really getting close to the details makes a difference or where a large team of regular contributors help out.

Your project may not yet have the ambition to be “Big”, which is OK. I love constrained scope too and the growth of small ‘single serving’ apps is one of the most interesting recent developments on the Free Desktop.

Product doesn’t work alone, Product is part of a software team. Here’s a quick rundown of some of the roles that you might find on a software team: Developers, Interaction Designers, Quality Assurance, User Support, Graphic Designers, Security Engineers, User and Developer Advocates, User Researchers, Tech writers, Build engineers, Operations people, Release managers, Standards Committee Members, Public Relations, Hackfest Organisers, Localisers, Internationalisers, and more… Very few projects will have all of these but expand your mind, what could your project do if it had some people working on one of these roles?

Product without other people is lonely and pointless. Solving complex problems requires a diverse team and often doesn’t admit simple solutions. A perennial problem for open source is attracting people with skillsets you don’t know about. You can’t just sit around and wait for them to turn up and start working, you need to invite them in by name. Maybe also start by taking their tools seriously. Yes, that probably means GNOME should have a Discourse forum. There’s been some really encouraging recent progress on modernising our infrastructure but GitLab is a great first step, not the end. The tricky, tricky bit once you’ve got these people involed is making sure they don’t go away. This doesn’t mean ‘do everything they say’ but it does need some open mindedness. The promise of Free Software is thatby having control over the software they run it will better fit peoples needs. Reducing the barrier between producers and consumers has always been a critical part of this and lowering it further by welcoming the skills of those who can help can only make our software stronger.

How do you decide what to do? The best way to decide is by focusing on a mix of internal drive and user satisfaction. I never want to underestimate internal drive and product feel, it’s what gives your software its unique flavour and can help create fanatically devoted and delighted users and contributors but if you want a large number of users then listening to feedback can be helpful.

Some good sources of feedback are: In person, GitLab (or bugzilla), IRC, Telegram, press reviews, blogs, forums, user testing. Just plain listening on bugzilla is kind of unhelpful, you need to look at your user support channels to feel the pain, and then translate that into a good engineering journal solution.

Endless has metrics which tell us some anonymised things about how people use our software (this is controversial). But they are very useful when used responsibly, for example they can tell me that Nautilus was GNOME app that Endless users opened most in the last month. But it’s not clear we can just roll this out. GNOME has strong privacy guarantees and intermediating forces (like Endless!). It’s not normally helpful to have people between yourself and the user if you want to react to their problems and provide solutions. Where possible, disintermediate (this means you should be using Flatpak for your apps).

User research and going onto the ground to talk to users and stakeholders is also really important. It’s great to talk to people who were motivated enough to come to GUADEC but you get a whole different view by meeting people in their own context. This is something that Endless has been fanatical about, and has really influenced our product developement process and is an area GNOME can also do well in with its distributed community.

At the end of the day, great products never listen in just one way and a key role for Product Management is to weigh the feedback from each channel and merge it together into a coherant product direction. That’s the real trick, good luck!

Summing up:

• Everyone is making a product - you may not need dedicated management right now but using the techniques can help.

• If you want new people you have to do something to make it happen.

• Get a diversity of feedback - but be discerning with how you listen to it.