Exploring the product-edit relationship
Once upon a time, there was a product manager and an editor. They had coffee, solved all the problems of digital publishing, and wandered off into the sunset at the time scheduled by the PM and without interrupting the current sprint.
Within digital media, the relationship between product and editorial is vital, but it can be a difficult one to establish, maintain and improve. (This is true of many of the key working relationships, but arguably this one is the key to really driving an editorial product forward.)
Phase one: WTF is product?
The first stage of the product-edit relations, from an editorial perspective, may start with a sense that “We create this content, are the face, voice and soul of the brand, know our users inside out and are dedicated to making this publication the best in the world. What on earth do you do?”. Anyone working in product management has probably had to Google “What is product management?” and “How do I explain to my mum what I do as a product manager?” at some point in their career, so hopefully they have an explanation of the basics close at hand. If not, I’d recommend this slide show and this article.
Product management has emerged within publishing over the decade or so as a recognised function, so the level of WTF depends partly on how quickly a media organisation embraced the need for the product layer. Even when well-established in a company, new starters within editorial (or elsewhere) may well not have a clue what the PM does. It’s worth taking the time to explain the goals and processes – an air of mystery can lead to misunderstandings and missed opportunities.
For a PM on an editorially led product, it’s crucial not to underestimate how much every single development, improvement and change matters, and how much your editorial team care about them. This could range from a user-facing update that means it’s easier for users to find more content, or an update to the CMS that saves the journalists some crucial time when they create that content. Both those sets of customers are equally important to the success of the overall product. Building an understanding of the editorial goals, workflows and frustrations can shed light on why some seemingly minor changes can have a massive impact (positive or negative).
On the flipside, it’s also important not to assume that everyone is fluent in product-speak. Agile, scrum, sprints, standups, roadmaps… the day-to-day language within a product and technology team is jargon elsewhere. Transparency around decision-making, development cycles, timelines and goals beyond those of the edit team (could be technological, such as improved page speed, or commercial, such as viewability goals) will go a long way to building an understanding of the world the PM inhabits, as well as helping foster a sense that we are all on the same team.
As you’d expect, it takes a great deal of communication to move through the WTF phase. The PM needs to actively learn about the product, the audience, the editorial processes, goals and team, and to work with their editorial stakeholders (and wherever possible the wider team) to ensure transparency around the roadmap and the process by which it is developed and delivered. The many different ways to do that are an article in themselves – suggestions welcome.
Phase two: Walkin’ on sunshine
Let’s assume we’ve made it through phase one (if you’re a fan of the Tuckman model, this means working through forming and storming) and have come out the other side with some agreed priorities and enough information to work with the scrum team to start developing and delivering. This can be a golden period, and ideally it’s where the relationship stays. The PM is delivering on a roadmap, set of themes or list on the back of a pack of organic kale chips (whatever works best for the particular organisation). The editor is seeing bug fixes done, new features being developed and feels like there is momentum in an approved direction.
This doesn’t mean the PM is just delivering an edit wishlist; hopefully they are in a position to bring data to the emotion (does this change benefit users? How is that demonstrated?) and emotion to the data (telling the story of how this UX change/analytics-driven change makes a difference to our editorial mission and benefits users). As Marty Cagan has explained at length, an effective PM is working in partnership with stakeholders to deliver the best for the users.
[Alongside this, the PM is keeping other stakeholders looped in and hitting non-editorial targets, but life in the centre of a Venn diagram is worthy of an article to itself.] At this stage, we’re all aligned. Life is good.
Phase three: What have you done for me lately?
The product-edit relationship can find itself strained on a reasonably regular basis in many organisations. Unless you’re in a business where money is no object and the KPIs are straightforward and regularly over-achieved (in which case, why on earth are you reading this), the natural tension between editorial and product can become a source of frustration on both sides.
This was neatly summarised in a recent Recode Media podcast (if you don’t already subscribe, you should) where the editorial lead on LinkedIn and host Peter Kafka discussed how they were learning to live with the importance of prioritisation of tasks that is so very necessary in digital development. It rang so very true: that issue has been at the heart of many a difficult conversation, terse email exchange or grumpy meeting.
It’s easy to see why (but often not so easy to rectify) how this tension comes about. There are almost always more bugs or potential features than a development team can address at any one time, so a ruthless approach to prioritisation comes in. Does it affect many or most users? Is it costing revenue? Is it having a quantifiable effect on the user experience? Is it adding unreasonable time/complexity to the user journey or edit workflow? The PM has to make some difficult decisions around what to focus on (within the constraints of time and resource) and if the communication slips away, so does the stakeholder buy-in. Instead, there can be a growing sense of detachment; the editorial team may feel that the development is being done to them, not in partnership with them.
Left unchecked, that gulf will continue to grow, even if there are successes along the way. Additional complexity is added if structures evolve (a shift to feature-led development, for example) or team sizes change.
There’s never a single solution to an issue that can arise in different ways depending on the particular organisation, resource constraints, personalities and external pressures. One potential route is to go back to the beginning and realign everyone across the goals (editorial, business and — most importantly — user experience), then rebuild agreement on the plan to achieve them. Reinforcing the agile process (assuming that is the development method) can help as a reminder of why injecting issues into the schedule can create inefficiencies and a disaffected development team.
It may also be that the process isn’t working — let’s not assume the issue is at the editorial end. Could a Kanban-based support service help alleviate a long backlog of bugs, for example? Should a wider view be taken of the roadmap to make sure it’s heading in the intended direction? Would some user research help establish what the most effective changes might be for the audience? Do people in the teams need to spend some time together talking about what they see as important? (It can be extremely effective to get editorial and development teams together rather than ending up with silos.)
Whatever stage the product-edit relationship is at (there are bound to be others beyond these three), it’s worth taking the time to step back, look at what is and isn’t working, and make changes as necessary. United, a product manager and editorial team can achieve amazing things. Divided, even if they do ship great stuff, it may not feel like success.
