Lucie McLean is Head of Product for Children’s at the BBC in Salford. She has worked for the BBC for 19 years — nine years in journalism and ten years in product management. Most of her product career has been in mobile products and she led the teams which developed the mobile website and award-winning BBC app for the London 2012 Olympics and the hugely successful BBC Sport app. She now leads the teams developing the BBC’s websites and apps for children. She is passionate about increasing diversity in digital organisations and helping those new to the digital world embrace the opportunities it offers.

Video

Slides

Transcript

Amazing to be here. It’s extra amazing because it’s the first time I’ve been on a stage in Scotland since I left Cumbernauld Youth Theatre in about 1992. So it’s really special. Because I’m on first, I get to do this. I would love to find out who we’ve got here. So please put your hand up if you’re a product manager. Great. Please keep your hands up, product managers. Keep your hands up if before becoming a product manager, you were something else. I don’t mean if you were a child, but like if you had a different job. Different job. Okay. So once you were something else. So gentleman in the dark top, what were you? You were a developer? Gentleman there? Engineer.

So lots of different jobs. So I was something else as well before I was a product manager. I trained as a journalist. I went to Strathclyde Uni. I did an English degree on a Journalism postgrad, and I joined the Glasgow Herald. Then I joined BBC.

I kinda won my job in a competition. I entered a journalism competition when I was at Uni, run by The Times newspaper, and John Simpson was a judge. I came second, but he offered me a job. So it will be 20 years ago next week that I went to London to work for John Simpson and kinda never left.

So I joined the World Affairs unit, so I was involved in sending correspondents to war. I then went to work in the newsroom. So this is me working at News 24. This is… I think it’s 9:10, the night of the millennium. This is a Hogmanay, waiting for the Millennium Bug. It didn’t happen. I then moved to BBC News Online, became a journalist there, became product manager about 10 years ago. I moved to Salford six years ago, where I ran the only London 2012 work stream outside London, mobile work stream. So my team built the Olympics app, the Olympics mobile website, then sport app and lots more sport things that I’ll talk about.

So yes, there was a time about 10 years ago when I wasn’t product manager. I didn’t know how software got made. I didn’t understand this stuff. If you’d ask me what my references to Waterfall was, I would have said this album. If someone would ask me what Jira was, my guess could have been it was a lovely place where they made great whisky. And this is where I am now. This is Salford. This is, I think, one of the BBC’s best inventions. It’s an absolutely amazing place to work. There’s about 3,000 of us there. And it’s absolutely brilliant.

I think the BBC has got a long history of making amazing things: Ceefax, BBC Micro, iPlayer, London 2012 Olympics. Lots of great stuff, but we’re not a digitally native organization. We can’t be. We’re 90 years old. And the Director-General Tony Hall has set out a very clear mission for BBC to become internet-fit.

I work for the department of design and engineering. We’re absolutely at the heart of that. And product managers have got a really, really important role to play in that. So I want to talk today about how we’re approaching that. What I’m trying to explain, how it’s different being a product manager in a company like the BBC or organizations that are quite similar to us, I often come back to this chart. I think this is really, really fascinating.

This is from an article that was in TechCrunch in January, and I’ve stolen this chart from them because it’s just so interesting. It talks about the difference between traditional and digital organizations. I don’t agree with all of it. I don’t think only digital companies think about innovation, think about scale. I just don’t think that’s true. But a lot of what’s in the right column…a digital organization is about people, it’s about collaboration, it’s about UX, it’s about defaulting to Yes, being agile. And that last one about relationships and partnerships is the most crucial one to me. Building product culture in organizations like BBC is absolutely founded in building those relationships. So that’s what I wanna talk about today, the things that we do to build those relationships.

So I’ve got six things I want to talk about. If you sit there going, “It doesn’t really apply to me. I don’t work in a company like yours,” think about the people that you work with, who might not be where you are in this journey with digital transformation. I also think a lot of what I’m gonna say today applies to other disciplines as well. So think about something that you do that you may have to let people understand. And I think you can probably reuse some of these thoughts as well.

So the first thing we do is to evangelise product management and helping people understand what it is. And I think when you’re first introducing product management to organizations, there’s kind of an unspoken question. Where’s the control? Who’s in charge here? And I think it’s quite easy to diffuse that when people actually understand what product management brings. It’s not about trying to be in control. It’s about making sure that the best things get built in the best for the best reasons. And I think the best way of doing this is to be able to show it, be able to find a way to demonstrate it, rather than actually telling people what you do.

So I joined BBC Children’s about two years ago, and we have a number of different things that we do. We commission a number of games every year for the website that support our TV shows. And these are commissioned by third parties… Sorry. They’re built by third parties, mainly in the UK. These are sort of four recent ones we built. So Danger Mouse was one that was… one that kind of, we wanted to make that a bit of an example of how we can improve our product by putting some kind of product rigor around them.

So we had a games team who were commissioning these games, and I put a product manager and a business analyst into this team and asked them to start thinking about putting some product process around our games. So before Danger Mouse was launched, we spent quite a lot of time and effort getting really good detailed stats in it, stats that could really help understand what’s going on with the product. And after the game launched, we looked at what was happening with the game.

So this chart shows how…kinda when we’re losing players through the game. So the game had loads of levels, but we saw that we were losing a large…during the tutorial, which isn’t great. Then a few levels down, we’re losing loads more players. So lots of people weren’t going to experience those beautiful levels later on that we spent a lot of time and money on as well. They just won’t get to spend as much time with the game and the brand as we’d hoped.

So we record the XY coordinates of when people actually leave the game, and we saw this little spiky guy who killed 25,000 children in the first two weeks. So we got rid of him, and that increased the number of users engaging with the game longer by 9%. So that was just looking at the data we already had from that product. Just kind of looking at it and understanding what was going on and making changes on the fly. We then actively thought about, well, how can we start to introduce build, measure, learn processes into developing this game?

So we had a hypothesis that for children who were really struggling with one level, just let them go past it. Let them try the later stuff. There might just be one thing in that one level they’re not getting. They’re getting frustrated and they’re gonna go away. Let’s give them a chance to kinda try later levels.

So we introduced a Skip Level element, 70% more players engaged those later levels, got to spend more time with that game. Our games usually have kind of a half-life like this. So they kind of start really high, burn really bright, and fade away. But Danger Mouse is just going against that. It’s getting stronger and stronger and stronger. So it was released in September and it’s still our most popular game. It’s doing absolutely phenomenally. So that was a good example for us to show what product thinking can bring to a piece of content and the experience.

I think it’s also important to talk about product management as a discipline. So there are two million people on the LinkedIn with product manager in their job title. We didn’t invent this stuff. We didn’t make this up. This is how stuff gets done. So then talking about how competitors and other big companies that people respect use product management is really important, showing those examples. Quite often I’ll bring companies in to talk about how they use product management, just to help people understand its role in digital services and generally.

A very important thing is to have empathy in thinking about what’s going on in the minds and the hearts of the people that you’re working with when you’re on this journey. A key thing that I think about a lot is what went before. So chances are you’re probably not the first people who a lot of your colleagues and stakeholders will have worked with to make digital stuff. Understanding what relationships you’ve had with people in the past is really important.

Back in 2012, the BBC relaunched the BBC Sport website. Before the Olympics, we wanted to get the Sport website ready. And our product team spent a lot of time and effort doing lots of research with the audience to kinda make sure it was the best product it could be, but it’d be nine years since the last big Sport website refresh. It was a big bang release, and there was a vocal minority who did not like it. I’ll leave you to read this quote yourself.

Yep. Yeah, that happened. And when the site relaunched, there were a number of public blogs written by the journalists and the creative director and the product manager, and these are the kind of things that were left. And of course, for a website that millions of people use, that wasn’t the majority of response, but that was loudly seen. And that left a mark on the people that built it, on the people who were involved with it. And I think the next person who had to go out and suggest to change the website had to bear that in mind. That person was me, who had to go next. And I’ll explain a little later how I approached that.

I think understanding the impact of your work is also important, so understanding the changes that you make to a product. Even if people have developed insane crazy ways to deal with, you know, work flow bugs and issues, be mindful that’s what they do now. So if you change something, that’s gonna have an impact on a lot of people.

Something we did in Sport when I was building the mobile website was we got the software engineers to go and spend time with the journalists who did the live test commentary, just to help them understand how people use their products and just kinda build those relationships, and start to show your interest as well. It’s just nice to build those connections.

Does anybody here build apps or work on apps? Yup. Does anybody find that backlogs are really unsexy? Really unsexy stuff with changing operating systems and new devices coming out and changing UX requirements. Quite a lot of stuff is involved in just keeping an app alive and keeping it growing. And I saw a lot of this when I was in New York in February. I went to the New York…I went to North American Toy Fair in New York. And it seemed that most toys come with an app now, so whether it’s a dressing-up set with an app that helps you record your story, whether it was a virtual reality coloring book. And I could really see companies struggling with the fact that when you give birth to digital product, you’ve got to look after it. You’ve got to love it. You’ve got to spend time and effort on it.

So they were loving the fact that by having this digital add-on to their product, they could start to see how long their products were being used for and actually it would extend the life of the product and sometimes… But long after money had been spent on that box of stuff, you’ve got a product you’ve got to support. You’ve got to keep that app alive, and people are really struggling with that.

And I think that unsexy backlog, I can kind of hide it in the corner and go, “Yeah, we’ve just got this stuff to do in our product,” but I don’t. I use it and I show our stakeholders that this is what’s involved in creating digital products. It’s very different from making television or radio or many other things that our customers…that our stakeholders work with. It’s different. It takes time and money.

An app is for life, it’s not for Christmas. You have to feed it. You have to look after it. It will pee on the carpet. It will chew your slippers. You’ve got to look after it.

I think everyone wants to make informed decision-making, and I think product managers can make this process so much easier when you’re doing this with stakeholders. I think because we live and breathe our products and all the decisions we have to make about them, we kinda forget other people don’t. So sometimes you have a limited time with the people who you have to make decisions with, and bearing that in mind is really important.

We launched the BBC iPlayer Kids app earlier in the year. We worked in conjunction with the iPlayer team to build that. And we decided really early on that we wanted to build the app on the iPlayer code base because it’s a really solid code base. It’s been around for years. Millions of people use it, and it’s also a really quick way to get to market as well. And that meant that the feature set for the MVP was gonna be fairly fixed. So we knew what was gonna be in it. And helping stakeholders understand that was really important just as I say because we can’t put that much extra stuff in. You know, iPlayer has got certain capabilities and features. We wanted to use them first. We’ll build the other stuff when we sort of look at the feedback from our audience and see what the need is for it.

So we slowed down. We slowed right down and we spent some really good detailed sessions with our stakeholders, helping them understand what iPlayer did, why it did certain things. It impacted a lot of the front page. You know, it impacted how search worked, it impacted how downloads worked. We had to help them understand why things were the way they were. But we also had some fun stuff we could do with. So we built an avatar system. We spent a lot of time thinking about what the right avatars would be for a product that had to serve not 12-year-olds. So there was some really good fun stuff to do as well, but some stuff just kind of we had to land. So we slowed down and we helped people understand it.

I mentioned earlier that…about the Sport website. So yeah, I was the person who had to go back in and said, “We’re gonna change it again.” And that started in 2013, but went to start making the site responsive. So I was thinking ahead to the Commonwealth Games and the World Cup where we wanted to introduce our first responsive pages. This is the BBC Sport Home page. This was in 2013. It was massive. It just went on forever, this huge, huge number of components and modules. And we knew we had to cut them down if we wanted to kind of shrink it into one column for mobile. And I wanted to make sure that that conversation about what do we get rid of, what do we keep, what’s working, what’s not, was really well-informed. So now we’ve got products like Chartbeat, but we didn’t back then.

So I got the software team to develop just a really simple heatmap that could help us see what was being used. And you saw once you got below the first couple of screens, people just weren’t using stuff at the bottom. And I just made that conversation about getting rid of stuff is so much easier because it was based in data and it was just earlier conversation to have.

I think language is really important. Language can build bridges. It can also build walls. So I think that’s a really important thing to bear in mind. So there’s a cracker, where I work: when something’s in development, that’s what I think it means. If you work in television, it’s a fuzzy front end having ideas in brainstorms completely different. So if someone says to me Teletubbies is in development, depending on who’s saying that, it could be two completely different things. So understand the language of your world and your stakeholders’ world and your clients’ and customers’ world is really important, too.

I think be mindful of the terminology as well. Definitely don’t say… I’m not saying don’t do the things, but I’m saying just be careful about how you explain what you do, and do explain what these words mean. Ways that we do it is using examples. So when I was talking about how we were going to evolve the Sport website to a responsive site, I wanted to stress that we were not gonna do a big change. It was gonna take a while. We were going to develop iteratively. And I was thinking about how do I explain the concept, iterative development, to senior stakeholders. Examples help.

So I used this one. It’s a story… It’s probably a myth now, that eBay once had a yellow background, and they took it away and people didn’t like it. So they put it back in, and over the next 100 days, turned the yellow down a little bit every day until nobody noticed. I’ve also heard the story the other way around where it was a white background, they wanted to make it yellow. But anyway, you kinda get the point, don’t you? To say that you can do things slowly and gently rather than the big bang approach, and that’s what I wanted to stress. This is how we were gonna change the Sport website in the future.

I also absolutely love analogies as well. So that iterative development one, I’ve also told it through the example of boiling the frog. Everyone aware of this one, where you put a frog… If you put a frog in a pan of hot water, it will jump out. If you put a frog in a pan of cold water and slowly turn the heat up, it wouldn’t notice. I used that example once and was then told, “Yeah, I think we’d prefer iterative development.” Great. Job done. It worked.

Another one I use a lot is shopping centers. I love a shopping center. I have used this to talk about platforms, about how to build platform approaches. My current use for it is thinking about onward journeys. So we have a number of things that people come to support in huge numbers like that Danger Mouse game, like things involving Newsround or “Blue Peter.” So I’m thinking about how do we use those experiences to drive people to other content that they may not necessarily find. And I started thinking about shopping centers and started thinking, “Well, you don’t build a shopping center unless you’ve got a John Lewis or a Marks & Spencer.” So what are our John Lewises? Who do you make the ambassador? How do we make them do a better job for us? So yeah. Kinda good thing to see sort of crazy people as well thinking about analogies. I love a shopping center.

My two favorite words now — “why.” I’m obsessed with why. I’m always asking why. Why do we do that? Why do we not do that? And I think if you say it often enough, other people start saying it, too, and it’s the best thing ever. I think when people start to become receptive to the concept of me asking why all the time, I’ll sneak them Simon Sinek’s TED Talk. And if they love that, I’ll sneak in the book. And just kinda getting people bought into why we do anything is really helpful. And I know when I go to meetings, people know I’m gonna ask it, so they kinda have the answers, which is great as well.

The most powerful word, I think, is “we.” I think finding that common ground, and you know, looking at how…and just talking about us, us doing things for our audience is the most important way to kinda build that connection. I don’t think your “we” can ever be big enough as well, so I think finding friends throughout your organization, throughout your community is really important as well. So I mentioned that I was a journalist in the BBC News Online Newsroom, and then became a product manager. But I stayed close to the Newsroom, and I found people in the Newsroom who I knew had kind of an interest in technology, an interest in the tech, and used them to help me as well. I say, “Use.” Doesn’t sound very nice, does it? I worked with them.

An example was when I worked on the WAP site. Remember WAP? Ages ago. So BBC News had a WAP site, and that WAP site got its stories from the stories on the BBC News website, which looked a bit like this. And they took our content from kind of the body of the story that didn’t include things like the textbox. So in this story, on the WAP site, you’d find out that Vancouver was the best place to live, but you wouldn’t that Melbourne was number two or Vienna was number three. But the journalist in the newsroom didn’t know this, and I had to try and find a way to help them become aware of this, but I couldn’t sit in the newsroom and kinda remind them each time. And I also couldn’t get the changes made to the CMS to incorporate this stuff anyway.

So we got the mobile phones. We got the guys who had that 6:00 shift in the newsroom. We got the mobile phones. In their taxi on the way to work, they could be looking at the news website on their phones and just kind of… It was helpful. They got to see the headlines as well, but also gotten familiar with our product. So we were always trying to find ways to kind of build those connections with people.

I think it’s really important as well as getting closer to your building as to get out of it as well and staying close to your peers, coming to events like this. Though you’re product manager in an organization where it’s not native, you’ve got to be at the top of your game, I think. And coming to events like this is an amazing way to do it. And it’s a great place to build those examples. I talked about having to, you know… It’s a great thing to bring examples back to your organization of things that work, companies doing great things, things you can learn from. This is where you get that stuff. It’s the best place to get it. I think it’s important to take time to get out and kind of reevaluate how you’re approaching things, what you’re doing. And again, that building is just a great way to do it.

Last of all, just be nice. Just be approachable. Be the people that people are comfortable going to and working with and going, “Do you know what? I don’t understand this stuff,” or you know, “Will you help me? Will you answer the questions I’ve got? Will you come to the meeting with me and show these people what you do? I think it’s really interesting.” It’s just so much easier to get stuff done. So thinking back to that time when you weren’t a product manager, well, you didn’t know this stuff either. Bearing that in mind, think about the time that you thought Agile was something that happens when you went to yoga, the time when you thought confluence is something you got from eating too many beans. It’s really important.

So I think building product culture in digital organizations is about building relationships that can unite the business behind those kind of defined objectives, behind that clear product goal. And I hope I’ve shown you today when you say some of the ways that we try to approach it and how we’re trying to help the BBC build its digital future. Thank you.

 

Video is great, but nothing beats being there. Join us at Turing 2017!