← SRCCON 2019 Session Transcripts

How to re-org your newsroom around product without breaking it

Session facilitator(s): Jessica Morrison, Amanda Yarnell

Day & Time: Thursday, 3-4:15pm

Room: Ski-U-Mah

JESSICA: Hello. Can everybody hear me? We’re gonna go ahead and get started, and we’ll let everybody trickle in, because we have lots to cover in a small amount of time. I’m gonna try to keep people on schedule here. This is how to reorg your newsroom around product without breaking it. I’m Jessica Morrison at Chemical and Engineering News.

AMANDA: And I’m Amanda.

JESSICA: Thank you for joining us. I know everybody is interested in product and team building right now.

AMANDA: Our session is being transcribed this afternoon. So everyone should say their name and their affiliation the very first time they speak up. And if you want to go off the record, please do so very clearly. Say “this comment is off the record”, and please don’t forget to say so, when you want to go back on the record as well.

JESSICA: So thank you for transcription. So who are we? You may be wondering what is Chemical And Engineering News? We have been published by the American Chemical Society, which has been the premiere society for chemist for almost 100 years. We publish daily news online, we have a weekly print magazine, we have podcasts, a video series, an Alexa skill, a daily news briefing. So we have lots of different products. And we have about 100,000 print and digital subscribers. Also, fun fact, we’ve been called by our chemist audience “The Economist for Chemists”. So that’s our reputation with chemists.

AMANDA: Why are we here today? You might remember, some of you, that Jessica gave a really memorable talk in at SRCCON:WORK, in which she said that our org charts in newsroom and others are bloated and that we need to untangle them to do the work we have to do in 2019. So we took that really seriously. In our newsroom. And we’re here to show the work we’ve done in the last 18 months. Here’s what you’re in for. First we’re gonna share what product means in our newsroom and how we reorganized ourselves to promote a product mindset. Then we’re gonna do a little exercise to work through a product request prioritization activity, and it will include groupwork and discussion. We promise it’s gonna be fun. And finally we’re gonna come back and share what we’ve learned about building and nurturing a newsroom product team at the very end.

JESSICA: So I’m gonna start by talking about how we changed our approach to product development. A year ago, our approach was: We didn’t really have one. We did not have a product team. We had a lot of really smart people working in silos. So this is just a sample of what those silos looked like. These are… So they’re business units here. Engineering, creative, revenue, operations, product with a dotted line around it, kind of a shadow thing. We had teams that worked in silos. They got requests from all sorts of different places. So our engineers might get an email that something is broken. They might get an email that the entire site is down. They might have someone pass them in the hallway and say… I don’t like this thing. Can you fix it? They might get a request from a writer to add a status bar across the top of a story, to let people know where they are in the story, to let readers know how far in the story they are. So they’re getting these requests from everywhere. And there wasn’t really a system to prioritize them. There was no way to judge urgency. Everything was coming in at the same time. Everything was on fire all the time. There was a lot of dropping this thing to do that thing and that thing to do this thing. So this is what the product team looks like now. It’s not a shadow team anymore. It’s an actual cross functional team. With 13 people. And we have the leaders of each of the business units participating in team meetings, acting as stakeholders. So that means creative, revenue, operations, we work in sprints. That’s another thing. We started working in two-week sprints in October of last year, so this team comes together every Monday to do sprint planning or sprint review, and the stakeholder team is prioritizing requests in a way that makes all our work a bit easier.

AMANDA: So we thought it might be useful to just define for everyone what product means. Knowing that product means something different in all of your newsrooms. For us, product meant all of our content, our news, our features, and a lot of our annual big reoccurring things that we do. Things like lists, Talented Twelve, upcoming chemists. Things like that. And it also means all of our distribution channels. Not just print. The website. Our newsletters, our podcast. But also our advertising units. As well as our internal platforms, like our CMS.

JESSICA: So that’s a little bit about – I know it went very, very quickly. There will be time for questions later. We’ll talk about how the team works together. But we wanted to give you all an opportunity to participate in part of the process that we do every week. So we’re gonna do a prioritization exercise. We’re gonna ahead and start moving you around. You want to take this part?

AMANDA: Yep. First step is we’re gonna divide up into groups of six. We’re gonna make you move. So let’s do that by counting off to…

JESSICA: Let’s count to 11.

AMANDA: There’s a lot of people here. Thank you for coming.

JESSICA: This is hard math to do on the fly.

AMANDA: So count off.

(people counting)

JESSICA: Is that everyone? Do you have a number? Do you remember your number? So we’re gonna switch tables now. Go to your table. Table one is here. They’re pretty orderly. One, two, three, four, five. On your table. This is your icebreaker activity. It looks like we wound up with about five people at each table. Is that true? Anybody have more than five? Anybody have less than five? So we have four tables of four? Okay. All right. Pardon my math. I would like you to be in tables of six. So only the people on the higher end tables… Can you fill in for me? I think there’s one spot here. I’m sorry. We need one here. One here. Two… Basically try to be in six. If you need one… This is great. Hold your hand up. How many you need. Are we mostly groups of six now? We still need one up front. That’s fine. How many people still need a person? Hold your hand up? You need one? You need one? All right. I need a group to split up. Which one wants to do it? That one? The back one? Will you divide yourselves? Are we getting a new person? New people. We’re looking for people for groups of six. We need one person here. We need one person here. All right. So we have two groups of five? That’s fine. We’ll roll with it. Okay. Ready for the next instruction, now that we’re all warmed up and we can do math? All right.

AMANDA: At each of your tables, there’s a packet of materials in the yellow envelope. Inside you’ll find a meeting agenda. A set of six stakeholder cards. A sticker sheet. And a set of ten product request cards. We’re gonna give you a couple minutes right now to select your meeting leader and your notetaker. Two things you have to do right now. Meeting leader and notetaker.

JESSICA: You don’t have to open your packets to do this. Just decide at your table who’s gonna lead the meeting and who’s gonna take notes. The notetaker is gonna be the person who reports out.

AMANDA: Great. Sounds like you guys have selected your leaders and your notetakers. All right. You’re gonna have 15 uninterrupted minutes to run your meeting. It should be enough time to get into your role, discuss your requests, and prioritize them. When you open a packet and get a stakeholder role that’s not your own in your newsroom, that’s fine. It’s actually good. The guiding principle – it will help you get a new set of eyes on the project at hand.

JESSICA: So you have an agenda on the front of your packets. The meeting leader is gonna work through that agenda. All these instructions are on the front of the packet for you. So you’ll have time to read those. And we’re gonna put them on the screen. You’re gonna have 15 minutes to choose your role. Work through the agenda. So you’re running a meeting where you’re gonna prioritize product requests. Fairly clear? Here’s the agenda in case you can’t see it at your table. We will be walking around in case you have any questions. Your 15 minutes starts now.

Hi, folks. I just had one question about what we were gonna be asking you to report out on which I thought was a good question, so I thought I’d repeat it to the whole group. First we’re gonna ask what’s at the top and the bottom of your list, then we’re going to talk about how did your team decide priority, what method did you use, and were there any challenges and how did you resolve them. So you can keep those questions in mind. We’re about halfway through.

Hello. We’ve got five minutes. This is your one-minute warning. If you haven’t prioritized your lists, start wrapping it up. Keep these meetings on track, meeting leaders. Okay. That’s time. So let’s talk a little bit about what you learned in your prioritization meetings. So reporters at each table, we want to hear from you. What did you put at the top of the list? What did you put at the bottom? We want to learn how your team decided priority, what kinds of discussions happened, and we want to hear if there were any challenges. And if there were, how did you resolve them or not resolve them? What happened in your teams? Is table one ready? So table one, reporter. Tell us how you did.

AUDIENCE: So we’re just doing the first one and the last one?

JESSICA: And one small thing. There’s no right or wrong answer. There are just maybe some practical answers sometimes. If they’re deadline-driven things. Otherwise, let’s hear it.

AUDIENCE: So we put number one as the metered paywall. Reduce number of articles as the highest priority. An account holder can read each one from 10 to 7. And our lowest priority was website ad automated recent stories to all staff pages. We decided that was gonna be – on story pages, that would be higher priority, but because it’s staff pages, we don’t really care about that.

AUDIENCE: Nobody advocated for that.

AUDIENCE: So how we did… We didn’t have a real tried and true method for doing this, but I guess we sort of tried to figure out what would be the things with the least overhead. That would be the highest impact to do. And then challenges were just different priorities for different roles. Editorial was advocating pretty hard for some things. Versus revenue and stuff. I’m sorry. So that’s what we did.

JESSICA: All right. Thank you. Table two.

AUDIENCE: Oh, wait. Hi. My name is Kede Gross. I work at Vox Media. Vox with a V. We chose as number one remove unused CSS to improve page load speed.

(applause)

(laughter)

This was, I think, one of the reasons this got to the top priority was because it was significant to so many different disciplines. It’s meaningful to revenue. It’s meaningful to product. It’s irritating engineering. And it shouldn’t actually take that long to achieve. Our lowest was fix alignment on leaderboard ad at the bottom of most articles. Because there wasn’t really any champion for that. At any point. And it didn’t seem like there would be too many people advocating for it on the user end. There was a challenge at one point when design started talking about how they were the redheaded stepchild, and how if you weren’t gonna hire them to… Why did you hire them if they can’t do their job? But other than that, a very productive conversation. And we all had a lot of fun pretending to be people we weren’t.

JESSICA: Table three. I’m gonna be coming around, taking photos of your lists. So don’t pull them apart yet.

AUDIENCE: We’re doing some last minute role reversal. So we had the metered paywall as our number one priority as well. And then user testing as the lowest. I would say the user testing on digital magazine… Weekly email… A big point of conversation was how long things would take, and if there were specific deadlines. So metered pay wall was first for us, because if we’re gonna hit that deadline, essentially you have to start working now. Because it’s gonna be multiple sprints. Then the rest was kind of like what has the most work left to do. What has the biggest impact. I would say advertising drove a lot of the conversation. Probably the best advocate for his role, which I don’t think surprises anyone. Challenges? I think we hit not knowing enough on some of these. So for the module on the staff pages, it’s unclear as to whether or not the users are really interested in topics or the authors. And so that would drive that decision. The analytics would help to drive that decision.

AUDIENCE: All right. So our top one – there’s a theme here – is the metered pay wall launch. We did this on faith that people are just going to pay. There was no discussion about whether the content was actually worth paying for. Whether moving from 10 to 7 would drive people away or not. Just on faith. The bottom one was the add automated recent stories to all staff pages, because nobody looks at those. Except our editorial stakeholder said it was important.

(laughter)

I would say yes, we talked about dates. That played a big role in our calculus here. We listened to people who had compelling arguments. I think everybody had… At one point or another… A compelling argument on their side. And it was fun playing people that we aren’t normally. I got to be the revenue guy.

AUDIENCE: So we, in contrast to y’all, put fixing alignment on the leaderboard as our highest priority. Because we’re like… That’s easy. So we’re like we should just fix it. And our bottom one was adding automated recent stories to all staff pages, because, again, no one looks at staff pages except editorial. I think our process was good. Our biggest contention was over charts. Editorial was very insistent that charts mattered and would save time, and everybody else was like… That’s a big ask for teams that might not be able to use it efficiently anyway.

AUDIENCE: Wow.

JESSICA: All right. Next table.

AUDIENCE: There was a last-minute adjustment in our list of priorities. So the number one now is the ad sponsorship box to the editorial package, and I think the reason for was that it required only one development sprint, and the deadline was not the soonest. That’s the metered paywall. But it just didn’t require that much work, so it made sense to prioritize ahead of the metered paywall. And our last item is the user testing, the digital magazine. I think they mentioned that it’s not due ‘til Q4, and also… User testing is… It’s only one step before you actually start doing the work. So it felt like a lower priority. And we spent a lot of attention on the information provided about the amount of work required and the deadlines, and we tried to make some assumptions. We talked a lot about the unknowns of what all these things might mean to a particular newsroom, and maybe made some assumptions based on our newsrooms.

AUDIENCE: Yep. So this was very authentic prioritization, to the point where I was having, like, moments of PTSD, having gone through this before. The top of ours was removing unused CSS to improve page load speed. But I will say: Again, reflecting the authenticity of the process that went on here, originally metered paywall was on the top. But at the last minute, engineering and design just secretly swapped them. At the bottom we put updated video page, because why? We struggled mightily with the prioritization discussions, because there’s no common currency to decide what is important and what’s not. And a lot of the conversations ended up being: I’m editorial, and I want this. Which, again, very authentic. Very authentic. So we struggled. And so as it always does, revenue – because everything is a million dollars! So revenue always wins.

So that’s how we ended up, I think, with a cluster of revenue at the top. The challenges, I guess, gets back to… How to decide among things that don’t really have, like, a common way of judging whether this is important or not, versus… And things that are on this list, that are actually more like bugfixes. So we struggled with all of that. Also, some of the people in this group here, I have to say… And I’m not pointing to anybody in particular, Trei… Need to work on your interpersonal skills.

(laughter)

AUDIENCE: Engineering is whiny!

JESSICA: Remember, you’re all director-level stakeholders in this room.

AUDIENCE: So for our top priorities, it’s kind of between implementing the updated design for the video page, because a lot of the stakeholders were like… We already have this implemented. We already have it designed. It might be easy to implement. Between that and user testing for the weekly email… With some of the motivations of, like, putting the reader first and editorial is excited about that, and then at the bottom, we have implementing or including the native ad positions. And we were lucky, because even our revenue side was not crazy about it.

AUDIENCE: I’m not good at this. I don’t know.

(laughter)

AUDIENCE: Very authentic.

AUDIENCE: We also selected metered paywall as our top priority, because again, it seems like revenue is king, and anything that improves or compromises that is inevitably gonna be an organizational priority. We also looked at timelines, with the August 15th timeline looming, there seemed to be a particular sense of urgency. It’s an all hands on deck cross functional exercise. And one of my anxieties would be user testing all that between now and then, and making sure the system works as intended. And our lowest priority was the automated recent stories to staff pages. We were wondering… Does anyone actually care? Does that section really get decent traffic? And it had low impact, perceived low impact on revenue and not a particular sense of urgency. Our team was a pretty compatible bunch. Lots of cross functional empathy. What we did processwise was we sorted them into three buckets. Low, medium, high. And then prioritized within them. We noted deadlines. We thought a lot about revenue, urgency, and user impact. Challenges were selecting – were organizing within those three buckets. So we had four things in the middle. What are the order of those four things? And also the amount of knowns and unknowns. Talked a lot about how there’s a lot we don’t know. We don’t know the revenue goals, we don’t know the target audience, we don’t know the capacity of the teams and their individual priorities and the way their sprints are organized.

JESSICA: So there are a few things I want to repeat back that I heard you saying. One thing I want to note – you probably saw that there were pet projects for all the stakeholders on this list. These are the requests that come in from all different business units. There are different levels, like there are bugfixes and massive projects on this list. This prioritization we all have to do every time, whether you’re doing it in an activity like this or not, it’s a lot to hold. Right? You’re holding lots of different types of projects with lots of different deadlines and lots of different urgency. I’m glad that you mentioned that some of the items didn’t have enough detail. That you didn’t have context, you didn’t know enough to make decisions. This happens to us all the time. We receive requests, and these are lightly edited, but these are actual requests that are on our request list, and they’re pretty close to how they came in. So there’s a lot of work sometimes to go back to the person who requested it and say: What did you mean? I need more detail. I need requirements for this. We can’t put it into sprint until we have requirement documents implemented. I wrote down that our biggest contention was over charts. That was funny. Deadlines drive priority. I heard that a lot. A lot of you said we picked this because there were deadlines looming. Revenue seemed to be another top contender, and out of meeting changes, which are another thing that happens. The team where engineering swapped some items. Just noting that that’s a thing happens. Which is going to lead us into what we learned at C and EN after doing this for about nine months with our product team.

So again, we’ve been working in two-week sprints, since October of last year. And that includes prioritizing new requests every week with that stakeholder team. And so a few of the things that we’ve learned is that it’s important to kick off your team right. That’s something that you did not have the benefit of doing. We just put you all together, and you assumed your roles and you had to work together to figure it out. When I was here last year, I went to the kickoff kit session. I don’t know if any of you went to it, or even if the presenters are in here, but it was a presentation by a couple of people from The New York Times, who talked about building a team, and these exercises that you can do, to sort of get you from forming to performing faster. So I took that back to C and EN, and when we started forming this team, we ran them through some of the kickoff kit exercises. This is right before we started working in sprints. We had the groundwork laid and started getting to it. And one of the sessions was called hopes, fears, and non-negotiables.

So step one, kick off your team right.

AMANDA: So the other thing we found is we didn’t intend to break the silos that existed in our newsroom when we started the product team, but that’s exactly what happened. I think just as all of you did, we managed to get the stakeholders, the heads for each of those silos, in a room every Monday to talk through their priorities, to argue about their priorities, and hopefully – indeed, over the course of the last year – I think align their priorities. So that was an added bonus for us. Aligning stakeholders in a way we hadn’t seen before.

JESSICA: You guys were kind of having fun with it, but it actually doesn’t happen that often. The arguing. And I think that’s because we did the work on the frontend to align the team around common goals. Everyone has their own guiding principle, but we’re all essentially there for our readers and for Chemical and Engineering News. And I’ll also say it was not easy to get all of those stakeholders aligned. One of the things that has been really important is that we run really good meetings. Like our print planning meeting and our sprint review meetings – they’re scripted. There was an agenda that we go through every single time. Trying to remember if I’m skipping ahead to the next one or not. Yeah. So I’ll save that one for you. Sorry. So there are two things about meetings. But yeah, so when we pulled this team together, it was kind of difficult to get all of the business unit stakeholders, who are all at the director level, to agree to come to a meeting every single week. There was a lot of like… I don’t want to go to another meeting. I don’t have time for this. I’m traveling. Da-da-da. But we did get them all to come together, and once they saw the processes working and saw the projects moving through the pipeline, they all continued to show up every week, and we’ve been iterating on the process every single time we meet. But also, speaking of those meetings…

AMANDA: So one of the things that I think has made them really productive and work really well is that we take turns. So you have – everyone had a meeting leader and a notetaker at these tables. And just like that, every week we alternate our meeting notetaker and our meeting leader. And there was a lot of resistance to that up front. A tremendous amount of resistance to that, I would argue. And I think part of it is just comfort level. But we really didn’t want the people who were either good at or didn’t mind taking on those jobs to always have to take them on. And so that’s actually, I think, improved meetings across our whole organization. A. Which is good for me. Being one of those director level stakeholders who had to go to all these other meetings. But also the other thing that we really saw happening was that people… When people take vacation, for example, or they come to a meeting like this, our work doesn’t stop anymore. And that used to grind us to a halt. Because those decision makers weren’t around.

JESSICA: This was a really unpopular idea. The idea of rotating meeting leadership and notetaking. When we did the six month retrospective, that was one of the biggest complaints people had. I don’t understand why I have to lead this meeting. I have lots of other things to do. That was at all levels of the team. There were multiple people who didn’t like doing it. And I’ll say it wasn’t systematized at the time. I initially started this by taking volunteers and having people sign up, basically. While also watching to make sure everyone was doing it. And after that six-month point, or right before the six-month point, I basically just made the list of the whole group and said: This is our order. If you need to change because you’re gonna be out or something, let someone know. Get a sub. And we’re gonna repeat this list over and over. And now that we’re doing that, I think it reduced some anxiety. People don’t have to sign up anymore. They don’t have to volunteer.

And everyone’s done it now. Everybody’s done it once or twice. Everybody’s done it at least twice, and the meetings are going so well. So the people who were really nervous about leading a meeting, maybe the first time they did it, they went over on time or something. They’re like… Rolling now. So… We just had our last sprint planning meeting with a new person running the meeting on Monday. Who had never done it before. And he killed it. It was so good. So that’s really exciting. Just to see that kind of thing working. And then finally… Looking for ways with this team – because it’s a new newsroom team, and it’s this cross functional team that doesn’t all report to one person, we’ve been sort of still working on how do we celebrate our work. Like, the work that the product team does happens behind the bylines. It’s a lot of invisible work that keeps our newsroom working smoothly. That the rest of the newsroom doesn’t always know about. So some of the ways that we have started to report out to the rest of the newsroom is to include updates about the product team in the once-monthly C and EN-wide senior leadership meeting. So we’re including updates there, where we report back. And then we’re also gonna start doing product memos. Quarterly product memos. At the end of this quarter. To just let everyone know how things are going. And then one other… Sort of small thing that I think is important is that we’re sort of working in – reporting back to the people who made the requests originally. And letting them know… Where your item is on the request list. Hey, we prioritized this week. It’s in medium. You may not hear from me for a little bit. If this becomes more important, please wave your hands. Or your item moved into sprint, so people are gonna be reaching out to you for more information probably this week. So we’re still working out that part. We built a lot of the processes about how the team works. And now we’re working on how we report out to the newsroom. How that all is functioning.

So that’s the end of what we have prepared. I’d love to hear questions. Yes?

AUDIENCE: Would you take your specific teams, the director level stakeholders, and have them switch roles the way we did here?

JESSICA: So we’ve talked about this. Since deciding to do this. And we have an all-hands staff meeting every year, where we bring everybody in, and so we were talking about doing it just staff-wide. Not even just the directors. But just having everyone do it.

AMANDA: To build empathy, I think. It was sort of a last minute decision as we prepared this, that we should actually force people to take a role that’s not their own. Yeah.

JESSICA: So that’s definitely something that’s… I’m gonna collect all these things and just reuse them, probably. Yeah?

AUDIENCE: Two questions, really. The first one, I guess, is: Who and how are the requests coming in? And the second one, I guess, is: Does everyone work on everything? Or are there certain people that have specialties that you then have to keep in mind too? That even if the person who does the podcast has no high priority things right now, are you still feeding them work?

JESSICA: So requests come in through Slack. And they come in from anyone within our news organization. So that’s reporters, production editors. Our editor in chief. Everybody goes through Slack. Which has been a fun process. Like when you have to tell your editor in chief – that’s a great idea. Please put it in this product request. I’m not doing anything with it, unless I see that. So we run it through Slack and then it goes into our product request board from there. And so in our sprint planning meetings, these things have already been prioritized, like new requests have been prioritized, and the whole team decides who’s gonna pick up an item. So we have engineers on the team. We have designers on the team. We have a couple of production people on the team.

And then also the stakeholders contribute too. So stakeholders tend to pick up research. Items for a research sprint and they also pick up requirements gathering for things that are kind of in their wheelhouse. So things are sort of divvied out by what would fall in your area. If that makes sense. Does that answer your question? Do you have more?

AUDIENCE: So the people… Does that mean, then, that there isn’t a group of people who are constantly checking the backlog to see what to do next?

JESSICA: So I do a lot of that. The question you had about the – the podcast person might not realize they need something right now. So the next phase of what we’re doing – this is the first nine months. The next phase is that we’re building out our product portfolio, looking at everything we have. All the stuff that Amanda put up there. We have now assigned owners for all of those things. Every product has an owner. Not on the product team, but newsroom-wide, someone is an owner for it. And we’re starting to fill in information about each of these things. The whole point of a lot of this is to take a holistic look at what we have and get all of that information about the status or the life cycle of individual products out of someone’s head and on to something that’s documented, where we can look at it all, and decide where to put resources. What needs attention. So once we have something like the product portfolio, I might look at it and say… Oh, we haven’t given any care to this podcast in a long time. And no one’s asked, but maybe we should go look and see if it needs a branding update. Or does it need user testing? Or do they want to do something new, and they just haven’t even asked us about it? So that’s what’s coming next.

AMANDA: I would also add that another thing that I think you saw in the prioritization exercise, at least when I was walking around, is that: Because they’re staff-driven tasks, the tasks’ descriptions can be vague at best and confusing at worst. And so another thing that we’ve been talking about is: How can we standardize a little bit more the information that comes in, so we’ve piloted in a separate part… My side, an events request system, and we’re thinking about… We’re sort of piling that on a small-scale. Because to bring it into the product team, because of the volume of requests that we get would be much higher… So we’re looking to switch it over into some kind of form-based system that would reduce the amount of confusion in meetings, where we’re like… We need more information. Where are we going to get it from? The person who can give it to us is not in this meeting.

AUDIENCE: Trei, cover your ears. Have you had any C-suites come in and just blow this up? And just go… We’re pivoting here. Just stop. If you haven’t… Do you think you have a better plan now, since you’re all equal stakeholders, that you can actually feel empowered to go… We think this is a good idea? Or no, we’re not doing that?

AMANDA: I guess I’ll take this, because I’m the closest one to the C. No. I would say up and down we have buy-in. I think the requests that we get in – it used to be… And I think the reason for this is that we used to have our advertising team – used to go in to IT, into engineering, completely differently than everything else for the newsroom, and then they would trump, basically, blow the whole thing up. But it was just such a slow process, because this is more efficient, I think efficiency is winning the day. They’re seeing their things speed up, and as a consequence, they’ve bought in. So no. We haven’t seen it. Cross my fingers. But… I think again, I think efficiency and putting rhyme and reason and predictability and visibility into the pipeline has helped.

JESSICA: I think we’ve also seen… So we have this parent organization, the American Chemical Society, that is our parent organization. And they are much larger and have lots of different types of resources. And so they have a lot of IT resources. And we have a few of those people in our product team. So we have pulled those people in. And historically, different teams – so not just our newsroom – but other groups within the organization – they’ve all had challenges, working together in an effective way, and so we have started getting feedback from IT that they like how this process is working. And they would like to see this sort of scale into other parts of the organization. But they’re just happy with how things are moving, and that we’re all communicating really well, and I don’t know if anyone went into the blaming engineering session today, which was really good. We used to be there, where things would get buried or dropped, but now we have this touchpoint every single week where this whole group is coming together and they’re learning how to flag roadblocks, which is not a thing that happened before. Things that were problems might just sort of disappear, and the project might disappear, and no one was championing it. And so six months later, we’re like… What happened to that thing we were doing? So it’s sort of just… Tying the group together better. Any other… Yeah?

AUDIENCE: How have you handled priorities that transcend the organization? So if I was looking at this list, and we were in an organization that was moving very rapidly to reader revenue, you might prioritize newsletter-style things above advertising-style things. But of course, the ad people aren’t gonna like that. So how do you handle those kinds of conflicts?

AMANDA: The step we skipped in describing what we’ve done, intentionally, just for the sake of time, was… Last year, one of the first things we did was build a newsroom-wide road map, so you didn’t have that to guide you. But I think that’s also been absolutely critical to allowing us to make those kinds of decisions. Because the road map does give you that sort of overarching – it was built out of our strategic plan, out of our parents’ strategic plan. And the priorities are laid out pretty clearly, and that even on the road map, there are places where we’ve indicated we’re expecting that this thing is gonna need product team assistance, and so it kind of feeds into what we’re doing. So I think that is critical. I don’t think this would have been… This exercise, you could see, would be really difficult if you didn’t have that kind of overarching thing.

AUDIENCE: Most organizations don’t. That’s amazing you guys do. That’s incredible.

JESSICA: We also didn’t, before.

AMANDA: Now we do.

JESSICA: And we’re kind of talking about this in a circuitous route, which is sort of how we’ve taken it. We’re experimenting with things, we’re trying new things. I feel like in another six months, I’m gonna be able to make this really beautiful timeline of like… This is how I would do it, if I could start from scratch and know all of these things. I would build a road map, and then I would build a product team. But we’re kind of just feeling it out as we go, and we’re just continuously improving the process. And thankfully, we have the sort of bandwidth and freedom to do that.

AUDIENCE: How is that road map communicated to everybody else on the team? Do they all have access to it? What does it look like? How often is it looked at?

AMANDA: So everyone has access to the road map. In fact, everyone on the team, much like the product pipeline, can make a request for the road map.

JESSICA: Not just the product team. The whole staff.

AMANDA: Sorry, the whole staff can make a request that goes onto the road map. Jessica had mentioned that we get together for an all-hands meeting. All the international staff come in to DC for a week and part of that activity is we do road map planning for the following year. And so that’s the process. So there’s input that they have in the process. And then it’s staff-wide. It’s always available. Jessica and I do quarterly road map updates, memos to staff. Reviewing… What have we checked off the box? What’s coming up in the next quarter? And I think having that at the highest level – and we reported out, I reported out upwards, as well. It’s part of our reporting into our editorial board. Governing board. Corporate boards for the non-profit that we work for.

AUDIENCE: I was wondering how analytics played into this. I don’t know if that fell under the product part of the team…

AMANDA: In our newsroom, audience, where analytics lives, is also a cross functional team. It partly reports into editorial. And it partly reports into marketing and sales. So the two stakeholders that represent those bring in the analytics piece.

JESSICA: I think one place where product is going to start to affect that is as we build out the portfolio, we’ve said it is the product owner’s responsibility to pay attention to analytics. And to sort of initiate requests. At least at the start. Once we have this sort of nice picture and have a person who can monitor it all the time, someone will help. But initially, the product owners are responsible for monitoring analytics and asking for things when they need it. Yeah?

AUDIENCE: I’m curious if you’ve built in time for reflection and looking back and seeing if the work you did was effective.

JESSICA: The work meaning the process work? Or the individual tasks that the product team is working on?

AUDIENCE: I guess both.

JESSICA: Okay. So I’ll start with process. While I ponder the tasks part. So for the team, because this is a new thing that we’ve been doing, we’ve built in – we have done so far a six month retrospective, and we’ll meet again at the one-year mark to talk about how this is going. Our agenda is an open doc that anyone can… It’s structured, so there are things we’re gonna do, but there’s a section that’s planning and process updates that anyone can add something to. So, for example, recently the engineering team… Somebody went sort of outside of the product request system, with a request that seemed very urgent, but it was not urgent. We had to have another talk about… Under what circumstances do you go directly to engineering? The server is down. If something bad has happened. It’s not just like an ad has shifted by 3 pixels. So those kinds of things we work on all the time.

Looking back at how things are working, I think that goes… It’s a couple different things. So a lot of these projects contribute to road map things. So those are often projects that someone is managing. So those people are requesting things, they’re letting us know if it’s going okay, if something didn’t get fixed, if it needed to be looked at again. Things like a metered paywall – that’s a big example of that. That’s a project that people are working on. So they’re submitting product request items as they need them. So it’s not at this time…

AMANDA: Tech-specific. Yeah. I think we do those sort of retrospective – how did it go at the project level. So it would encapsulate a few different product requests that had gone into support that task. So it’s certainly part of it. But we haven’t gone to the level of, like, okay last week, the release included X, Y, and Z. How do we feel about those things? That hasn’t been something we’ve tackled yet.

JESSICA: With that, we’re at a point where we’re like: Yay! We have regular releases! Because that was not a thing that was happening before.

AMANDA: And there are a lot of things in those releases.

JESSICA: It was very hit or miss before.

AUDIENCE: So I’m not exactly sure the total org underneath those product owners, the size of it. But I was wondering… Assuming that it is multiple people under each stakeholder, do you mirror in some way or parallel the sprint process that you use for the stakeholder meetings? And the sprints in those teams? How does that look? How does that connect? Are they also two-week sprints? Is it just that priorities get handed down and assigned? Or something else? I was just curious.

JESSICA: Let me think about that. The two people I can think of… So there are two stakeholders that have individual contributors on the team. And so that’s engineering and creative. And so all of those people are in the meeting. They’re all in there. There’s no one outside of the product team meeting. Is that answering your… They’re there.

AMANDA: I would say the exception would be requirements gathering. So say somebody from editorial who works on the podcast says… I want X, Y, Z. I’m in the meeting. I’m not gonna send them to the meeting. I don’t want them to go to that. I want them to do their thing. I’m gonna say: I own requirements gathering, and then I’m gonna go back to them and say: Here are standard requirements. Fill this out for me by this date. And I’ll check in and bring it back to the team. So I think in that sense, there are some people sort of outside the team that are doing some work. It tends to be on the research and requirements – the creative and development stuff. Those people are already in the meeting. And so they get a voice too. Like, what else is on their plate. Are they going on vacation this week. Do they have doctor’s appointments, so they can adjust the number of points that they get accordingly.

JESSICA: We’re pretty close to the end. Yeah?

AUDIENCE: Do you see a scenario in the future where you need to adjust this for scale? Like, if the people… You made a face. I want to know the thought behind that face.

JESSICA: Was there more to that question? Is that the end of it?

AUDIENCE: Really just that. Is there a point where it wouldn’t scale and you need to adjust it?

JESSICA: There’s one thing that’s coming to mind immediately that I’ll talk about, and if you have some other thought, go for it. There are some large projects that are just self-contained things that this team doesn’t manage. So for example, a production system upgrade that is essentially owned by operations. We had to figure out how do we want to do those things, now that we have this team. Because people on this team are gonna work on that project. But we don’t want that project to suck all the oxygen out of this team, basically. We don’t want all of our sprints for the next six months to be this upgrade. So operations just handles it. They put together their project plan, they put together their requirements, and then someone from the product team works with them to sort of task it out. Figure out: What is the work that you need from the product team to get this done and on what timeline? And then those things come in. So that’s like a very small example of how this has started to just grow.

And I’m gonna stop there. Any other examples that you can think of?

AMANDA: That’s what I was gonna go to.

JESSICA: And scale, when I’m thinking about scale with this, I’m already thinking about our parent organization, which has lots of different groups. They’re not necessarily… They’re not media groups. But there are a lot of publishing groups that are starting to look at this model and think like… Oh, can we use some part of this? Is there some way that we can get our team to work with this in sprints? So that’s, I think, kind of a scaling direction for us.

AMANDA: How would you scale it for 55 journals that publish 10,000 PDF payments in HTML a month? It’s like… Sort of an astonishing scale problem. And then how would you scale it for a database and information systems product that’s on every researcher’s desktop? So those are other kinds of products that our parent company works on. And I think that’s – when I was making that face – that’s the scale challenge to me. They’re very different. Their road maps are different. They don’t have road maps. Their priorities are different. Their stakeholders are different. Their road maps are different. So I think that’s a scaling issue that would lie ahead.

JESSICA: So… We are basically at time. Thank you all for coming. If you have other detailed questions, you want to get in the weeds, you want to see our road map, say hi and we’ll talk about that. Thanks for participating in the activity. Also, one of our analog products is on the table. Those are Chemoji stickers. Those are chemistry emoji. So those are yours. Take them.