Building powerful products starts with building brilliant product teams. And when you are growing rapidly and need to move at pace, that’s not an easy feat.
Not only do you need to hire A-players, get them onboarded, communicate the vision, define your team structures, and implement the right processes and systems, you need to do it all whilst making sure delivery stays consistent, and without sacrificing the culture you’ve worked so hard to build. Not to mention keeping the board on board throughout the journey…
I was lucky enough to spend some time chatting with Melanie McKay, Head of Product at notonthehighstreet, and Léa Samrani, Lead Product Manager at Uptime chatting about the challenges of scaling product teams, looking at some of the battles they’ve won and lessons they’ve learned along the way.
Watch the full 40m replay video below, or scroll to read the transcript.
Meet our panellists
Glen Duncan | Operations Director, 383 & Iris
With almost two decades of commercial operations experience across print, broadcast and ad tech, Glen’s background includes Virgin Media, The Financial Times and The Guardian. He grew the global operations function at high growth start-up Unruly before landing at digital product studio 383, where he has been responsible for creating a more scalable business and developing our talent program. Now leading our sister brand, Iris, Glen is building a product talent consultancy to help businesses reshape the way they hire forever.
Melanie McKay | Head of Product, notonthehighstreet
Melanie stumbled into the world of product management in 2005 after graduating from university. Over her 17 year career includes Transport for London, Rightmove, and now notonthehighstreet. Melanie enjoys working with her team to understand users and spot new opportunities and problems to solve. A key thing she has found throughout her career is that one of the most important, but undervalued, things product management can bring to the party is common sense and logic.
Léa Samrani | Product Lead, Uptime
Léa has been building digital products for a decade. She is currently Lead Product Manager at Uptime and a start-up product consultant. Uptime is a next-generation ed-tech app that presents five-minute knowledge hacks from the world’s best books, courses, documentaries and podcasts, to empower people to gain easy access to the world’s best ideas and thrive in a fast-changing world. Previously she was part of the product team behind Bumble & Badoo dating apps, used by over 500 million people all over the world, and headed the product & design team at CharityJob, building the leading career hub and social network for the non-for-profit sector.
Transcript
Glen Duncan: Hi everybody. Morning. Welcome to Byte. This is the latest in our series of events diving into the world of digital product. Thank you so much for joining us today. I am Glen. I’m going to be your host and I’m the co-founder of IRIS which is a product talent acquisition consultancy within 383 Project.
And today our theme is scaling product teams. Listen, if you’re anything like us you’ll know that when you’re building powerful products, everything starts with building extraordinary product teams. But when you’re growing rapidly and you need to move at pace, that’s not always an easy feat to achieve.
Not only have you got to hire in A-players, you’ve got to get them onboarded, you’ve got to communicate the vision, define your team structures, have the right systems and processes implemented. And you’ve gotta do all of that whilst making sure delivery stays consistent, and that’s without sacrificing the culture that you’ve worked really hard to build. Not to mention keeping the board on board throughout the entire journey.
I’m really thrilled to be joined by two awesome product specialists for today’s session, ready to share some of their challenges that they’ve faced and the lessons that they’ve learned from establishing, growing, and managing product teams.
Please join me in giving a very warm welcome to our panelists. First up we have Melanie McKay. Melanie is currently Head of Product at the online retailer notonthehighstreet and has previously worked at Rightmove and Transport for London.
Morning, Melanie. Thank you for joining us today.
Melanie Mckay: Morning. Nice to be here. Thank you for having me
Glen Duncan: Great stuff. And we’ve also got Léa Samani who is the Lead Product Manager at Uptime, which is an innovative learning app which was awarded one of the best Android apps of 2021. Léa’s experience includes roles at Badoo, Bumble and not-for-profit job board, Charity Jobs.
So morning Léa. How are you doing?
Léa: Good morning. Good. Glad to be here.
Glen: Great. Listen, we were also due to have Sophia Sulaman join us from SolutionPath, but unfortunately she’s had to drop out because of a family issue. Hopefully she’ll be able to join us for future edition of Byte.
It’s time to get started and hear from Melanie and Léa. Let’s start with this theme first then. What does a successful product team actually look like? Melanie, I’m going to come to you first, if that’s okay. In your opinion, what are some of the characteristics and behaviours that make a high-performing product team?
Melanie: Yes, this is interesting. I mean, I think I’d say it’s probably not that different to generally high performing teams in the first instance, in what I say, in terms of clear roles and responsibilities, effective processes that the team are actually bought into, strong relationships, good communication, common purpose. Those types of things that you would expect for a high performing team. Actually, some of the things you touched on in your intro actually.
But of course, with a product view. I’ve worked in product for a long time and every company I go into has a different view of product and a different way of working. But making sure that everybody that’s brought in is properly brought on board is key.
So, does everybody understand everyone’s role? Lots of teams do that initial forming part, say, at the beginning of setting something up. But then when you’re three, four, five years in, not re-doing that and bringing people in is where I think you can fall apart. Because you start to create these great processes, you create these great relationships, and then the world changes, or someone new joins, and not bringing them along, I think, can cause quite a challenge.
And I think as a product team, it’s really easy to focus on the product – sounds obvious – and the relationships with people like stakeholders. But actually, it’s really important to look at the product function with the same care. Maybe even treat yourself as a team the way you would treat your product. So, what are our problems? What are our opportunities? What’s working? What’s not working? What challenges do we have? I think taking the time to actually form together. And teams that do that, in my opinion, have got the best, they’re performing in the best way.
And it sounds obvious, but it’s really easy to get caught in that day-to-day company goals, objectives, strategy, delivery, and not take the time to check in with each other. Often you see product people will be really focused on their own product, and won’t necessarily understand exactly how what they’re doing is impacting what’s happening elsewhere.
You’ll have things like updates and people will just sit there, and they’re not really listening to what someone else is saying. And then actually taking a step back to go, hold on. We’re actually solving really similar problems in our products here, but we’re not talking to each other. It’s that, taking that time out.
It’s even the things like personal – if I, anyone that I manage, I want to have two sets of meetings with them. There’s one set where we’re talking about their product and what they’re delivering and what’s going on, and there’s one we’re talking about them specifically and their personal development.
And I think it’s the same from a product perspective. As in, yes, it’s great to know, what’s going on with stakeholders? What does the roadmap look like? But actually, how are we working together is also really key.
And then obviously the things like – I guess this is a bit standard, but research- and data-led, put your user at the heart of the strategy, strong relationship with stakeholders.
But I think it’s really remembering that the team itself is important as a function. If that makes sense?
Glen: Great answer. And Léa in your experience, has that been mirrored? Melanie made a good point there around bringing people along. Do you prescribe to that as well?
Léa: Yeah, absolutely. I think especially in the startup environment, none of that just happens naturally. You have to take the time to set it up properly.
And that means actually taking the time to understand the different ways of working of people, the preferences, the systems, the tools. And all of that together comes together and creates a culture. And as you grow and you bring new people in, you have, they have to buy into that as well.
But this is something that you actually have to actively do. You can’t just let it happen. You need to take your time to talk about it, to review it as well on a regular basis. And it’s just, it’s not that simple. You’d think it would be, but actually it does take a fair amount of time to find something that really works and is the best the best approach for your specific team and your specific company.
And I think one of the, maybe, the mistakes companies do, or some of the issues we have, is that there’s a lot of methodology out there. And you see people just being, okay, let’s just do Scrum, or let’s just set up this methodology, and we’re just going to do it by the book. And it doesn’t really work for many startups. It just doesn’t. You have to adjust it to your people and your team. Taking the time to do that is very important in my opinion.
Glen: And I suppose Léa, for you, you’ve pretty much been doing this from scratch, because you’re in a role at a relatively young company established in 2019.
How are you approaching establishing and building a product team at Uptime? Are there different behaviours required in a scaleup environment compared to some of your past experience at much larger organisations?
Léa: Yeah, absolutely. It’s very different. In a large organisation, you have ways of doing things that are fairly established. And when you have new joiner, they join to the organisation’s way of doing things, and you ensure that this stays aligned. But it’s kind of like a setup. Whether in a startup, a new organisation, in smaller organisations, things are created from zero. So every new joiner have a huge addition and can change anything.
It’s not something that’s set in stone, which means that it’s constantly changing. It’s constantly evolving with the size of the company, as well, the size of the product, the size of the team. The way we would approach that in a startup is with a very big open mind and the constant review of how we are doing things.
If I give you an example, in the last couple years, I think the way we approach product has changed maybe four or five times, and it has changed for the better every time. It’s a lot more flexible, I would say, in the startup environment.
Glen: Let’s talk about the influence of product in general, because I guess, it certainly feels like this in the last 18 months, it feels like product is the latest buzzword in and amongst the C-suite. You know, the big new thing that’s going to change the way we all do business. Go back a little bit further, it was digital and all the energy behind that, before that, design thinking.
But there’s often still a lack of comprehension about what being product-focused really means. Melanie, I noticed you were smiling there, so I’ll come to you for that one. Is that something that you’ve experienced? How do you go about educating internal stakeholders, who might be non-tech focused, on what a product-led approach really means for the business?
Melanie: I’m smiling because I think it’s, you’re right. It’s definitely, it definitely seems to have taken, re-taken, back off again more recently. And it is, you do hear it bandied around a bit. I think the interesting thing – well, I suppose I should say, while we have a product function at notonthehighstreet and have done for a long time, actually, we’re still, we are now, having been there six months, really going, what does it mean to be product-led? We, we’re kind of, like you say, it’s buzzwordy, let’s be product-led. What does that actually mean? And I think one of the things that’s been interesting is establishing what do other people think it means first?
So, rather than just going in and being like, right, well, product-led means this, going, what do you think it means? So I can establish, like you would with any product, what’s the as-is situation? What’s your current understanding of what this is?
And then I think the other thing I’ve noticed, and it’s something I’ve actually had an epiphany about in the last couple of weeks, funnily enough, I’ve noticed that people, understandably, if you work in a business and someone comes in and says product, we’re going to be product-led now, and you have a function called product, people get nervous that that means that that team that’s called product is now going to take away everything that you’ve been doing and is going to be the sole team that is there to drive everything, as opposed to it being that the product is what’s leading the organisation. So, the users and the users of that product being what’s building your roadmap, and the product function is there to, and this is my view, I suppose, but is there to draw out from everybody what our business goals are, what our users actually need, what’s possible from technology, and therefore be able to build a roadmap.
I’ve been talking about this a lot recently, but it’s not like, say, me sitting in a room going, this is what our plan is. It’s me working with people to draw out from them what their views are, to put the product at the heart, and then have a roadmap and a strategy.
So establishing what people think it means, and finding common language, and calling things out like that. Like saying, what’s your concern? I had a meeting with somebody last week who, as we were talking, we then realized that their concern about a design sprint that was happening was that, actually, the product team already knew what they wanted to do, and it was almost lip service, and we were just running the session. And going, oh, I’m so glad I know that’s what you are worried about because I can promise you, that’s definitely not the case, but let’s work through that together.
And it was such a helpful conversation. You know, it was a 40 – it was supposed to be a five minute conversation. It was 45 minutes. But drawing out what are your concerns, and what do you think product is here for, and what do you want us to be here for? And then being able to use that language to go back and explain what product is actually, therefore.
I don’t know if that makes sense. It’s a bit waffly, my answer, but it’s because I’m in the middle of – it’s quite an interesting thing at the moment.
"As a product team, it's really easy to focus on the product - sounds obvious - and relationships with stakeholders. But actually, it's really important to look at the product function with the same care. Maybe even treat yourself as a team the way you would treat your product. So, what are our problems? What are our opportunities? What's working? What's not working? Teams that do that, in my opinion, are performing in the best way."
Melanie McKay, Head of Product, notonthehighstreet
Glen: Have you noticed that Léa in previous roles before your, the role that you’re doing for your current business the distinction between what people think product is and what it actually is there to deliver for the business?
Léa: Yeah, absolutely. One of the main things is the definition of product is very different in different minds. And you could think of the product as the actual end-user thing, whatever it is, you have – a service, an application, a website. But you could also think of product as everything within the company, how a company functions.
So you deliver, delivering your successful business, in a way, could also be a product approach. Because, I’m sorry, I don’t know how to explain that properly, but basically, your ways of working, the way of growing within the business, the internal tools as well and functionality, all of that, in a way, is product. So you have to approach it with a much more holistic approach than just the end product that the user will actually see.
And an example of that is if your product is a service, the service could be food or education or whatever it is, that service is actually way more important, in a way, than the actual tool that you end user is going to use.
But when you talk about product, you often think of the application or the website that they will use. But actually, in that case, your product is everything along the supply chain before. So the definition of the word product itself is very vague and it tends to be a bit more, too specific in people’s minds.
And I think we could benefit of just really considering it as everything is product, almost, right? Your customer service is product. How you talk to people is product. Your whole supply chain is product. Your internal tool is product. All of it is product at the end of the day.
Glen: That’s a very interesting perspective.
Let’s stay with you Léa, just briefly. Obviously your business has been growing rapidly over the last few years. How do you approach keeping the board happy and showing progress with the corporate targets, but then still keeping the product vision in focus?
Is it difficult on occasion to balance those expectations between senior stakeholders and ideally what you know is right and want to achieve on the product roadmap?
Léa: Yeah, there’s always challenge along the way. But in my experience, when you have a very strong alignment with the board and the company, usually things go really well. And that comes from setting a vision very early on, on what is it you’re trying to achieve, and where are we getting at? And then the discussion is on the how are we going to get there. And that’s usually more led by the teams and by data, by findings, et cetera, like the day-to-day side of things.
I guess, transparency is very important. Ensuring that you get support as well. So, it’s not just direction, but you can also talk about challenges, talk about anything, really, where you could get advice from senior stakeholders, from board members, people that have different experiences, is extremely useful as well.
It’s almost taking it more as an incredible support tool of very smart people that have wealth of knowledge, rather than, almost, someone you have to report to
Glen: That’s a really interesting view. Is that mirrored in your experience, Melanie?
Melanie: Sorry, in terms of thinking, of talking about people, you’re seeing the stakeholders as being, say, experts rather than…
Glen: Yeah. I’ve just literally highlighted that point from Léa there around it being perceived as a support tool of smarts. The diversity of conversation I have on this topic is actually very wide when it comes to stakeholders, so that’s a really interesting way of putting it there. Interested to hear your view on that, Melanie.
Melanie: Yeah. Well, I think I’ve always found one of the things really interesting is that people often shorthand call their stakeholders or people they’re working with ‘the business’. That happens in lots of companies where you’re like, what do ‘the business’ want? What do ‘the business’ think? And I think that that just devalues a huge amount of, a huge wealth of knowledge and understanding, by just referring – I get why it’s shorthand, I even, I do it. I don’t like it, but I still do it when I’m like, oh, you know, the people over there have said this thing.
Actually understanding that the people you are working with are experts in what they do, that our expertise is working, one of our expertise, is working with experts. Actually understanding that you’ve got subject matter experts around you, who do whatever they’re doing day-in, day-out.
And actually, their knowledge is going, they’re going to have more knowledge than you in an area, and that’s okay. You don’t have to be an expert in what they do. They do. And then you work with them to understand what they’re trying, trying to achieve. I think it’s, I think it’s important to, I don’t know, build respect and trust between you and your stakeholders by not, I guess I’d say, devaluing them, or not understanding what value they’re bringing.
"You have to take the time to set it up properly, and that means actually taking the time to understand different ways of working, preferences, the systems, the tools. All of that together comes together and creates a culture. But this is something that you actually have to actively do. You can't just let it happen. You need to take your time to talk about it, to review it as well on a regular basis."
Léa Samrani, Lead Product Manager, Uptime
Glen: Just going to stay with you briefly, Melanie, because there’s a distinction between Lea’s journey with Uptime and yours at notonthehighstreet. So, you joined an already established team and you’ve had to embed yourself as a new product lead. How have you approached that challenge?
Melanie: Interestingly for me, although the team was established and product has been here for a while, actually, a lot of the team were quite new. So it wasn’t quite the same as joining a very, very heavily established team, which I guess is a bit lucky for me. The team was in a state of change anyway, so it meant I got to join and we did a bit of the forming together.
It was staggered. So you had the person who was here the longest, then, which was less than two years, had the majority of the knowledge.
So, we’ve had this really interesting challenge in general for me, which was, it’s an established business. There are huge amounts of processes, ways of working, tools, systems that exist. But the knowledge of those within our team itself actually wasn’t there.
Having to go, okay, I’ve now got to go through and ask people a bunch of questions, some of which they’re going to have already been asked, but really like, okay, give me the ‘dummie’s guide’ to this system. Whereas often when you join an established company, there’s already somebody there who knows the products inside out, that wasn’t the case here.
But it still meant, I guess – like I said, product itself has existed in the company, just the team hadn’t. The interesting thing – I came to a talk at notonthehighstreet seven years ago, at least, from the product team. So, you know, product’s been here.
What it meant, actually, was working with the stakeholders who’ve been here through a few different iterations of product teams and not having to re-invent the wheel, or drag people into ‘let’s talk about the process of what you think we’re doing’ that they’ve already done. So, trying to establish a best practice in the here and now has been the challenge. Going, well, you’ve already seen product done in different ways as a set of people that have come together, because although we’re not established as a team, it’s a big enough team that everyone’s coming in with different experience from different companies.
So going, okay, what do we think? What we’ve spent a lot of time doing is getting our house in order as a product team. So, roles and responsibilities. Let’s talk about that. A Product Lead in one company is the same as a Head of Product in another, is the same as a Product Owner in another. You know, this endless debate about Product Owner, Product Manager, but in general, just Head of Product, Product Director, different roles mean different things in different places.
So let’s establish together what we think we’re doing, I arrived as a Head of Product, having been a Head of Product. Is your expectation of me the same as it was in my previous company? You are a Product Lead, I think this means this. What is it that you are actually doing? Let’s discuss that.
And then from that, that’s then meant we’ve done a lot of relationship building between ourselves and got our house in order. And then we’re going out now to explain it in the most simple way possible more widely of this is what we do. This is how we do it. And trying to get that balance of we’re a team you know existed, but we are changing what we are doing as a team. So let me explain it to you.
I’m lucky enough that I was a teacher previously, so I quite like trying to explain something to a very wide, diverse group of people with different understanding, different backgrounds. If you’ve stood in front of 30 children and tried to teach them how to do programming, from a kid that couldn’t care less to a kid that does more than you do at home, it makes it a bit easier to try and do it. But it’s been that – the function was there, but the team wasn’t established. It’s been a different kind of challenge, I guess.
Glen: That’s amazing. So let’s continue on this theme of growing and scaling teams, and to zero in on talent and people for a moment. If you are moving at pace, then hiring quickly is key, but obviously hiring right even more so. Melanie, for you, what are the most important things that you look for when you are recruiting new talent into your team?
Melanie: Common sense. It’s a thing that I did not realise until I was older is a skill in itself. I just assumed everybody had common sense. So my first thing is some common sense. Logic, logical thinking. Someone wanting to understand why.
Something I quite like to do in an interview is to just explain to somebody a situation and ask how they’d react to that situation. And, often where people start to go, oh, wait a minute. Why is that happening? Explain this to me again. They start to come back with questions rather than immediately answer. You can see the way someone’s approaching a problem. They’re going, oh wait, let me understand how this is working. So you can see some of that common sense and logic.
And I think a skill – I have to admit, I didn’t know this was a skill until it was called out to me as something that I can do that someone recognizes a skill. The ability for product people to work on a micro and macro level and constantly come in and out. Actually lots of people can’t do that. Again, I think if you work in it, you don’t necessarily realise that everybody can’t do the same thing as you. The ability to show, okay, well, I would do this thing and this is why, and keep going – I don’t know why I’m moving my hands around! – but keep going in and out of problems.
I always give a task in an interview and I’ve found people fall into two categories. They’ll either present to me the theory, so, actually – to Lea’s point of there’s lots of books and blogs and things out there – so, if somebody says to me, if I say here’s a problem and they come back and say, I would solve this problem by putting our stakeholders in a room together, running a session, but they don’t actually think through how they would solve it practically. They just – I can read, I can go onto the internet and read lots of different product processes. I have my own view of what they are. I don’t want someone to present back to me theory. I want someone to actually try and approach it so I can see how they do it.
There’s no wrong or right answer when you give someone a task in an interview. No one has access to any of the data, or any of the users, or any of the things. They can’t – it would be impossible in a task to know what definitely a strategy could look like. But the ability to go, I know the theory and let me talk you through what I would do, and I’m going to make some assumptions. That bravery, I guess, in an interview to go, I think this. I could be wrong, but I’m gonna be brave and take a stab. Yeah, that’s what I’m looking for when I’m building teams.
"We've spent a lot of time getting our house in order as a product team. So, roles and responsibilities. Let's talk about that. A Product Lead in one company is the same as a Head of Product in another, is the same as a Product Owner in another. Different roles mean different things in different places. So let's establish together what we think we're doing."
Melanie McKay, Head of Product, notonthehighstreet
Glen: I guess those unique interpretations are the ones that really stand out, aren’t they, when you’re screening talent?
Melanie: Yeah. I, I interviewed somebody once. I wish I – it’s awful, because I don’t remember her name. This was a long time ago! She had a task to do. It was when I was at Transport for London. She’d gone out interviewing people in tube stations. She came in with these boards of things that she’d made. It was amazing. It was such a good interview. It was brilliant. I mean, it was well beyond what I was expecting somebody to have done! She seemed to have had a lot of fun doing it, so that was also really engaging.
Because I don’t remember what her idea was – this really was a long time ago! – but it didn’t matter. I was so bought into what she was presenting to me because of the amount of time she’d spent – let me break this down, let me think about this problem, let me think, let me see if I can understand what you’re doing.
Not that I think everybody should do that in every interview, but it was amazing as an interview task.
Glen: Léa, let me come to you. Obviously hiring is one part of the equation, but you how do you, at UpTime, approach onboarding new talent to set them up for success, particularly when you’re moving so rapidly?
Léa: I wish I could say something like we have amazing documentation and everything is up to date and there’s a very clear process set up when you come in and go through, but in practice, that’s rarely the case. Whether you’re a startup or a fairly large company, I’ve never seen processes in place for onboarding that were amazing.
I think the best thing you can do is actually ensure that there’s a lot of communication going on in the early days, that the person that joined has a care forum and care access to ask any questions, to get to know the team. So, know the responsibility, know who to go to for what.
Get to know the product. It’s very important for a new joiner to actually take the time and know exactly what’s already there, and understand the technical requirements behind it, or some of legacy information, for example – things that you can’t necessarily change, or that may have consequences elsewhere, before you just start to change everything, which is usually what people like to do when they join a new company.
And then, constant support, I think, is very important. In an ideal world, yeah, you’d have also very good documentation, that’s up to date, that is all in one place, that you can give to someone so they can refer to it. I’ve never seen that, but ideally that would happen. And that’s about it.
Glen: That’s great. I guess there is a part of it which, if you hark back to the old agile manifesto of work, working software over comprehensive documentation, right? Which is, I should just be able to fit in, to some degree, and it work practically. Melanie’s jumping at the bit for a comment there!
Melanie: I just think that that can be misconstrued, that kind of view of about things over documentation. It’s no, not big, heavy requirements documentation, not don’t have any documentation so that people can’t figure out what’s been done.
There’s nothing harder than, I think, joining a company and trying to figure out why someone chose to do something six years ago, because everyone goes, well, we don’t, we don’t do documentation because that’s not in the – the manifesto tells us not to. And you’re like, but no one knows what’s happened or why. And it, it can take so long to unpick things. So I think it’s about the right documentation. That’s the key thing.
And I do think, like Léa’s saying, the up to date side of things – even just marking something as archived. It’s one of the things I’ve started to try and do now is, every so often, I just go in and mark, ‘this is an archive’, or ‘this is out of date’. Keep it so people can read it, but this is not the most recent version of whatever you are looking at.
It just makes it much easier. Yeah. Sorry!
Glen: No, nothing wrong with that response. That’s why we’re here! It’s great.
Final question and Melanie, I’ll come to you for this one and then we’ll reach out to the audience because I know there’s been some questions coming in.
As a product leader, how do you get the whole team aligned behind the product vision and driving in the same direction? I guess for you, you said you’ve almost had quite a lot of new people coming in, as well, so how have you managed to get everybody rallying behind the cause?
Melanie: Drawing pictures has been really key. Rather than just saying with words, this is what our business strategy is and this is how this breaks down, and therefore, this is what our product strategy is, it’s actually drawing that out and going, okay, so we’re trying to do this, which breaks into this.
And it’s just a simple diagram, but it’s, in the way that I’ve approached it for this particular role, it has been that, okay, let’s look at this together. Let’s figure out how, we’ve got this business strategy, we know what we’re aiming for in the next four to five years, what does that mean for our product? If we’re going to be at this stage in four to five years, how does that mean our proposition needs to change and how are we going to get there? Doing that.
Not going, I’m going to work out the product strategy over here, and then I’m going to come and tell you all, and we’re going to work out how we’re going to deliver against it, but going, let’s do that together.
So, less telling, more collaboration in the first place, and drawing. Which sounds ridiculous, but I’m very visual. If somebody just explains something to me, I’m going to be – I’m always drawing what people are saying. It’s something people can then get behind and go, okay, I see how this breaks down. I can see how this works together. So that’s been my general approach to what we’re doing.
It’s difficult because I automatically want to just start talking about our business strategy and what we’re doing, which obviously I can’t do! But I want to use that as a way to explain how we’ve aligned ourselves on it.
Also I think one of the key things for me and my role is I’m not here – it’s not top down. I’m not here to tell the Product Leads and the Product Managers what to do. I’m here to make sure there’s this space available for them to do what they need to do. They, again, they’re more of an expert in the area that they look at than I am. That’s why they look after their product domain they look at. So, it’s creating the right space, asking the right questions, challenging each other. And I see us as looking at the same problem from different angles. Therefore we can help each other more widely.
"It's very important for a new joiner to actually take the time and know exactly what's already there, and understand the technical requirements behind it, or some of legacy information, for example - things that you can't necessarily change, or that may have consequences elsewhere, before you just start to change everything, which is usually what people like to do when they join a new company."
Léa Samrani, Lead Product Manager, Uptime
Glen: That’s great. Listen, thank you both so much. Some really, really wonderful responses from, from both of you on those questions.
Let’s take this over to the audience and see if there’s any questions we can dig into here. Just bear with me a moment. We’ve got quite a number of questions here.
Here’s a great one for you. How do you approach the ‘need this now’ approach of a commercial business when that often doesn’t suit the development process for a product?
I guess we touched on this earlier with how you’ll manage the stakeholders against the product vision. Have either of you got anything to share there around the conflict with the, ‘we need this now’, versus what you know is actually right to do?
Léa: Yeah, happy to take that one. Usually the question is why? Why do you need this now? It’s very important. Either there’s a why that’s very well constructed, and it could be that there’s a reason for the business that is more important right now than what we wanted to do for the customer. Something that can open new partnerships, maybe, or new funding, something that is possibly higher level than improving user experience, but is as important.
Sometimes the why is just, because I want to, or because this competitor is doing that. That’s quite often the case – that competitor is doing that, why do we not have it? And in that case, you really have to deconstruct the reasoning, if it’s a justified why or not.
And if it is, then I think you should actually try and prioritise it and make it happen as much as possible, because you’re not here just for your own team and your own objectives, but for the business ones. So, if it is important for the business, you need to try and make it happen.
If not, there’s a lot of techniques on how to avoid doing it, like showing what you’re currently working on, make the person, help the person visualise other things that would have to give, to not be done, if you decide to do that, that kind of thing.
Glen: Melanie, do you have anything add there around the, ‘we need this now’?
Melanie: I think I’ll probably say the same thing, which is you want to understand why and what the impact of doing that thing is going to be. And for everybody to understand what happens if we don’t do it? So, there’s the what if we do do it and what’s it solving, but if we don’t do this, what’s going to happen? What impact is it going to have?
I think a lot of these things come back to the impact, and like Léa says, being able to go, well, this is what we’re doing. This is what we’re doing right now. This is what the strategy and the plan says. If we do this instead – I keep saying the word impact with lots of different meanings! – what’s the impact of doing that? We need to do this right now. What does that mean we’re going to stop doing or we’re going to change?
It’s okay to change direction. That’s fine. That’s okay. You can pivot if there’s a good reason to do it. But it’s going to depend on the reason.
Obviously you’ve got, ‘something’s broken’, or, ‘this is causing us harm right now’. That’s fine. Something needs to be done right now because it has to be done, because something’s broken, or we’re losing money because some new competitor’s come on the market who has got something that actually is meaning we’re losing customers. Whatever those things are, there are things you have to react to.
I think what Léa is saying is really key. It’s why. It’s, why is this thing there? And what’s the impact of doing and not doing it to allow you to then prioritise effectively? Because you don’t – unfortunately, none of us have secret teams in our back pockets, so it’s always a prioritisation call.
Glen: Great answers. And let me ask you another one, then, that’s come in and had quite a number of votes against it. What do your respective team structures look like at the moment, and does diversity have an impact on how you structure those teams?
Léa, I’ll come to you first if that’s okay.
Léa: Yeah, sure. The structure is, we work in squads, really. There’s multiple squads. Each of them have objectives. They have a different set of skills. So you have your engineering, your product, your analysts, design. It’s quite spread out. There’s also people from other area of the business that would be included in the squad, whether it’s learning and development, content marketing, et cetera. So it’s very – we try to avoid silos within different departments.
As per diversity and inclusion, it’s not done at product level. It’s done at company level, in terms of everything that’s put in place to ensure that hiring is done in a way that encourages diversity.
Already today, there’s quite a few things that we put in place for ensuring inclusion. The main one, I think, is that the team is actually responsible for the culture. There’s actually what we call a ‘culture club’, and it’s the people that are volunteering from every team, and they come together on a weekly basis and they decide what should be encouraged, what new policy should be done at company level.
It’s completely owned by employees from every team, at every seniority level. They basically champion that, and it’s working very well because it’s not top down at all. It’s the other way around.
Glen: That’s great. Melanie, I’ll take that one to you as well, if that’s alright.
Melanie: Yeah. I guess I’ll answer backwards, but from a diversity and inclusion perspective, similarly, it’s not done at a product level, at product team level, it’s at a company level. So we’re look, you know, we, we consider what we need to do and that’s, you know, looking at our data currently, looking at how we need to be more diverse.
We had one of the board from Rightmove do a talk at International Women’s Day when I was there, and she said, you know, look at your customer base and look at your senior management and board. Are they reflective? Are, are your senior management and board reflective of your user base? And if they’re not, then you might have a problem. Because you can’t just, if you’re trying to appeal to set a people, but you’ve only got one – not that everyone thinks the same, but that ‘group think’ is a problem.
I thought it was such a great thing to have said. It was also very interesting, because at that point we looked around the room and went, oh. Actually, maybe there is a challenge here. And that’s something that the company has addressed. It’s done at a company level.
In terms of our actual structure, we have A VP of Product who works with the exec team, then me as a Head of Product. We have some Product Leads. We have Product Managers, and we have more, I don’t really like using the job title junior, but more junior Associate Product Managers.
We’ve basically got this Venn – it’s not really a Venn diagram if it’s one, after the other is it? – but anyway, we’ve got the way that they cross over.
Of course, when you’re moving from one role to another, there are things that you’re doing that cross over. We’ve described that in a diagram – as I said, I like pictures! – of how our roles relate to each other, and done role canvases to be able to talk through what we all do.
We have more junior members of the team reporting into Leads or reporting into me as a Head of Product, depending on where they’re at in their career. They can’t really – I keep waving my arms around! It’s just a normal hierarchy, in terms of that.
Glen: The drawing aspect!
Melanie: Yeah! What’s really important, what I said before, we are all trying to solve the same problem. We’re just coming at it from different angles. So, where someone is there to unblock things, someone’s there to ideate on things, whatever those things are. The point is that we’re all trying to build towards one goal.
Glen: That’s great. I’m just gonna field you one more question, actually. There’s two questions that compliment each other quite well here, which is, how do you expand your product team as the business grows in the most efficient way? And somebody else has asked, do you use agency and freelancers, for instance, to augment your team? Interested in your perspective on that and how you grow your teams as efficiently as possible.
Léa, or Melanie I’ll come to you – whoever wants to go first is fine!
Melanie: It depends a bit on the company. It depends how the company’s growing.
You can break off down into domains when you look at a whole product and then you might go, well, actually, we’re really focusing very heavily in this area right now, and there’s just too much work for one person to do.
The way that you approach that could be, so do we have a more junior member of the team? Do we need a more junior person to work with them? Is it that we need to bring in somebody from an agency? It’s so difficult to answer because it’s so related to the situation at that point and how the company’s growing. And if suddenly you’ve got…
I don’t know if you just heard that, but there are two cats fighting right next to me! That was terrifying! It’s completely thrown me off what I was saying. I have absolutely no idea where I was in that sentence. I’m sorry. Maybe go to Léa while I check that my cats haven’t killed each other!
Glen: That’s fine! You should check they’re both alright, actually. Léa we, we will come to you just to close us out here.
Léa: I do agree. It’s so specific and it depends in companies. I don’t think there’s a general rule. There’s a few caveats that you do have to be careful with that are probably a bit of a general rule. When you start with one team, which is the source of truth, and then you start having multiple teams, that’s quite a bit of a challenging phase, where you do have to make sure you have proper methodology in place at that stage and proper documentation in place as well. That’s the first thing.
The second thing I think was about hiring freelancers and agencies. Sometimes it’s needed, but my motto is that it’s never done as good externally as it is done internally. You have people that are in the company that know every little aspect of it and what we’re trying to achieve. They tend to, I think, integrate a bit better in the long term and facilitate this growth.
But sometimes you need a very specific set of skills and you need it for a short period of time. That’s usually where an agency or freelancer comes in in a very handy manner.
It’s very specific, and I think the way the team grows and the way you look at that can change very quickly. If you, for example, launch a product and you can see one of the aspects of the product has a lot more engagement or a lot more potential than you originally thought, you might want to hire a team just for that specific part and split it. If you can afford it, as well. Depends. It’s very case by case.
Glen: That’s great. Thanks Léa. Melanie, I hope the cats are okay! We’re almost out of of time, but all that’s left is to say a huge thank you to both Melanie and Léa for taking time out their day to chat with me this morning, and to all of you in the audience for joining us and submitting your questions. I hope you’ve enjoyed watching it as much as I’ve enjoyed taking part.
Our next Byte event will be in September and we’re going to be focusing on product discovery at that one. You can follow 383 Project on LinkedIn to hear more about that Byte event and if you want to get involved as a panelist, drop us a line at hello@383project.com. We’d obviously love to hear from you if you want to take part.
Finally, you can also catch up on our past Byte events and lots more digital product thinking at the 383 blog, or you can learn a little bit more about IRIS and find lots of resources on talent and recruitment at foundbyiris.com.
And we’ll see you at the next Byte! Thank you very much.
