8 things I learned in moving from news to product
The newsroom, by Flickr user Rick Harris
Two weeks after the 2014 Online News Association conference, I finally hit upon a topic for the session I should have pitched.
Let me back up: A little more than a year ago, I left the relatively comfortable confines of journalism — a place, squarely on one side of the church-state divide, where I’d spent nearly my entire career — for the strange new world of product management. I wanted to help my news organization make better digital products that would, I hoped, help pay for its journalism.
In the course of this transition, I absorbed a few kernels of truth I thought might be useful to those making the leap today (or those still on the news side who want to get along with their product colleagues).
Since I’m too late for the conference, I thought I’d deliver this talk — on what I learned in moving from news to product management* — in list format, taking a page from the folks at Buzzfeed.
*(Thanks to CNN’s Etan Horowitz for sparking this idea.)
1. ‘Process’ is not a dirty word.
Newsrooms are full of complex processes. They’re just so time-worn and embedded in the culture that it’s hard to identify them as processes at all. For journalists, they’re more like habits.
In product development, process is more defined, more deliberate, but not necessarily any more rigid or structured than it is in the newsroom. In fact, others have observed that agile, the widely used software development methodology, has a lot in common with the rhythms of a newsroom: Fixed deadlines, collaborative approach, emphasis on performance over planning, etc.
Why, then, are journalists so skeptical of the notion of process as it’s presented in product development terms? (I’ll admit: I was dubious myself.) My guess is it’s often the terms themselves that get in the way. Words like “scrum master” and “cadence” sound scary and foreign. (Though I guess non-journalists would feel the same about “slug” and “nut graf”.)
Not long into my product immersion, our CTO bought me this book on agile product management. (Yes, I learned agile from a book.) It’s a quick and easy read and effectively demystifies the terminology, bringing out agile’s elegant simplicity — a notion that should appeal to jaded journalists.
2. SMART goals are your friends.
It’s not enough to say, “I’m going to increase social traffic to my website.” If you don’t know how much and by when, all you have is a vague wish. You certainly don’t have any way of measuring your progress toward that goal.
Try this instead: “I will increase social traffic from 10% of article visits today to 20% within three months.” If, six weeks in, social represents 15% of your article traffic, you can say you’re halfway to your objective. Doesn’t that sound good?
So what is SMART? It’s just an acronym to help you remember to define your goals in ways that are Specific, Measurable, Achievable, Relevant and Time-bound.
3. Technology should be an enabler, not a constraint.
An unfortunate dichotomy is in evidence in the way technology is seen in different parts of the enterprise: To the product manager, technology is the lever, the means by which a problem is solved. To the content creator, technology often is the problem that needs solving, the obstacle you learn to work around.
Years of technical debt in many news organizations have perpetuated this notion, so journalists today tend to view technology through the lens of what it cannot do: “The system I compose my story on won’t let me insert hyperlinks into articles.” (Hard to fathom, I know, but still true for some.) Or, “This article template won’t let me use a vertical photo in the main art spot.”
Meanwhile, if you ask a developer whether a certain piece of functionality can be made to work, the answer is invariably, “Sure, it’s possible,” hopefully followed by an estimate of the level of effort required to implement it.
The job of the product manager, of course, is to keep track of all those things that are possible, how much effort each will take and how urgently it is needed, and continually prioritize what should be done next — so that, hopefully, fewer end users (internally and externally) complain about the limitations of the technology and begin to see the value of iterative improvement.
4. No product is ever finished.
Another place where traditional journalistic practices and product development are at odds is in the notion of “finished”. There is a certain liberation in being able to hit “publish” and head home, knowing you’ve done an honest day’s work and produced something of value to the public — and then to be able to come back the next day and work on something new. For many journalists — even in the digital world — this is the reality.
In product development, though, launch doesn’t really signify the completion of anything but rather the beginning of the next phase of a product.
Also, in journalism, we publish only when a story is perfect, or pretty close. In product development, we release things before they’re even really finished. This is the goal of the “minimum viable product”, the notion that you should launch as soon as you have something that’s useful and valuable, and adjust your future development based on feedback on the initial version. After all, why spend months building a fully-formed, feature-rich product and release it to the world, only to learn that it isn’t at all what the world was waiting for?
How long does this cycle of design-built-test repeat? As long as the product is still alive. Try telling that to a reporter: “Your job is to just keep updating the same story forever.” (Then again, isn’t that kind of the idea behind Circa, as well as Vox.com’s card stacks?)
5. Strategy by vendor is not strategy.
I’m convinced that many news organizations have abdicated control over their destiny by outsourcing too much of their product strategy to alluring third-party products purpose-built for publishers.
On one hand, vendors enable news organizations to focus on what they do uniquely well — publishing news — and to hire out the technical work that is never going to be their forte, simultaneously benefiting from the combined investment of many publishers. (After all, how many times does an analytics tool or ad delivery system need to be built?)
But some functions are too important to leave to third parties. For example, how many revenue-sharing deals do we have to sign before we’ve learned that with each one we give up a little more of our ability to monetize our own audience.
Barriers to entry keep falling. Off-the-shelf technologies, with some modification and integration work, can solve many of the complex problems publishers previously relied on expensive purpose-built tools for. (Witness Journal Register’s Ben Franklin Project, for example, which I’ve praised previously.) Many of us essentially missed out on the democratization of technical innovation brought about by the open source movement, but it’s not too late to be part of this community and benefit from its work.
Another thing to consider in deploying third-party products is user experience. If you load up your pages with widgets and doohickeys, you will end up with microhate — those little annoyances that add up for users. (Hat tip to The Atlantic’s J.J. Gould for this evocative term.)
6. A single metric rarely tells the whole story.
Everybody can see the unfortunate effects of digital publishers’ obsession with a single metric — the impression — as the primary determinant of advertising value. It has turned content sites into Christmas trees, lit up with a thousand blinking, multi-colored ornaments. It resulted in photo-gallery pageview padding, pointless article page pagination and the vast right-rail wastelands you see on so many sites. It is why most publishers still chase clicks instead of actual engagement, which in turn has led them to value catchy headlines over quality content.
And ultimately, it’s our reliance on this measurement that has caused the perverse oversupply and collapse in value of digital display ad inventory. All because we equated impressions, which are infinitely inflatable, with attention, which is finite and the thing advertisers actually want to buy. (Gradually, we see sanity prevailing, but it’s taken us two decades to get there.)
Variations on this story are repeated on a daily basis, though usually with less enduring effects, in business scenarios around the world. Focusing on one metric at the expense of others oversimplifies the problem being measured and often leads to new ones. This is why you should always be on the lookout for the potential unintended consequences of each metric you use.
7. Your perspective is valuable.
When you find yourself in a meeting about some aspect of the business — a new ad product, let’s say — and you look around the room and realize you’re the only person there who has ever worked in a newsroom, your first instinct might be to lean back and let the businesspeople do their thing. Don’t do this.
Almost as often as I’ve had to push back against business initiatives that didn’t make sense from a journalistic perspective, I’ve seen colleagues censor good ideas in order to avoid any possibility of running afoul of the high priests in the newsroom. And while you can’t necessarily represent your journalist colleagues if you work in product, you can speak with some authority about journalistic values and priorities. As a product manager in a news organization, your most valuable asset might be your understanding of the organization, its capabilities and its limitations.
8. The mission still matters.
It’s a truism among journalists that we’re not in this business for the money. Most of us are drawn in some way to the public service mission, even if what we do on a daily basis doesn’t always look like public service. Even many non-journalists working for news companies, I’ve discovered, are there in part because they like the notion of working for an organization that’s shining light in dark corners and contributing to the betterment of a community.
Especially if you work in a large organization, with disparate departments that often don’t get along, you can use this shared sense of purpose to find common ground and unite people.
And uniting different kinds of people in pursuit of a shared goal is perhaps the most important thing that product managers do.