Product managers in non-digital organisations can often find themselves building product management culture in their companies - as well as building products. Lucie McLean shares the tools and techniques that have helped her and other product teams at the BBC build successful products by developing relationships across the corporation.
← All talks 
Build Product Turing Fest 2016
Building Product Culture in Non-Digital Organisations
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
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 Cameron Old Youth Theatre in about nineteen ninety two, 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 for the 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 if you had a different job. Different job. Okay, so want say you were something else.
So, Gentleman in the dark top, what were you? You were a developer? Gentleman there? Engineer. Lots of different jobs. I was something else as well before I was a product manager. I trained as a journalist, so I went to Shaft Clyde uni. I did an English degree and a journalism post grad, and I joined the Glasgow Herald.
Then I joined the BBC. I kind of 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 twenty years ago next week that I went to London to work for John Simpson, and Kean never left.
So I joined the World Affairs Unit, so I was involved in sending correspondence to war. I then went to work in the newsroom. This is me working at News24. This is nine I think it's ten past nine, the night of the millennium. This is also Hogmanay waiting for the millennium bug.
It didn't happen. I then moved to Beads Senior Online, became a journalist there, became a product manager about ten years ago. I moved to Salford six years ago, where I ran the only London twenty twelve work stream outside London, the mobile work stream.
So my team built the Olympics app, the Olympics mobile website, then the sport app and lots more sport things that I'll talk about. So yes, there was a time, about ten years ago, I wasn't a product manager, I didn't know how software got made.
I didn't understand this stuff. If you'd asked me what my references to Waterfall was, I would have said this album. If someone had asked me what Gier was, my guess would have been it was a lovely place where they make 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 three thousand of us there, and it's absolutely brilliant. And I think the BBC has got a long history of making amazing things. CFACS, BBC Micro, iPlayer, London twenty twelve Olympics lots of great stuff, but we are not a digitally native organisation.
We can be, we're ninety years old. 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, and we are absolutely at the heart of that. Product managers have a really, really important role to play in that.
So I want to talk about today about how we are approaching that. When 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 it because it's just so interesting. It talks about the difference between traditional and digital organisations. I don't agree with all of it. Don't think only digital companies think about innovation, about skill.
Just don't think that's true. But a lot of what's in the right column in the digital organisations 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 organisations like BBC is absolutely founded in building those relationships. So that's what I want to 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, what probably doesn't really apply to me, 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 going to say today applies to other disciplines as well. So think about something that you do that you might have to help other people understand, and I think you can probably reuse some of these thoughts as well.
So the first thing we do is to evangelize product management, helping people understand what it is. And I think when you're first introducing product management to organisations, there's kind of an unspoken question. Where's the control? Who's in charge here? And I think it's quite easy to defuse 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 way 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 telling people what you do.
I joined Boobsy 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 the four recent ones we've built. So Danger Mouse was one that one that kind of sort of wants 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 these teams 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 was going on with the product.
And after the game launched, we looked at what was happening with the game. So this chart shows how kind of when we're losing players through the game. So the game had loads of levels. But we saw that we were losing large portions of people during the tutorial, which isn't great.
And a few levels, we were losing loads more players. So lots of people weren't getting to experience those beautiful levels later on that we spent a lot of time and money on as well. I just weren't going 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 twenty five thousand 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 nine percent.
So that was just looking at the data we already had from that part, 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 and that one level they're not getting, frustrated and they're going to go away.
Let's give them a chance to kind of try later levels. So we introduced a skip level element. Seventy percent more players engaged in those later levels, got to spend more time with that game. Our games traditionally have a kind of a half life like this, so they kind of start really high, burn really bright, and fade away.
But Danger Mouse has just gone against that. It's getting stronger and stronger and stronger. So it was released in September, and it's still our most popular game, 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 LinkedIn with product manager and their job title. We didn't invent this stuff. We didn't make this up. This is how stuff gets done. So I think talking about how competitors and other big companies 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 in general. A really important thing is to have empathy and 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 twenty twelve, the BBC relaunched the BBC Sport website. Just before the Olympics, they wanted to get the sport website ready. And the product team spent a lot of time and effort doing lots of research with the audience to kind of make sure it was the best product it could be.
But it had been nine years since the last big sport website refreshed. 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. 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 in and suggest a change to the website had to bear that mind.
That person was me who had to go in next. I'll explain a little bit 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 workflow bugs and issues, be mindful that's what they do now.
So if you change something, it's going 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 text commentary just to help them understand how people use their products and just kind of start to 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? Yep. Does anybody find their backlogs are really unsexy? Really unsexy stuff with changing operating systems and new devices coming out and changing UX requirements. There's quite a lot of stuff involved in just keeping an app alive and keeping it growing.
I saw a lot of this when I was in New York in February. I went to the North American Toy Fair in New York, and it seemed that most toys come with an app now. So whether it was a dressing up set with an app that helps you record your story, whether it was at a virtual reality coloring book.
And I could really see companies struggling with the fact that when you give birth to digital products, you've got to look after it. You've got to love it. You've to spend time and effort on it. So they were loving the fact that by having these digital add ons to their products, they could start to see how long their products were being used for and actually would extend the life of their products.
Long after the money had been spent on that box of stuff, you've got a product, you've got support, you've got to keep that app alive, and people were really struggling with that. And I think that unsexy backlog, I could kind of hide it in the corner and go, Yeah, we've got this stuff to do in our products.
But I don't. I use it and 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 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 forget that other people don't. 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. We decided really early on that we wanted to build the app on the iPlayer codebase because it's a really solid codebase. It's been around for years.
Millions of people use it, and it's also going be a really quick way to get to market as well. That meant that the feature set for the MVP was going to be fairly fixed, so we knew what was going to be in it.
And helping stakeholders understand that was really important, just to say, we can't put that much extra stuff in. Know, iPlayer has got certain capabilities and features. We want 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 impacts a lot of the front page. It impacted how search works, impacted how downloads work.
We had to help them understand why things were the way they are. But we also had some fun stuff we could do with, so we built an avatar system. We spent a lot of time about what the right avatars would be for products that had to serve naught to twelve 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 about the sport website. So yeah, I was the person who had to go back in and say, We're going to change it again.
And that started in twenty thirteen, but we wanted 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 homepage. This was in twenty thirteen. It was massive.
It just went on forever. Know, it's a 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. I wanted to make sure that conversation about what to get rid of, what to 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 a really simple heat map 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 the stuff at the bottom.
And it just made that conversation about getting rid of stuff so much easier because it was based on data, and it was just a really good 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 somebody's in development, that's what I think it means. If you work in television, it's a fuzzy front end of having ideas and brainstorms completely different.
So if someone says to me, Teletubbies is in development, depending on who is saying that could be two completely different things. Understand the language of your world and your stakeholders' world and your clients' and your 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. The 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 going to do a big change.
It was going to take a while. We were going to develop iteratively. Was thinking about how I explained the concept iterative development to senior stakeholders. Examples help. So I use this one. It's a story. It's probably a an urban 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 hundred 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 kind of 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 going to 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 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 won't notice. I used that example once, and was then told, Yeah, I think we prefer iterative development.
Just great job done. It works. Another one I use a lot is shopping centers. I love a shopping center. I have used this to talk about platforms, about how you develop platform approaches. My current use for it is thinking about Onward Journeys. So we have a number of things that people come to us for in huge numbers, like that Danger Mouse game, like things involving news rounds or Blue Peter.
So I'm thinking about how do we use those experiences to drive people to other content that they might not necessarily find? And I started thinking about shopping centers and started thinking, well, you don't build a shopping center unless you've a John Lewis or a Marks and Spencer's. So what are our John Lewis's?
How do we make them better? How do we make them do the best job for us? So yeah, it's a good thing to do with creative people as well, thinking about analogies. I love a shopping centre. My two favourite 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. 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 them the book.
Just getting people bought into why we do anything is really helpful. I now know when I go to meetings, people know I'm going to ask it so they can 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 kind of 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 and interest in the tech, and used them to help me as well.
See yous, doesn't sound very nice, does it? I worked with them. An example was when I worked on the WAP site. Remember WAP? Eggs 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.
They took their content from the body of the story. They didn't include things like the text box. So in this story, on the website, you'd find out that Vancouver was the best place to live, but you wouldn't know Melbourne was number two or Vienna was number three.
The journalists in the newsroom didn't know this, and I had to try and find a way to help them become aware of this because I couldn't sit in newsroom and remind them each time, and also couldn't get the changes made to CMS to incorporate this stuff anyway.
So we got them mobile phones, we got the guys who had that six o'clock 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. They also got them 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 is to get out of it as well and staying close to your peers, coming to events like this.
Being a product manager in an organisation where it's not native, you've got to be at the top of your game. Think 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 organisation 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 getting out of the 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, you know what, I don't understand this stuff. Will you help me? Will you answer the questions I've got? Will you come to 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, where you didn't know this stuff either, bearing that in mind, think about the time that you thought agile was something that happened when you went to yoga.
The time when you thought confluence was something you got from eating too many beans. It's really important. So I think building product culture in non digital organisations 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 some of the ways that we try to approach it and how we're trying to help BBC build its digital future. Thank you.