This is a lot late, but since I went to the Online News Association conference in Denver last month, one of the presentations has been on my mind.
Katharine Bailey, Greg Emerson, and Hailey Persinger, from the NYT and WSJ, ran a session on building products in the newsroom (the full presentation is at that link). The perspective that they brought, and their general approach, is close to how we think about products internally now, though it took us a long time to get to this point.
To be clear, the relationship between product and tech at the Journal and the Times is very different than here at Gizmodo. We don’t run a classical sprint process on a weekly or bi-weekly time frame. We don’t use points to scope out developer work. Instead, we have longer product time-scales, where teams either build a new feature, (for example, our newsletters) or work on a number of small improvements/bug-fixes around a single theme (like our off-platform team implementing AMP).
What we do have in common with the ‘papers of record’ is the focus on our editors and writers: ensuring that we’re building tools that they know how to use and are comfortable with. To quote Katharine (emphasis added):
Happy editors definitely mean happy readers: that’s been a big learning for me. I think the ‘live event coverage’ project that I talked about earlier is a great example. We spent just as much, if not more time on the tool that powered that feature as the user-facing experience. [...]
What that resulted in was a tool that the editors really loved using [...]. If they want to use it, they will keep using it, and they will keep making it better because they will keep asking for more features [...]. When it becomes part of their day, part of their habit, then the user experience ends up being a lot better, and the content a lot richer.
The value of process-orientation, or writer-orientation, is something that we’ve discovered as well. While we (the product and tech teams, who I’m referring to as one entity for this post) are avid users of our sites and our platform, we can’t anticipate all the use cases the editorial team will find for our tools and the extensions of the product they will need.
The give-and-take between the editorial team and tech/product is the sign of a healthy relationship, and leads to strong products that evolve over time.
It is really difficult to maintain this even-handed dialogue, with edit (or any operational team, really) using & extending the products we build, and tech/product listening to their feedback and using it to drive the experience. I’ve seen this virtuous cycle stop working, with either edit or tech/product as the culprit.
Occasionally, tech/product doesn’t respect the very real needs of internal customers for usability or minor features. Building software is harder than having an editor complete a few extra actions (at least for us it is!) and, hell, it’s their job, right? Who cares if they don’t like it?
Unfortunately, products that are hard to use and are avoidable don’t get used. Without internal use, there’s no innovation or improvement. Products get abandoned after a few uses, leaving cruft and future decisions about deprecating features that can be divisive and slow down development time. We recently went through a major project to remove old features that are rarely or never used. The research and re-factoring that went into that project were substantial, since we can’t be sure that nothing depends on the old feature until we review all the rotting code.
On the other hand, operational teams like edit sometimes don’t have the patience for building new products, instead pushing for faster solutions to minor annoyances and chasing what competitors are doing. “Publication ‘X’ has feature ‘Y’, we need it ASAP” is a formulation that I have heard, which to me indicates a lack of confidence in the team building products internally.
Sometimes these externally generated requests are unavoidable, and even useful, but following them can lead to software that is built from the outside-in: the view from the reader’s perspective is great, but the editorial workflow often makes little or no sense, as does the API structure. And since editors struggle to use the software, it doesn’t get used, and doesn’t evolve, so it usually ends up inferior to the competition in my experience.
Ultimately each company needs to find their own balance between these groups. And achieving this balance is dependent on the alignment of incentives: if our editorial team has wildly different goals than we do (say, one team wants to try out new software or new article formats for their own sake, rather than solving a business need) we’re going to have more friction than function. But I’ve found that orienting product design towards the creators of content results in better products than skipping right to the consumers, since it allows product/tech teams to learn from their creators.
Iteration and the patience to let products evolve drives some of the best publications in the world, and if we hope to include ourselves among them we are wise to do the same.