Product discovery is the foundation of a successful product strategy. Identifying and validating customer needs is essential if product teams are to reduce risk and build the right thing.
But when you are moving fast, how do you embed continuous discovery throughout your product lifecycle, without impacting on delivery? How do you frame discovery as a catalyst and not as a blocker, and get buy-in from the business? And with so many tools, frameworks and theories available, how do you filter through the noise to find what will work for your team and your customers?
Recently, I chatted to product leaders from WhatsApp, Productboard and Banked about the realities of continuous product discovery, the challenges and opportunities it presents, and what advice they can offer for product teams.
Watch the full 40m replay video below, or scroll to read the transcript.
Meet our panellists
Allison Busacca
Head of Discovery Product Marketing, WhatsApp
Allison Busacca is a senior product leader with 15 years experience building products and businesses that connect people with the world around them. She currently leads the PMM team for the WhatsApp Discovery Pillar, which aims to connect people and businesses on the platform.
Niyati Joshi
Product Lead, Banked
Niyati Joshi is currently Product Lead at global payments network Banked. She has ten years experience in product development, leadership, and business intelligence, with an emphasis on financial services and technology.
Michael Stencl
Director of Product Management, Productboard
Michael Stencl is an experienced product leader whose background in product management spans software development and travel and tourism. He is a graduate of Mendel University with a PhD focused on Artificial Intelligence in Economic Informatics.
Y'shira Kelly
Senior Product Manager LEGO
Y'shira Kelly is Senior Product Manager for LEGO digital consumer engagement, responsible for creating immersive and engaging customer experiences on site. Previously, she has worked in product teams at YOOX Net a Porter group and William Hill.
Hosted by Matt Vercauteren
Senior Product Manager, 383 Project
Matt Vercauteren is a product manager with nine years of experience delivering client and user value through software development and services. Most recently, he has helped product teams deliver first releases, traversing the lifecycle from concept to cash using value-driven product management techniques.
Transcript
Matt Vercauteren: Hello, everyone. Welcome to Byte. This is the latest in our series of events with Byte digging into digital products. Thank you so much for joining us today. I'm Matt, I'll be your host. I'm a Senior Product Manager with 383 Project, and today we're chatting about product discovery.
Product discovery is the foundation of a successful product strategy. Identifying and validating customer needs is essential if product teams are to reduce risk and build the right thing. When you're moving fast, how do you embed continuous discovery throughout your product lifecycle without impacting on delivery? How do you frame discovery as a catalyst and not as a blocker and get buy in from the business? And with so many tools, frameworks and theories available, how do you filter through the noise to find what will work for your team and your customers?
I'm thrilled to be joined by some wonderful product specialists in today's session, ready to share their thoughts on the realities of continuous product discovery, the challenges and opportunities it presents, and what advice they can offer for product teams.
Please join me in giving a clap in the chat, if you will, for our panellists. We'll start out by introducing Allison Busacca, who leads the product marketing team for the discovery pillar at WhatsApp, which aims to connect people and businesses on the platform. Her past roles include TripAdvisor, Instagram and the BBC. Good morning, Allison. Thanks for joining us today.
Allison Busacca: Good morning. Thank you for having me.
Matt Vercauteren: We also have Niyati Joshi, who is the Product Lead at Banked, a global payments network. Niyati brings almost ten years of experience in product across tech and financial services. Good morning, Niyati. How are you today?
Niyati Joshi: Morning. I'm very well, thank you. Thank you for having me.
Matt Vercauteren: Our next panellist is Michael Stencl, Director of Product Management at ProductBoard. His experience in software development, travel and tourism. Thank you for joining us, Michael.
Michael Stencl: Thank you. Glad to be here. Thank you for the opportunity to discuss this.
Matt Vercauteren: Always great chatting with you on these panels. All right. Also Y'shira, just in time! I was just about to introduce you.
Yshira Kelly: Hi, everyone. Thanks for having me.
Matt Vercauteren: Yshira Kelly joins us from LEGO, where she is a Senior Product Manager for digital consumer engagement. Previously she's also worked in product teams at YOOX Net-a-Porter Group and William Hill. Good morning. Welcome.
Let's get into the conversation. First up, let's start with the basics. Very important question, though. What do we mean by product discovery?
Allison, I'm going to come to you first. How do you define product discovery in your team and who owns it?
Allison Busacca: Of course. So, basic question, basic answer. We define product discovery as the process, essentially, of trying to figure out everything that we don't yet know.
We believe that everyone on the product team should be interested in the outcomes of the discovery work, but we specifically see discovery work as the job of product marketing, data science and user research. We actually call ourselves the 'understand' team. We give ourselves a cool name! Between those three departments, PMM, data science and user research, we have people who consistently do data analysis, customer research, and market and competitor analysis, which then gives us multiple angles of attacking any question that we might have.
Matt Vercauteren: That's great, thanks, Allison. Niyati, coming to you next. Does that definition also ring true for you? Are there any differences or other considerations in a start-up or scale-up environment like you find yourself in?
Niyati Joshi: I think there's a lot of overlap with what Allison said, especially some of the roles and functional domain areas that are involved in that.
For us, it's a little bit of a step further, especially from a start-up or scale-up environment, because a lot of it is around what is the problem we're trying to solve and what is the key objective we're trying to reach? But just as Allison said, it's a lot about what's the overall outcome that we're trying to achieve.
Sometimes in a start-up when you're scaling, you probably don't have all of the areas that you would have a larger organisation. A lot of it is about being very open and collaborative with the functions that you do have. For us, for instance, a lot of the discovery is between myself, product marketing. If it's more of a front-end facing tool, then we have user design coming in, but we also have customer success, because they are our first point of call with the customers and what they're experiencing. The solution architects as well. And there's the good old desk research that we also do to see what competitors are doing. So it's very collaborative and open, but very much focused on the overall objective and the problem that we're trying to solve.
Matt Vercauteren: Going to turn to you, Michael. You've got a unique viewpoint here as you're a product team that is building tools for product teams. Do you think there's enough understanding of discovery and its role outside of the product management team?
Michael Stencl: I like the comments from my colleagues because this, unlike other topics out there, I don't see that much difference between B2B and B2C because it's more tied up with how big is the team, you cooperating together. Usually with bigger teams there's a really nice, standard definition of the discovery process and clear roles. The more you go to a start-up environment and smaller teams and even individual contributors, the less authority is there.
Essentially I would say in small teams, everybody's doing everything and trying to move the thing forward. The bigger teams you have, the better structure, the more systematic approach is visible. This is also tied up with the data we see on our side as well.
Matt Vercauteren: Yshira, going to turn to you next. LEGO is a company with a long reputation for product innovation. How important do you think that product-led attitude is in building a culture of discovery?
Yshira Kelly: It's a really great question actually and I love this question because it's an easy answer for me. In short, I think very important, and here's why.
Firstly, with regards to your comment about LEGO's reputation for being innovative, this innovation culture is a work environment our leaders, our product leadership, are cultivating in order to be able to nurture unorthodox thinking and its application. So, workplaces like LEGO really foster this culture of innovation. They subscribe to the belief that innovation is not coming down from top leadership, but actually anyone from the company, any role within the organisation, can source some of these really great ideas. We know that some people are better than others when it comes to idea generation. Well, great ideas can come from just about any corner of the company at any time. At LEGO, ideas are welcome from everyone regardless of role. We also aim to test those ideas really quickly, as quickly as possible, and validate as quickly as possible.
I think that's what being product-led is all about, for me. We're guided by this potential of products. It's no longer the product manager's job to come up with the best new ideas. It's our job instead to ensure that the company and then also our team is creating the right environment for these really good ideas to flourish. Pursuing them, investing in them with the right amount of rigour is what it's all about.
At LEGO, again, coming back to the point around innovation, we've come a long way in being product-led, in breaking down these silos between the product and what is the business, and some of these barriers around whether it be PM and squad, again, breaking down that as well. It's this change in behaviour and ownership that I think is one of the most important steps in encouraging and building that culture of discovery, as you said.
Matt Vercauteren: It's great insight, thanks Yshira. The culture starts with everybody being responsible for innovation.
Okay, we've got everybody's thoughts initially on discovery here and obviously there's a delivery side of this as well. Let's talk about the relationship between discovery and delivery. Generally when we speak to clients, they know how important discovery is and they are fully sold on the value of it. However, they are also under pressure to deliver against a roadmap and there's often a friction when it comes to finding the time and space for discovery.
I'm going to come to you, Niyati, first. Is that something you've experienced? How do you approach that balance between discovery and execution at Banked?
Niyati Joshi: It's a really good question. I think friction is a really nice way of putting it. We would sometimes term it as 'healthy conflict', because when you don't have a lot of people, you tend to wear multiple hats and you have to ruthlessly prioritise your time and be systematic about what it is that you're trying to do.
Especially at Banked and other startups that I've worked in, we tried to move towards dual track agile where, let's say, it's the product manager with PMM, customer success, solutions architect, and you would kick off almost a sprint zero; a big piece of discovery, because you're trying to figure out what is the problem you're trying to solve. That would mean that I'm about one to two months ahead. That still means I'm still working on delivery, going to my squad and standups and retro-ing and GTM, all of that happens, but you have to ruthlessly prioritise your time. Then what we do is we focus on value increments and moving to that potentially shippable PSI model of every six weeks, knowing what value we are going to deliver.
Really the key of our discovery is not to answer the world's biggest problems but to say, what is the quickest way, breaking it down into phases, to get to that value a lot quicker? Because obviously in the smaller start-up environment you're trying to understand, what can we iteratively develop on? How can we learn and test and grow as we do these things to test a lot of our hypotheses? All of our cycles tend to be shorter, irrespective of whether it's a B2B or a B2C scenario as well.
For us, it's a healthy friction, but it means that people do a little bit more left shifting, and as we said at the start, everyone left shifts with you. We create a culture of a lot of cross-collaboration; sometimes even a head of customer success would come in at kick offs or big objectives to get the latest feedback on customers.
Really, what we're trying to do is create a culture where everyone becomes a lot more comfortable with ambiguity. Just focus on the six weeks, I don't need to have the answers for the next six weeks after that. We'll try and futureproof as much as possible, but going in knowing where unknowns and risks are becomes a lot more manageable and digestible for even the engineers to work on.
Matt Vercauteren: Very insightful answer. I'm going to shift over to Michael. There's plenty of discussion about the dual track on product development, and on paper it makes a lot of sense. How easy is it in reality to run discovery and development alongside each other, in your opinion?
Michael Stencl: That's a really great question. I have to say, if you do not have this set up in your product teams, you should really start, because it's nice overlapping with the engineering teams. You need to be really consistent and you really need to do and share all the results, as you do from engineering perspective, doing this also from the research and discovery. Once you're able to make this part of the culture of the engineering team and product teams, or the delivery teams altogether, this is something that actually brings a lot of value to all the sides in the process.
It's good to do demo sessions by the end of the sprint. Do also discover sessions when you will be presenting what's actually happening on the market, what is happening with your customers, what are the findings you made and just make it a part of the culture and of the processes of the team.
Matt Vercauteren: We'll shift over to you, Yshira. Where do you think the ownership of discovery should sit within the product team and how can that affect their approach?
Yshira Kelly: Another good question. I think discovery, in short, is a team sport. I'm a huge advocate of something like, I think they've termed it recently, around squad-lead research. I love that. I think in the same way, as previously mentioned, ideas are coming from anyone in the company, it's also then everyone's job on the team to be able to recruit and then interview those customers. No longer is it just UX researcher, but in the same way that we've got our squads having this outcome goal to reach when building technology, by having the squad then also do things like user research, we then align the everyday work of solving customer needs with the end goals of the company, and then we become squads that do discovery regularly. Based on my experience, I'd say that there's some major discovery implications that are not really particularly difficult to implement. It helps the squad strengthen their discovery muscles.
In terms of how this can affect a team's approach, I've seen some of the good and the bad. I think the benefits of doing the hard work of product discovery as a team are really obvious. As product managers, we don't have all the answers. We won't hear 100% of the user's problems and we won't be able to connect all of the dots. This is where our team comes in and then helps fill in the gaps. So, together, as a team, we end up really knowing everything that we can about our user. We approach testing things differently. We end up doing things like building proof of concepts, prototypes, developers are whipping up something quickly technical. These may never see the light of day, but then this helps us dash from assumptions to validation, really, over and over.
A bit of the bad, I've seen. I think it's all good in theory, but I think what ends up happening is that a product manager goes away off on a discovery conquest and then they come back after that really long journey with all of the insights packaged. They've got 45 minutes long recordings of user interviews and they're like, well, here's the interviews, here's the customer research, get close to it as a team. But then what ends up happening is they don't listen, they go away, developers, and they develop the actual product. With product discovery and delivery, it then remains these separate phases and then always at odds. What ends up happening is it creates this culture of apathy within the teams.
As I said, good and bad. It's not an easy challenge, but I think once a team actually does take ownership of discovery, we end up fostering this passionate team. Our approach is one of being ultra-focused on the products. We get the whole team buying into the customer problems we're solving for and then we end up delivering value to the customer. It's just really a matter of trying different methods and building those habits and then changing the approach.
Matt Vercauteren: Final question on this topic. We're going to shift over to you, Allison. You have quite a structured approach to discovery at WhatsApp. Could you talk us through what your discovery cycle looks like?
Allison Busacca: Absolutely. So much of what has been said is really resonating with me in terms of that squad mentality I would say, particularly when we are thinking about attacking what I would call, maybe, the slightly shorter term questions that we have. We've got these hypotheses, we have these assumptions, we're putting prototypes out there, we are testing, and we are learning.
Throughout that process, I saw earlier in the chat, there was a question, are designers and engineers involved? Absolutely. That is that team sport. That's that squad mentality, where we are putting things live out there with our users, we are ensuring that they are landing, and we are tweaking if they are not.
I would say the added layer that we have on top of that is what we call our 'understand roadmap'. You can think about this very similarly, like your product roadmap. In an ideal world, those two roadmaps inform each other. The understand roadmap, for us, again, when we think about PMM, data science and user research, it gives them the opportunity to tackle some of those bigger picture questions or longer term questions. This might be, what is the next customer set we're going to tackle? What is the next market we're going to enter? We literally roadmap these together as a team. As your understand and your execution function, everyone builds these roadmaps together. The insights from the longer term understand roadmap should inform the product roadmap for the following half.
Equally, when you build the product roadmap, you generally end with some big open questions that you still don't know the answer to; that then informs again that understand roadmap. That does mean that PMM, data, science and user research have to split their time sometimes between that bigger picture understand roadmap and that day-to-day execution, product discovery work. But by building these roadmaps together, everyone is invested in ensuring that we answer these questions, because it means at the end of the half, we have answers to things that we didn't start the half with and we can really build the strongest roadmap possible.
Matt Vercauteren: Thanks, Allison. It makes a lot of sense. All right, our third topic of conversation here before we move into the questions from the audience.
On discovery, we're never really finished. It's a continuous process and there's always more to learn about customers. At some point, we've got to build some things. We've got to cut and move forward and decide that that's enough. When can we feel confident that we know as much as we need to, to move forward, that we've found that balance between risk and understanding?
First question on this topic, Michael, how do you manage this at Productboard and is there a tipping point you can identify?
Michael Stencl: I would say that, in my past experience, it was don't be afraid to experiment, iterate, be consistent, and be disciplined. The discipline there is critical. Also monitoring your competition or monitoring what's happening on the market. Small pieces here really make a big difference.
To answer exactly the question I'm not really sure, on the feature level, if you ever could be super confident releasing a feature. I would say, when you see the patterns coming from the customers and coming from the users it's a good sign to start building the model. But still, how to look for those patterns? My experience is it's really good to work with the visual prototypes, if possible.
In general probably the only right answer is be consistent, continuous, precise, and do small things, and try to iterate as much as possible, even with the early prototypes. That's probably now the best recipe I can give to the team so far with my experience.
Matt Vercauteren: Yshira, coming to you next. How does that research and discovery process change when you have to consider building products with children where you might not have direct access to the end user consistently?
Yshira Kelly: LEGO regularly engages children in their research of course and also in the process of character development and storytelling and then providing that cool feedback on new play set ideas. It's as cool as you can imagine it to be and children are really direct and they'll tell you when something is not fun! That part is super cool.
But as you said, we don't always have access to the children as our end user. Also in this context, to add a further complexity to it, the end user is not the person who makes the decision to actually buy the products for this shopper segment. So, I'm excluding the whole segments of adult fans of LEGO from this example, but it's really tricky because we're not only not talking directly to our users, but our buyers are not our end users. It means that we're also possibly getting things like problem statements from stakeholders that aren't necessarily aligned with what our users want or need. So, it's just a further complexity to not having that direct access as well.
When it comes to this issue of buyers not being our users, I don't think we necessarily have to change our approach to discovery as much as we now have to consider multiple people's needs that we have to meet. We have to meet the end user's needs and we have to meet the buyer's needs, because if the end user, the child in this case, doesn't use it, doesn't play with LEGO, well, regardless of what the parent thinks, they're not going to be purchasing again. So, no real change in discovery as much as considering multiple different user needs in this instance.
In terms of not having that direct access to the end user, it just means that we've got to look elsewhere. We've got to look for other accessible options. I've joined support calls to learn about customer problems where our product could be doing more and where our parents are relaying on behalf of the child. Any kind of creative customer care workarounds.
One of the PMs in the company did something really cool last week. She was in the airport waiting for her flight and she had some time to kill. She walked into a LEGO store, got the sales permission staff, and then just started following customers around asking questions. And those customers are then parents and then child. In case you weren't aware of it, when a child is looking to choose a gift and when an adult is looking to make a purchase, children for the most part will be really explicit in the desire for which product to get. Some really valuable insights ended up being gleaned relatively quickly.
This is just an example of a really stellar indirect way of gaining access to our customers when we don't have them via maybe traditional research tools. Of course, all of this doesn't really replace things like dedicated customer research, but it does go a long way to getting that ongoing customer feedback loop going.
Matt Vercauteren: Thanks Yshira. That's a great example. The topic of the buyer not being the user is interesting. It reminds me of the B2B space a bit, because a lot of times you end up selling products that the user doesn't necessarily have the budget to buy.
Going to an actual store - imagine going out into the world to get user feedback! Lovely example. Thanks.
Alright, Allison, we're going to come to you. Data and feedback is obviously key, but it's only one part of the equation. How do you make sure the data turns into insights so they're going to be useful and valuable for the team?
Allison Busacca: Absolutely. Yshira touched on this, actually, in a previous answer - the 45 minutes deck read out is tough, right? We focus a lot, actually, on storytelling and communication of our insights because it is one thing to do the research and to gain the learning; it is entirely different to make sure that those insights and that learning land with the teams, particularly in these day-to-day lives where we do have alternative demands coming in at any time. Execution picks up, we've got pings coming in at any moment.
We really do three things that seem to work pretty well. Number one, anytime anyone has an insight, I ask what their recommendation is. Don't just come to me with the data, don't just come to me with the feedback; tell me what you think that means for our product development. Come to the team with a recommendation that they can debate and action.
Number two, socialise those insights and those recommendations in as many forums as possible. That might be a 45 minute deck read out, to start with. It might be a note that you publish on your internal systems. It also means being a part of those execution discussions on a daily basis and making sure you're the voice of those insights in those day-to=day conversations.
Then lastly, I spoke about our dual roadmaps, our understand roadmaps and our product roadmaps. We end every half with an insights read out. It's a summary of essentially everything that we feel like we have learned so that people don't forget all of the great insights that we've picked up along the way. We make sure that that includes a recommendation as we go into next half or next year's planning of what these insights mean for what our users' need.
Between those three things, we generally find that teams are invested in the questions that we're asking and they're really eager to find the answers to the questions once we've got them.
Matt Vercauteren: Great, thanks Allison. One final question before we get to our questions that the attendees have asked. Niyati, how do you approach that closed feedback loop at Banked and what are the best ways to communicate insights across your business?
Niyati Joshi: I think I'll add on Michael and Allison's answers, as well, because it's very similar in that B2B space. With a closed feedback loop, because we're a B2B business, we also have the additional challenge where the buyer isn't the end user. It's a payment company, you're targeting CFOs and financial controllers, but it's API-first, which means that we're actually working with developers.
What I try to do a lot is to build relationships with everyone that is customer-facing that I can't always easily get access to. When we go into new product discovery, or we start to understand that a product is shaping up to look like this, or a new feature is, you get representatives of those customers in the room. We have a head of solutions architecture come and say, well, actually, it doesn't work quite like this, or developers prefer this, or actually, based on previous, they found this to be a little bit more cumbersome, let's try something else this way. It's about getting people that can represent your customer in the room with you when you don't have that additional easy access.
What I've also started to do is have a lot of open conversations with customer success to say, it would be great if I could join phone calls. It's not to prevent the sales from happening, it's not to prevent you managing that account that you have, but it's just to come in and listen and see, is it solving the problems that we thought? Who are the actual end users of our systems? How many of our assumptions and hypotheses can we actually validate?
To Allison's point, a lot of that is about closing the loops internally as well. So, going back and saying, at the end of six weeks, we did this, and this is how it's been successful, or actually we need to go back and rethink how we do this the next time around, so that they also understand what is and isn't working out there in the market and testing those assumptions at the same time. That happens in lots of various formal and informal sessions. Everyone loves Slack, but we also do end of week stand-downs and we come together and say, what did we learn this week from our various conversations that we had with stakeholders?
I think the key thing is, and to Allison's point, it's a lot about storytelling. What I found successful is to remove the product jargon, because that's the easiest way I can get stakeholders on the call. If I say I'm going to kick off product discovery, they will get terrified because they think I'm just going to go off on a ship and discover a new world. All I will say is, I think there's a problem here, or I think there's an opportunity for us to expand our services, what I need to do is talk to the people that will use it to understand a little bit more about the solution. So, understand the problem, frame the solutions, constantly keep just talking about all the various data points I've got.
I find it's very important to be open and collaborative. I like going on a discovery road show every four weeks with various stakeholders to say, this is what I've learned so far, what do you think? This is what it's shaping up to be. Getting them involved in that feedback is the only way I’ve found they can get shared ownership.
Removing that jargon and just putting it quite simply has a lot of impact. Instead of saying customer insights X, Y and Z, I just said, I spoke to five customers, they look like this, and this is what they came back with. I find that everyone just gets on the same page, irrespective of domain or functional areas.
Matt Vercauteren: Thanks Niyati, that's a really actionable little tidbit. Because changing your language just opens it up and makes it so much more accessible. It's such an easy thing to do, right? For product managers, it takes some active thought in order to just change the wording a little bit, but if you can do that then all of a sudden you're able to more easily engage and open up the conversation with more folks. That's a great bit of advice. Thank you.
We're going to shift over to our questions from the audience over here.
One theme here is, it's obvious to me that the four panel members are all working at companies where there's a culture of discovery and everybody's responsible for innovation. And not everybody on this call is working in an organisation like that; some folks are trying to get to that place. How do you combat the culture of apathy and how do you get stakeholders to prioritise innovation and work where you're looking into discovery?
Niyati Joshi: I think apathy would be a strong word. The way I would say it is, how do I communicate in a way where the person I'm speaking to understands the relevance of discovery, and how they can either contribute or how it will impact what their deliverables look like for the next couple of weeks or months.
It's a very valid question and not all cultures and companies I've worked in have been product-led or understand discovery. But the way that I phrase it is to step away from the jargon and the more structured, systematic way of doing things and just say we want to become a bit more customer-driven. And the way to do that is to think about all the problems that we need to solve for our customers within the space of what we do. And the way to do that is to get qualitative insights, quantitative insights, make sure that what we're building is the right thing. So you get the satisfaction that we're meeting business objectives, but also doing it in a way that actually expands and furthers our strategic priorities, or expands our market reach, or actually creates long-term retention.
The way I do that is by tying it back to business metrics that they're keen on or objectives or things they understand. I think it's less about apathy and more about relevance. For instance, I work with a lot of different engineers. They're very lovely people, and sometimes they say, I don't really care, I just want to build cool things. And I'm like, that's great, but you make a thousand micro decisions a day about how to build something that I'm not part of. How would you know how to make a decision? How would you know whether it's the right thing to do, futureproof it, what information than do you have? And if you knew the bigger picture of what we're doing or what's coming around the corner, that might then impact the decisions you make now. Less of it is about going back and having to refactor or piling on the tech debt or having to go back and not build a hacky solution, but something that's a little bit more interim.
A lot of it is around, again, that communication skill becomes very important, moving into this is why this is relevant for you. And that's not just with engineering. That happens with sales and marketing and ops and even executive leadership as well. So it's just about building that muscle of communication, I think.
Michael Stencl: I really like the idea about getting examples. Do your homework. Do prepare some storytelling about how in the past that was successful, affecting the business metrics. When you connect all those things together with the business metric and clear examples of what was happening, then you're in the right direction.
Yshira Kelly: I'd agree with everything that you've both just said. I'd probably add one really practical tip.
Stakeholders will always come to us with a million different requests, and always fighting for priority. One of the things that I implemented early on in, I guess, my last two companies was a really great one pager. So, I was just helping to define and use as a starting point this one pager in order to build shared understanding around opportunity, around value, and impact, and outcomes, and risk, and viability.
I was very quick to ensure that the communication and the language around what I was using within this one pager; it was short, it was easily consumed, it encouraged collaboration, but in no way was it meant to communicate detailed specifications or requirements or plans. Again, it's a great starting point for you to have with your stakeholders around what is the problem to solve for. Maybe a practical way to approach that mix with stakeholders.
Matt Vercauteren: That's great Yshira. I think the one pager is a great idea to try to shift the perspective, if stakeholders are thinking about, I want this delivery, give it to me, that sort of thing, just changing the conversation and elevating it is the way. Yeah, we could just deliver things but don't you care about these metrics and all of these outcomes and that sort of thing? Does that align with where you're heading with that?
Yshira Kelly: Yeah, absolutely. It's just about asking those questions. I think you'd be surprised when you start to ask the questions and ensure that there's a goal around the fact that we're not trying to manufacture certainty or pitch our favourite solution, but rather what we're looking to do is take this data-informed perspective on risk and return. And so if you just outline that for stakeholders, I think it goes a long way to make them understand that what we're ultimately looking to do is improve decision quality, improve outcomes, and ultimately make the best product possible. It also encourages novel solutions to validate problems.
Michael Stencl: May I ask you something? I'm just wondering if those one pagers include success metrics, or essentially, how do you define success?
Yshira Kelly: Yeah, there's so many different ways that you could define that one pager, but I've used things like how would you measure success.
One of the things that we always have to be conscious about as product managers is just accounting for bias. One way in which to do that is to make sure that we have that measurement framework upfront and outlined and that we're looking to agree on what that experiment design looks like with our team and with our stakeholders. You're removing bias and you know what to track at the end of it. Certainly that would be a key part of my one pager.
Michael Stencl: Agree on that, totally. I was asking because I have great experience, usually with senior leadership, if you ask them how do you define if these features are actually successful or that whatever we're building is successful, they usually have a discussion and realise that actually they are looking for completely different things they wanted to achieve.
Yshira Kelly: I have a question back at you actually and probably to the wider panel because it's something that I'm dealing with at the moment. Do we have success metrics for discovery, actually? Are we using that in any way? Are we defining the success of what discovery looks like?
Michael Stencl: That's a really great question. I would say one of the things is time to delivery, because when you do really successful discovery, usually the time to delivery of the features is short. I believe it really depends on many different circumstances and many different aspects as well. And it's highly tied up with the industry, so especially in software, this is something that can speed up things.
Allison Busacca: It's a great question and I can't say that our understand roadmaps, for example, come with KPIs against them. But the whole point of our discovery work is to inform the right products that we bring to market and so in reality you should all be chasing the same adoption metrics or the same business metrics that you're trying to move. You will hit those metrics if you end up answering the right questions and you do the right validation and you do the right discovery work. Otherwise you are bringing something to market that isn't informed, potentially, or doesn't have all the customer research that it needs or all the data that it needs to actually land.
I think that even ties back to the stakeholder question - you bring a couple of products to market that bomb and no executive is going to want you to spend the time building something that we can't eventually land in market. In many ways, I think those success metrics are all tied together and the more teams also drive towards the same goal, the stronger those teams will be.
Niyati Joshi: I think there's a tendency to make those metrics more quantitative. Sometimes, for me, it's a little bit more subjective where, actually, do I feel like I've gotten to a place where I have at least an MSP product that I could go in and test some metrics of success against? And sometimes that's perfectly enough. Have I given enough for the engineering teams to go build an MSP for me to go on to test? How many people does it solve for, or what was the adoption looking like?
To Allison's point, yes, discovery should always be about the wider business objectives and the goals. If it's to increase revenue, if it's to increase customer penetration, x, y and z. Yes, you should be doing all of those things. But sometimes it's just about being able to get to a stage where, have we understood the problem enough and are we thinking about a solution in a way that we think we can get to an MSP, at least, for the first six weeks, go in and build and iterate on that? So, I think while discovery might not have a hard metric, sometimes it's just about saying, how does it further all the other metrics that you then need to go in and hit.
Matt Vercauteren: I'm going to end the topic here. I want to give a huge thank you to all of our panellists, Michael, Allison, Jiyati, Yshira. You've been great. Really appreciate you taking the time to chat this morning and to our audience for joining. The questions submitted were excellent as well. I hope you all enjoyed watching it as much as I've enjoyed taking part and hosting with all of you.
Everybody that's attending, look out for the playback in your inbox later today. Our next Byte event will be coming up in November and we'll be chatting about DesignOps. Follow 383 Project on LinkedIn to hear more about that, if you're interested, and if you'd like to get involved as a panellist, drop us a line hello@383project.com. We'd love to hear from you. And then obviously out there on LinkedIn, as well as follow ups on this topic, this very engaging topic that the panel got into here.
You can catch up on past Byte events and lots more on digital product thinking on our 383 blog, which is at 383project.com. With that, I'll sign off. Enjoy the rest of the day, everybody, and thank you so much for being a part of the conversation.
