The Product Experience

What companies get wrong about product discovery - Frances Ibe (SVP of Product, Tide)

• Mind the Product

Share episode

Listen to our conversation with Frances Ibe, the SVP of Product at Tide. Frances shares invaluable insights on her journey from developer to product leadership and how to avoid common pitfalls during the discovery process.

Featured Links: Follow Frances on LinkedIn | Tide | 'Six things we learned at the Pendomonium and #mtpcon roadshow - London 2024' feature by Louron Pratt

Our Hosts
Lily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She’s worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.

Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.

Speaker 1:

Hello and welcome to this week's Product Experience Podcast. Today we're going to be talking to Francis Ebay, svp of Product at Tide. We talked about product discovery, how people get it wrong and some really great practical tips to get it right. The Product Experience Podcast is brought to you by Mind, the Product part of the Pendo family. Every week we talk to inspiring product people from around the globe.

Speaker 2:

Visit mindtheproductcom to catch up on past episodes and discover free resources to help you with your product practice. Learn about Mind, the Product's conferences and their great training opportunities.

Speaker 1:

Create a free account to get product inspiration delivered weekly to your inbox. Mind, the Product supports over 200 product type meetups from New York to Barcelona. There's probably one near you.

Speaker 2:

Frances, thank you so much for joining us live in person in London. Yeah, it's amazing. So people here at the conference have seen you, they've heard you talk already. They know who you are. People in our podcast audience, don't? So can you just give us a quick introduction? What are you, what's your job these days and how did you get into product in the first place? Yeah, sure.

Speaker 3:

So I work at Tide. My role is quite a broad role. I am chief experience officer, ultimately. So I'm looking at how to evolve Tide to have more connected, better experiences for our members. Fantastic. And how did you get into product in the first place? So I used to be a developer and then I fell into. I got headhunted into product. I had no idea what it was. It was called product solution managers at that point in time and really they just wanted people that could code as well. So, yes, I used to code and do product-y decisions at the same time.

Speaker 2:

And we were talking before we started the camera's going and you said one of the things that frustrates you the most and mistakes that you see people making the most is they're not good at discovery, and what I hear from most people is the complaint that they don't have enough time for discovery. The business doesn't let them do it. But you came at it from a different perspective.

Speaker 3:

Yeah, so I think it's so. Sometimes a business doesn't, but that's typically because they've done discovery before and it's taken too long. So then they go. Can you just get on and do some stuff? So the opportunity is how can you own discovery so it doesn't get taken away from you? And that's what I'm passionate about.

Speaker 3:

I think most people overcomplicate it. I see a lot of organizations or PMs that talk about discovery on a quarterly basis. I see a lot of organizations or PMs that talk about discovery on a quarterly basis. I'm going to discover something for a quarter, rather than really applying the agility that you would with delivery of every sprint. What can I learn? That's going to help me to have a better understanding of the risks around the product. That will increase the confidence in the product bets we're making, because ultimately we're making bets. None of us can fully predict what's going to happen when we productionize what we, what we build. So, yeah, way too much complication. It ends up being so slow and then, at the same time, it doesn't come out with necessarily clear, a clearer understanding of what needs to be done, and hence why most companies don't want people to do discovery done and hence why most companies don't want people to do discovery.

Speaker 1:

How do you like to sort of set up your teams for embedding discovery like more in their processes and also, I guess, in their just day-to-day thinking?

Speaker 3:

so, I believe in this dual track agile way of working.

Speaker 3:

I think, ultimately for teams that aren't used to working that way, they do need to get good at just consistent delivery because you do need to free up time. So if you, as a PM, are having to micromanage the delivery approach because you haven't worked on your daily connections with a team, setting up your tools, so, for example, jira, I'm like that should be the source of truth for all conversation, not Slack all these other things, so you could just reference it. All these other things Do you have to free up some time or you're not going to be able to do it. And then, in the dual track approach of discovery, really being very intentional on what is it that I'm trying to answer in this sprint, like, what is that goal? And then asking the next question what is the quickest way that I can get to an answer to that goal? That will help me to understand whether I need to invest further in discovery. I can move it to delivery or I should pivot or kill what I'm doing so.

Speaker 2:

I'm going to be facetious here. That's always going out and talking to 20 customers, right? No?

Speaker 3:

and this is why I stress that it needs to be the quickest way to answer questions. So if, for example, your question, your initial question, might be I just don't actually understand the insights. I don't have a good enough understanding of the problem. Is that I'm trying to solve and that is my focus. Sit with the insights. I don't have a good enough understanding of the problem. It is that I'm trying to solve, and that is my focus. Sit with the data, if that's what the team needs to do. Sit with the data with your designer, with your engineers, so that you all have the same basis of understanding, because that's again the important part. You're trying to reduce the time to delivery, so bring the relevant people together and work through that. It might be that actually, what you want to do is a data prototype, because you're at that point. Figure out how to do that data prototype. It might be that actually, what you need to do to understand what's needed is to manually do the work rather than actually build. There are lots of options.

Speaker 3:

I think the challenge is everyone thinks it's talking to users. It's talking to lots of options. I think the challenge is everyone thinks it's talking to users. It's talking to lots of users. Again, the more confident you get with it, you start seeing trends very quickly, and it's always either just doing this quant technique, that's it. So when I talk to teams, I really go. If you understand what it is hence the sprint goal, what you're trying to understand in this period then really ask yourself collectively what's the quickest way that's going to enable us to have an answer to that. And you don't have to have the full answer, but some answer that enables you to move forward, and I think that's the goal. Like, how can I be progressively moving forward and not be stuck into which I'm sure you've heard before just this cycle of just continuous discovery with no way coming out and no answers and no delivery?

Speaker 1:

So you mentioned something there, a data prototype. That's not actually a term I'm familiar with. What does that involve?

Speaker 3:

Yeah, so it can come in a few different ways. It might be that you already had an old prototype that just looked at the UI and UX and what you've now done is taken sample data and that pushed through, but you haven't had to worry about the full data science or having the full answer in terms of data, but you've gone for this small persona of people. We've already gone this might be some of the data that they might want exposure to and then exposing it that way, and so that's what I meant. There's different ways to do data prototypes. That's an example, but ultimately go.

Speaker 3:

My desire is to answer data questions. So I know in a past organization I was building a global product that was around career data and actually spent a lot of time just working with analysts to just go we're going to look at data in Excel and we're going to pull it through to say, actually, where do we have confidence in this data? And then took that data to not create the actual website but to create emails with the data to the users. That helped us to validate whether that data was valuable and if it was accurate enough to drive engagement. So it's those sort of things where it's like I'm trying to answer a data question. How can I answer it without having to build the whole data funnel and have all the data in place?

Speaker 2:

You used a word there that I really like. You talked about confidence to move forward. How do you instill this in other teams? You know people always say I need to do discovery. They don't know what enough discovery is. I've got a friend, monica, who talks about our job as product people is to help people to make better decisions faster.

Speaker 3:

Yeah.

Speaker 2:

But how do you know when you have enough information to make the decision and give people confidence to say, yep, do something with this, yeah.

Speaker 3:

So part of it is starting with a hypothesis. So, again, an immature team is going to come up with a hypothesis. I'm comfortable with the fact that that hypothesis probably is not going to be the right one, right, but you start, you have a starting point. So I think it's an emphasis, a bias for action and actually starting somewhere and doing something. Through the activity of just doing, you will gain confidence because you will either go that hypothesis was completely off and we need to rethink our hypothesis and potentially rethink our solution, or you can say there's something in that and we just need to rethink or adapt the hypothesis slightly in order for it to to be more relevant.

Speaker 3:

Confidence isn't like a scientific, perfectly formed thing, but you do know when you're like here's the risks. Again, it's a risk part. So you've looked at different risks. You've asked yourself against those risks, what are the ones that you are the most uncomfortable with? So again, I also say to teams you can look at the risk, you can score the risks and go. I'm going to tackle the most riskiest assumptions in this so that I can get to a higher confidence in that. So I feel like I've covered a lot of different things in that.

Speaker 3:

But there's lots of aspects to the confidence. And then again it's how do you expose it so I can expose it to a small set of people, learn some more. That improves my confidence. I might need to expose it to more people to increase the confidence, but it's that I'm incrementally doing things to just gain that confidence. Bringing people on journey is essential. Hence you bring your stakeholders and it's essential you bring a team through that process and you're sharing the learnings so that they can also challenge your assumptions. And I think that's the problem. There's a lot of discovery is about validating. I actually think discovery is about invalidating and it's about cutting through the noise, because there's a lot of noise in product.

Speaker 1:

And I think, as much as we want to feel like we're really good at not having any assumptions, we literally do have some. So having people in the room who can help to challenge those and point those out is so helpful. How do you encourage your teams to share those insights across the business? Do you have a playbook, if you like, for doing that?

Speaker 3:

well, yeah, so I kind of simplify this in the agile ways of working. So what? The additional thing I've noticed is people go oh, why do I join a daily stand-up? Or why do I join a retro or a product review? There's no value in it. There's no value because the right conversations are not being had.

Speaker 3:

If we're having more candid, relevant conversations and we come into it to say we're all here to bring different perspectives, to challenge and pull apart and see if it still holds true, that's going to be an interesting meeting to join. So for me, it's about structuring sprint views in a way that you're actually starting with. Here's the outcome and that we're targeting for holistically. So it might be, might be okay. Our objective, whatever that is, however your company defines it here was our sprint goal and how we thought that's going to contribute towards that. And then here's the things that we did and what we learned from it and what we're planning to do next. And giving an opportunity for conversation in it and in that people one get the context so they can actually contribute and two, hopefully you have to tease people for it. You start getting to good types of conversation over time. But it's building that culture of storytelling giving the context, but also transparency and allowing people to feel like they can ask any questions, whether it feels stupid or not.

Speaker 2:

I tend to find that teams, no matter how well intentioned, when they use the same structure over and over and over, it gets stale after a while. What are some things that teams can do to make sure that they're keeping to the spirit of that, even if they sometimes change the structure?

Speaker 3:

So I like to do stuff like, for example, you built something, you've had a goal, why don't you get your stakeholder to come to call and actually just use this solution right there and then? Isn't that the best way to learn to observe someone that had no lead up. Or because I see teams sometimes go do step one and you're supposed to do this and this and this and this, and they're kind of like hand holding them but just giving them the raw products and seeing can they actually achieve the goal and what are they asking and how is their face changing in that? Or even bringing customers into it. We've done that before where we've brought actual customers into a sprint review and that's been something that teams have enjoyed, because they see the customer engaging with what was just built and being able to give like real, candid feedback that can be addressed in the next sprint, rather than waiting multiple weeks to get that feedback. So that's that's another way.

Speaker 3:

But I do think, as a product manager, that is one of the challenges, like how do you keep these conversations to be meaningful and interesting for people? And, as with everything, it's a process. It's about iterating, getting feedback and just trying different things. Some will work, some won't. Um, some people will be more engaged, some people won't. It's just, it's a part and parcel of how to bring people on on the journey this episode is brought to you by pendo, the only all-in-one product experience platform do you find yourself bouncing around multiple tools to uncover what's happening inside your product?

Speaker 2:

In one simple platform. Pendo makes it easy to both answer critical questions about how users engage with your product and take action.

Speaker 1:

First, Pendo is built around product analytics, enabling you to deeply understand user behavior so you can make strategic optimizations.

Speaker 2:

Next, Pendo lets you deploy in-app guides that lead users through the actions that matter most. Then Pendo integrates user feedback so you can capture and analyze how people feel and what people want, and a new thing in Pendo session replays a very cool way to experience your users' actual experiences.

Speaker 1:

There's a good reason over 10,000 companies use it today experiences.

Speaker 2:

There's a good reason. Over 10 000 companies use it today.

Speaker 1:

Visit pendoio slash podcast to create your free pendo account today and try it yourself want to take your product led know-how a step further, check out pendo and mine, the products lineup of free certification courses led by product experts and designed to help you grow and advance in your career learn more today at pendoio slash podcast.

Speaker 1:

One of the things that Teresa Torres talks about is, you know, always talking to customers, and you mentioned about kind of making sure that you are doing discovery based around the particular goal for the sprint. Do you make time for more sort of free discovery, if you like, more just unstructured conversation and investigation?

Speaker 3:

Yeah, so, the way that I structure discovery is in part, so in the engagement with customers. We're also just trying to discover more about customers. So I will typically start with unstructured type conversations. Initially I start seeing what are some of the themes that they talk about and the things that they're covering that might not be related to what I want to discover on, because this is an opportunity to talk to a customer, not be related to what I want to discover on, because this is an opportunity to talk to a customer. So don't waste it with. I'm going to do 15 minutes or 20 minutes just to cover what I'm interested in. So always encourage that.

Speaker 3:

I want to say to team if there, if there's a longer discovery session, build in the ability to observe them using your existing product or observe them using a competitive product or actually observe them doing something in their workplace. That also gives you context. I think observation is such a powerful part of it and not necessarily what people say and then typically you'll see either naturally leads into some of the things that you want to cover. It may not, but then you can start going into like the more structured we want to cover these sort of areas Ideally you're not like leading them for it, but you're structuring it in a way that it makes sense and that's how I always approach it. So they build up a knowledge base of just your customers, what they care about, observations, as well as validating or invalidating that specific thing that you want to do. So that's what I encourage teams to do. Some people feel like it's overhead, but I feel like it's a missed opportunity not to just learn other things.

Speaker 2:

One of the other challenges I find is teams, not just teams, product managers as well. They focus on the problem at hand that they've been asked to work on. Their perspective really narrows down to this is the most important thing in the world, because it's what we are doing and therefore we have to solve this. How do you make sure that the product manager, the team and the stakeholders as well maintain the context of what it is you're trying to do, why and how relatively important what part of the journey it's in, what part of the customer lifecycle it's in?

Speaker 3:

So I always encourage, when it's in the problem space, actually do the saving, the solution as well, but start with a divergent view. So whatever's presented, fine, that's great, but spend time brainstorming like what are the alternatives, what are the problems, how does it all connect all all of those pieces so that you do have an opportunity to converge on the right things? If it's a stakeholder and they're really passionate about it, again find a quick way just to validate that, but don't make that just the only thing you're doing.

Speaker 1:

ultimately is my answer and I find sometimes the you know the data goes a certain way and throws all plans out the window because I don't know conversion rates dropped or revenues dropped or whatever it is, and then you kind of have to almost like pick up a different set of discovery because you need to understand like, why has this happened, what's going on, how, how do you have? I guess if you have like a really great process for discovery, then it's really easy to then just respond in that situation and that's why I think it's important to have that sprint approach, because you have an opportunity to say do we continue, then what?

Speaker 3:

you actually be surprised. There'll be some time where you go we can stop because we've done enough, that we thought we needed to do more, but actually where we've got to, sufficient and we can move on to something. That tackling another, an area I think the other part is I call it like portfolio management of how you invest your time. Sometimes some things will be more strategic and actually a short-term metric change shouldn't deter your ability to still be working out the strategic. So how do you allocate your time so that it isn't all just tactical responding but you're also still maintaining a strategic view of where we need to?

Speaker 2:

go to. So, francis, we talked a lot about how people get to a point of discovery and what the optimum thing is to allow you to make a decision, but is that really the end of it, when you've made a decision?

Speaker 3:

No, it's not typically the end.

Speaker 3:

So I think one of the other than discovery should be your superpower as a PM.

Speaker 3:

Storytelling is really important and I see that that's an area that's really challenging. So I might have a PM that is actually doing the right discovery and I ask them a set of questions but the response does not add up to a story that's compelling or clear. So it will be keen to go back and really work on that story, because it should be something that is clear enough for anyone to pick up and really understand why you decided to do what you're doing, how did you approach this and how did you get to that conclusion and what we think we'll get out of it. And so I do encourage I've done the past like taking storytelling courses and really looking at your content to be like it should have a beginning, middle and end and it should be clear like the why around all of it, so that people go, yes, of course we should do that, rather than they have to be part of your team to understand the context of why you even did what you did.

Speaker 1:

I think that's such an important point and it's almost like irrelevant how good your insights are if you can't present them in a way which makes sense to the people that need to understand them Exactly. How do you get people to practice that as well, like on a very practical level of you know? Your PM has, you know, uncovered some something interesting, like how do you get them to practice presenting in different ways or refining their storytelling?

Speaker 3:

yeah. So in the past I've done different things it might use. So we've had, for example, I had one team that would do regular monday meetings as a pm group and I'd get a pm to come and present their content so they get active feedback. That's a great way Because other product people typically like. If the product group doesn't get it, then that's obviously an issue. But giving opportunities so that people can present it, I also typically would create like stakeholder groups, so it doesn't have to be perfect.

Speaker 3:

This is the other thing. It does not have to be perfect. If you've got a stakeholder group that you have built a level of trust in and they have trust in you, you can show these things early and see how they respond to it. I think it's just having a clear structure. So, with a leader, ask them questions so that you can build more clarity in it. That's why they're there to coach you as well. So I do think there's lots of feedback. As with everything, I know I'm sounding really repetitive, but just iterate. It's iterate, learn and improve. It's okay to fail. It's okay if it's not perfect and hopefully you're in an environment that makes you feel it's okay to not be perfect as well.

Speaker 2:

I wanted to ask you about repetition. Actually, you're in a leadership role. You've got a bunch of people on the team. You want to make sure that the stories they're telling are somewhat consistent and add up to, towards the bigger story, the epic or saga that you're trying to tell. How often do you have to keep repeating this story? How do you ensure that everyone stays on the same page?

Speaker 3:

Oh, that's the biggest challenge and I think that's the biggest challenge. That's one of the biggest challenges as a leader to help people to stay on board, because people forget. It's actually very funny how you can have a public protection and then someone forgets completely. Um. So I think there's different mechanisms. It's like how do you organize your team? So in the past I forgot, for example, if the challenge has been, our experiences for a specific persona doesn't fit together end to end. I might organize a group that they are persona focused groups, storytelling. That's going to enable me to say how has that persona's experience evolved as an example, or it might be a specific product offering and then how you organize those groups and to tell that. But the simple answer is just keep repeating until someone says to you stop. That's probably the best thing to do, but it's hard and that is one of the biggest challenges, I think, in product.

Speaker 1:

Yeah, I agree, I've been telling you my story, but I agree. So in discovery we, you know, we often talk about the research, interviews and data analysis and surveying and things like that. Obviously, there's like so many skills to build there as a PM, if you're leading on all of these things, or if you're, you know, you might have the advantage of having a UX researcher on the team or a data analyst on the team, but you still need to be able to speak their language and and really understand how to ask the right questions, how to work with them. What are the kind of like? I guess what's the best advice that you would give to a PM? To work well in these different disciplines and to evolve their own skills so that they really understand what good looks like from these different sort of research function.

Speaker 3:

Yeah, so one of the things I would say is hopefully you're working in at least a triad, so it's not just you. So I actually think, the accountability and responsibilities of the triad. You each have different role and skills and roles in this, but it's the collective effort. So I'd say that and through that you learn. So if your product designer is really good at running user research sessions, let them run it. You do not have to lead on everything. Learn from them by observing and joining the sessions and then you can step in and do some parts. A data prototype, for example, that we mentioned before.

Speaker 3:

Not all PMs are really strong in that area, so it is okay to say to to someone else. I'd love for you to lead on it. I mean, the other part that I should have said initially is when the problem and the outcome is clear enough and you've got to the essence of what the value is that you're trying to to drive that it's actually easy to get all these groups to align and to get to where it's needed. But when it isn't, that's where you'll see different people going different directions and it gets all really confusing and you feel like you have to take on the full burden. So if you spend enough time in giving that solid context and hopefully you have great people in your squad and around you you will see a difference and you'll see how they'll collaborate and engage differently and francis.

Speaker 1:

This has been such a great conversation. Thank you so much. I just have one more question for you. So what advice have you had in your product career which has really shifted your perspective? Um, as a product person, what has been like, you know, game changing and really making you understand what product is about?

Speaker 3:

yeah, um. So I'm going to give two early on. When I started, look at your data daily and I think a lot of people don't do that anymore for lots of different reasons. So how do you fill up time to do that? And then I think the um second one is just the bias for action and just having that iterative mindset and being able to just challenge yourself, challenge your own assumptions. So I think I've given more than one, but More advice is always welcome.

Speaker 2:

Thank you so much.

Speaker 3:

Frances, this has been great. No, the pleasure. Thank you.

Speaker 2:

The Product Experience hosts are me, Lily Smith, host by night and chief product officer by day and me Randy Silver also host by night, and I spend my days working with product and leadership teams, helping their teams to do amazing work.

Speaker 1:

Luran Pratt is our producer and Luke Smith is our editor.

Speaker 2:

And our theme music is from product community legend Arnie Kittler's band Pow no-transcript.