Being a Product Manager at the Natural History Museum
There are more fantastic articles out there about being a Product Manager than I could ever reasonably read. A lot of them talk about being a Product Manager in a technology or software company — from huge companies like Facebook to plucky startups trying to achieve their first product-market fit.
I’ve only ever worked in digital product management in the non-profit/charity sector. And I can confirm that what happens in my current role has some key differences from the startup and tech company product manager roles that are so often talked about. (I like that!)
Here are two things that I think are different in my role from the PM roles often talked about, and two things I think are the same.
Two things that are different
1. The product is not the business
There’s a ton going on here at the Museum. We’re a visitor attraction, a commercial enterprise, a scientific institution, a centre of expertise, a conservation and preservation lab, a school trip destination, a place for volunteering and learning, an events and venue hire company, a partner in national programmes, an advocate for nature and the planet, a non-governmental body — the list goes on.
My team’s objective is to inspire and enable investigation into the natural world through digital products.
Can we help the Museum achieve its vision of a future where people and planet thrive, and its mission to create advocates for the planet? Absolutely.
Does the Museum close down if my digital products stop working? Not in the slightest.
Would Uber close down if its app stopped working? You bet.
The lack of organisational dependency on my products is empowering, enabling me and my team to forge our own path, set our own distinct strategy, and solve problems for users, not for the business.
But it also means we can end up fighting our very small corner against a lot of other priorities in the Museum. Because we’re not business-critical, our arguments can have less weight behind them than something that’s losing us visitors, money, or both.
2. The product isn’t a product at all
The four Product teams here at the Museum aren’t structured around a specific product, or specific features in that product.
Instead each team focuses on different objectives that can be achieved through either (or both) improving our existing digital products, like the main website, or creating brand-new digital products, like an app to help people identify UK nature.
Instead of a traditional ‘product’, ‘feature’, or ‘journey within a product’, we are instead structured around different:
- audiences
- tasks
- and/or purposes
that can be empowered/completed/fulfilled with digital products. (I’ve yet to land on one that I think describes it best.)
This makes the opportunities endless and the scope broad. But it means I’ve often struggled with figuring out where to focus.
In Rosemary King’s recent article on Mind the Product she says that there are two types of PM: ‘builders’ and ‘optimisers’. Well, in my current role, I’m both.
In one hour of my work day I might spend time thinking about and running discovery on a brand-new standalone digital product to help people explore nature. In the next, I might spend time planning an A/B test on our existing nature identification pages to optimise our key results.
It’s exhausting, it’s challenging, and I love it.
Two things that are the same
1. The PM role is about bringing the team, the ideas, the strategy and the stakeholders together
The way this happens day-to-day might be different (see: fighting a very small corner) but essentially I view my role as trying to keep hold of all the information me and my team need at once.
I bring user knowledge to our team meetings, I do stakeholder comms to ensure other teams understand what we’re doing and why, I build strategies and slide decks. And, I try as much as possible to shield my team from the ‘digital service delivery’ requests that still come in. (“Oh by the way, we’ve got funding for this project and need you to build us a microsite.” Right.)
I love the way Clement Kao describes the PM role in his PMHQ article on Stakeholder Empathy:
Product managers are not value generators — they are value multipliers.
My team are the ones who do incredible work, with code, content, design, testing and more. What I can do is help them be incredible by giving them focus time, a goal and direction, and the right information at the right time.
2. The team can work to agile principles (but not necessarily methodologies)
As a quick reminder the four principles of agile (from agilemanifesto.org) are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
We do our absolute best to work to these principles, releasing and testing as often as we can, letting our work be the documentation, learning as we go, and working in the way that works best for us rather than insisting on following a certain process.
But this sometimes means we work in ways that a lot of product management and agile articles tell us not to. We don’t have daily stand-ups, instead we meet weekly. We sometimes work in waterfall, because there’s so many things going on we can’t all focus on one thing at the same time. We don’t have a product owner, scrum master, backlog groomer or delivery manager. We have one developer, not 8–10. We have content producers in the team.
We don’t work together on everything, we work together when it makes sense.
The Agile Manifesto says individuals and interactions over processes and tools. Somewhere along the way, it’s been forgotten that agile methodologies are processes and tools — and it’s okay not to use them if they don’t work for you.
As John Cutler says, great teams break the “rules” all the time.
I’m still learning in my product career, so any feedback and comments are very welcome!
