6 things I’ve learnt as a product manager in digital publishing

Reflections on my last few years at the coalface

This week, I leave Immediate Media after two and a half years working on content sites and the mammoth project of delivering a new platform. In between farewell trips to the pub and deleting emails, I’ve found myself reflecting on the lessons I’ve learnt along the way. There’s a lot of stuff out there about how to be a good product manager, but not nearly enough about what it’s like to be a product manger in digital publishing. Here’s six things I’ve learnt from my hundreds of mistakes.

It never takes ‘10 minutes’

Beware of a stakeholder feature request that comes with the justification that it would take someone who knew what they were doing ‘10 minutes’.

Beware of a developer who, without much consideration of a problem, immediately agrees to a new feature or change because ‘it will only take 10 minutes’.

It never takes 10 minutes.

Large, content-rich sites are much more complex than they seem, and the older the site, the worse it gets. I’ve seen 15 different templates for what is almost exactly the same article type. Then you have clashing ad code, navigation on mobile, the endless but always futile obsession with landing pages ranking in search, site search, image handling, user accounts, and email newsletters. And that’s before you even spend much time thinking about the infrastructure and all the things that can go wrong there. Plus the QA, release process, comms and other easy-to-forget-but-important side work that comes with any ‘small change’. If you’re a PM of an entire site or sites, it can take a long time to understand how everything fits together and why any new work is complex and deserves a bit more thought before it gets a yes.

The ‘10 minute’ perception is a big problem in publishing businesses that do print and digital. Colleagues with a lot of print experience often think digital is easier, and that the lack of a physical product means that things can move faster. It almost never works this way. Print publishing, with over a century of established production processes, can be very efficient because everyone knows exactly what they’re doing. It’s possible to launch a new publication and have it on the newsstand in a couple of months, sometimes even a few days. As a PM of a digital publication, it’s your job to explain to colleagues and partners why you can’t always move as quickly as they’d like.

Having bad tech and systems ≠ working in publishing

It is a truth universally acknowledged that editorial teams — who in the digital publishing model produce a large part of the product but often have the smallest voice — will have the worst tools to do their work. Product teams are often not far behind. Try to avoid believing that this is all because you work in publishing. Sure, there’s not quite the kind of money flowing around that there might be in other industries. But as a PM in a publishing company, sitting between content creators and those giving them a platform, you are in a position where you can make a difference, whether that’s helping them install a useful Chrome extension or the somewhat more laborious task of delivering a new CMS.

Centralising feature development is a winning plan, but beware of feature factories

It’s encouraging that most multi-brand publishing companies are moving towards centralising product development, away from the bad old days when this was dispersed across different brand and geographical silos. At Immediate, our worst example of this was when we had four separate product teams building a gallery template at the same time.

For past 12 months, I’ve been fortunate to be part of the Fabric team (yes, it was named after the nightclub, enough said), which is undertaking a big, transformative project that will bring Immediate’s 50-odd sites and other systems onto the same unified platform. My colleague Laura Jenner has written of the specific challenges facing product managers in such a transformation, particularly the way that it can affect a PM’s relationship with editorial teams.

However, when undertaking such a huge, company-wide tech project, it can be easy to slip into a mode where you think your job as PM is just to get the team to churn out features – something for every stakeholder – to show progress and forward motion. Elsewhere on Medium, John Cutler has used the term ‘feature factory’ to describe this, and I’ve found it a useful phrase to remember and try not to get sucked into. Working in a feature factory is not good for your team, not a very honest way to work with stakeholders and ultimately means you never have time to reflect and measure what you’ve put out there (if you’ve actually managed to ship anything).

Communicate early and often

Don’t assume anyone knows what the hell you’re talking about. On a big project, aim to communicate the same plan at least 17 times. Clearly I have made this number up, but if you remember that communicating the vision of what your team is trying to do is your job on a daily basis, then you’ll be some way towards reaching this goal.

Don’t assume that everyone across the company will understand the thinking or work that has gone into your shiny roadmap, or what a roadmap even is. This is obviously a point relevant to all product managers, in all industries. Doing a slide deck once doesn’t mean you’re done on the talky front. Give people time — weeks, months — to understand, to ask questions, to get upset, to reflect, to believe and trust you. You will never get honest feedback on a project in a group presentation — seek this out on a one-on-one basis.

Don’t assume that just because you’ve been hired as a product manager, that anyone at the company knows what the hell that means. This is a particularly acute problem in digital publishing, where there is often a split between the people who believe they’re working in a technology company, and people who don’t. It’s your job to educate them on your job, your work, your strategy and your sprints. No one else will do it. This may take months or years and lots of lots of diagrams. I’m quite bad at drawing, so take it from me.

It’s all too easy to get distracted by emotion and forget the users

In digital publishing the makeup of editorial and commercial teams often reflects the publication they work on. Of course it is absolutely the right thing that these passionate content creators and salespeople have similar interests to and intrinsically understand their audiences, but it can sometimes make for difficult conversations when discussing new features or changes to the product.

These stakeholders can often be so empathetic towards their users that they believe they are them. Why should they believe your UX researcher’s painstakingly detailed report that users don’t understand or need that new feature WHEN IT IS CLEAR THAT THEY DO?! That survey that says the site’s users aren’t particularly fussed about the newsletter design when an editor wants a new one — well, the survey must have been poorly written.

Take a deep breath, remember that it’s actually your job to be in the middle of these conflicts, and make sure that you include all stakeholders in the process of gathering and interpreting data about your users.

Ad Ops are your friends

When I joined Immediate, one of my first meetings was with a harried-looking colleague from the Ad Operations team, where I was presented with a 100-line spreadsheet detailing all the problems with the ad code on the newly launched site I was taking over. I had come from a place where the company culture, mystifyingly, was that we didn’t pay much attention to the few ads we had on the site. I understood that things here were different and that at that time the business absolutely depended on the ads being reliable, but I didn’t know why there were so many problems, or why the team appeared to spend a lot of time comfort-drinking at the pub across the road.

In the intervening few years, I’ve learnt a lot about how important it is to understand what Ad Ops do, how they work, why they’re frustrated a lot of the time and generally how broken the advertising model is in publishing. If you think the technology the product and editorial teams are working with sucks, then go and spend some time with Ad Ops, and make sure you have a user account for tools such as DFP (shudder) and Moat (double shudder). Know that the reporting you’re seeing in these tools means absolutely nothing if you haven’t got the ad behaviour on the site correct. Make sure your development and design team spend a lot of time with Ad Ops too. And for god’s sake, buy them a drink.