 Good afternoon everyone. Welcome to the session build the right thing with the formalized discovery process We're very happy to have Anjali with us. So Anjali, thanks a lot for joining us So without further ado over to you Anjali. Thank you. Thank you so much. All right. Let me share my screen here I'm so glad to be a wish I was in India doing this presentation in person, but we'll make the best of our virtual world So my name is Anjali Leon. I am the founder and principal of PPL coach It's a boutique coaching and consulting practice that offers experiential workshops and programs innovative co-created solutions like the one I'm going to talk about today and Professional coaching in the areas of product people and personal leadership So I incorporate design thinking lean and agile principles and practices and a coaching sense in all of my solutions My joy and fulfillment really comes from helping people learn to navigate and Increasingly uncertain and complex and changing world So today I'm really excited to tell you the story of building the right thing with a formalized discovery process And this is something that we implemented at one of my clients I was called in to help them evolve their product management practice And one of the most impactful things that we did there was investing in a discovery process So let me give you a little bit of context of this organization. You all might be familiar with Pearson It's a large international education publisher with over 33,000 employees all around the world and this particular business unit that I was working with was a thousand employee unit within this large complex organization and Their product was a fully online school Servicing from a kindergarten to high school and they had enrolled over 75,000 full-time students and over 250,000 part-time students and this process is something that we put together in the year 2019 and I wish it was there now because you can imagine that they are Bombarded with a lot of requests and all change happening in the organization right about now But in 2019 they found themselves in a highly competitive business landscape and They had some aggressive growth goals and so to keep up with the latest Technology and make build a really robust platform. They had embarked on a complete rebuild of their learning platform and Another little context here is that they had adopted agile ways of working and it invested in the scale agile framework The VP of product management there Stephanie Allen She was my sponsor and co-creator of this discovery framework And I typically give the stock with her so I'm going to try and bring her insights and perspective to this conversation the best I can You know, so she knew that the success or failure of this new platform that they were going to build Was predicated on how well they understood and met the customer needs You know, she did not want the new platform to just be a lift and shift of the old platform A lot of what we see in many other organizations, but she wanted it to be thoughtfully built based on the current customer needs so You know when I Got in and started Doing my consulting work with this organization I recognized the pattern that I had seen in in other organizations as well And it was this imbalance in where they put their focus energy and time you know, there was lots of effort put on Getting features out the door as quickly as possible and of course those there was emphasis on those features being of high quality and scalable But there was not enough of that effort energy and time spent on making sure that these features We're actually addressing real customer problems. It was really throwing something out there taking a guess They didn't spend the energy and time to make sure that it was a better experience for their customers So in other words a lot of investment in making sure that they're building the thing right And not enough on making sure that they were building the right thing And this might be the product of how some of our agile implementations have been put in place in many of our organizations You know making sure that you truly understand the customer's problem and pain points and addressing those Requires a steady investment of time and getting the right people involved. So it is an investment But without it your customers are likely to have a really frustrating experience I mean, I'm sure that you yourself have had many stories to tell of Products and services that your views that have been frustrating every time I think about this I think of that time when I'm looking for at a screen Looking for that button that I know that should be there and I just cannot find it or that incredibly frustrating experience and when you fill out a long form and You have to fill it out all over again because one of those fields got invalidated so you entered it for all or you missed it Or I have had many experiences where there's this elaborate Series of tabs that I need to fill out a little piece of information in each tab For something that is I consider fairly simple. I'm sure you have many similar stories to tell You know what I'm talking about When speaking to my sponsor for this company, you know, she she saw similar problems What she really wanted was to get her team to move beyond delivering just the requested features Really think about what was the experience that they were creating for their customers? She was also fairly new to the organization and Her goal was really try to strengthen the relationship between her product management team and their internal Stakeholders and development partners. She wanted to see all have all of them the whole product development group see themselves as one team Co-creating solutions for their customers, you know, because at that time, you know, she needed commitment from Technology she needed commitment from the UX her UX partners to kind of come up with the solution And she was getting it from inconsistent response at best Now she had some previous experience with design sprints And then I was doing a training for them and I brought in the idea of discovery teams and the design thinking framework that I had used with some other clients And so kind of the melding of the two to happen And we decided to put together a framework that addressed these challenges and brought in some of those ideas and principles And I should say that the investment and commitment That we made actually did pay off And and I'll share a lot more about that during the rest of this presentation But I have to say that, you know going out and interviewing real users Which in the case of this particular organization was teacher teachers and students and the students caretakers Really open their eyes to the real needs and struggles That these teachers and students and caretakers were experiencing and the opportunities that they were to make their lives easier You know I recall sitting in one of those early interviews and it was with the teacher And that memory will forever be etched in my mind Because this teacher had her voice was cracking There were tears in her eyes. She was so grateful that somebody from the organization had reached out to her to get her input And understand what her struggles were You know, I know that the team was part who was part of that interview They left with a renewed sense of the meaning behind their work and what they were doing I know that that particular interview Actually resulted in the dropping of a feature And closer attention to another feature. Isn't that exactly what we want? But let me give you a behind the scenes view of this framework but Let's start with A pause here and a little bit of reflection as with what I shared shared so far Are you experiencing similar challenges in your organization? And maybe if you have a pencil and piece of paper, just note down. What are those challenges that you are experiencing? Maybe even want to drop it in the chat So that others who are in this session can Can share your experience as well So before I share the details of this discovery framework, let me start with what I mean when I say the word discovery So for us at this organization, we define discovery as the thoughtful and disciplined approach That brought the right group of people together To focus on creating and validating a great customer experience You know before this uh Discovery was somewhat non-existent There was a lot of analysis happening Maybe the product manager went to some individual stakeholders and asked some questions Hardly ever conversation with real customers, at least from the product management team And any of those efforts were seen as low priority You know, I think this is true for a lot of organizations Anything that does not include hands on keyboard is often seen as waste But you know, I think Peter Drucker said it really well There's nothing quite so useless As doing with great efficiency something that should not be done at all What discovery does Is it strikes a better balance? It restores that balance between the investment that we are making to ensure that we are creating high quality scalable output And the investment in understanding the needs of the customer to make sure that the output that we're creating Is towards better outcomes So we created a process that put thought and discipline behind that investment And it was great that we had the VP of product management who served as the internal sponsor and champion Of this investment because it was really important to have that That that champion inside the organization to Bring to to help it Take life So the discovery framework That we put together had these Four core elements They were elements that we borrowed from and curated from other frameworks And there were some ideas in here that were very important to the context of the organization That we were in So the first thing was this discovery framework was based on the principles of design thinking It borrowed heavily on elements from Jake Jake knaps book sprint That you see in the slide here And elements from the design thinking framework and another product leader Teresa Torres's work So a lot of duration Of of those bodies of knowledge We recognize pretty early on That the problems that needed to be solved really required cross functional representation even at this discovery stage Particularly at this discovery stage So whatever framework we put together would need to include participation from engineering from architecture and user experience And you'll see how that came together We also realized that for this to work the team would need to have The things in place that would help them be successful. So some clear guidelines and expectations And some good tools for them to work with and the necessary training So there was funding that was required and this is really where the VP of product management Had a big role to play in making sure that this was well funded And then we did not want whatever we put together to be yet another process that the team had to contend with and get confused But you know the teams were already practicing scrum at the team level and they were they were Using the patterns of the scaled agile framework at the program level So we wanted whatever framework we came up with to fit seamlessly as possible with whatever was existing at the time So let me start You know drilling down a little bit and sharing a little bit about this cross functional team That was a really critical element of this framework So when we first Socialized this discovery process And started getting some excitement in the organization around it. Everybody wanted to be a part of the discovery team But you know, we recognized that it was important to keep it fairly small and of course cross functional So the discovery team that we put together That met those criteria was fairly small. We call it the core discovery team And at Pearson, this is what it looked like Pearson had product managers and then product owners for each of the teams So a core discovery team included a product manager who was kind of facilitating the discovery work Uh, then there was a product owner an engineering lead a qa lead A ux designer and an architect as part of the core team and this core team worked pretty closely together They met on a regular basis. They were the ones who were really interviewing the customers assimilating their information and identifying and validating potential solutions But in addition to this, you know, there were lots of insights and subject matter expertise all across the organization That could really support this core discovery team So we identified what we called the extended discovery team So here's an example of who might be on an extended discovery team The membership of the extended discovery team was determined by the core discovery team They depending on the discovery that they were on and who they needed to engage from the organization But the extended discovery team members were very specific They were identified as people not just a department and that individual was invited into Certain events that the core discovery team conducted The core discovery team really relied on the extended discovery team for initial insights and then validation And further insights on some of the work that they were generating So you can see that when it comes to discovery Anyone in your organization can really contribute to discovery another piece of This the way the teams were structured is that we did not want this to be a handoff Otherwise, we'd be just going back to what we had, you know way before in the waterfall world And so the way the team members were selected was done very carefully to make sure that the knowledge gained during Discovery made it all the way through to delivery Ideally, maybe you wanted the whole delivery team to participate in the discovery But that it didn't wasn't an optimal solution in this particular case So the best thing that we could do was to make sure that we had a representation of From the delivery team that was likely to work on the features their participation In the core discovery efforts So you'll see here that the product owner the engineering lead and the qa lead actually shared responsibilities between the discovery and delivery Now they did have to Manage their time a little bit better than the other delivery team members But they learned how to do that because they saw the value of the insights that they gained from the discovery that they could bring back in to their team This was an absolutely critical element to make sure that the understanding of the need of the customer was brought back and made its way As the teams were uncovering solutions to these to the features that they were building So here's what that process looked like it had four different phases Understand ideate validate and define. So a lot of this as you can see is borrowed from The concepts from design thinking but to fit the context of this organization So in the understand phase the team took the time to review current functionality because this was kind of rebuilding of a platform And it took the time to conduct their customer interviews and uncover pain points and opportunities A lot of this information was captured in customer journeys And and shared and during this stage was it was a really good time for the team the core discovery team to engage That extended team to get their input and their insights At the end of the stage the team had some clear goals for further discovery taking to what they needed to ideate on and validate The ideate stage was when the team brainstormed some potential solutions Leveraging techniques again from design thinking like how might we statements to explore multiple ideas and then sketching and wire frames To brainstorm how they might solve these problems by the end of the ideation stage The team had a complete a couple of ideas on How this goal could be accomplished? The next phase was the validate phase And the team here Took some of those ideas and they wanted to get feedback from the customers. So they built some prototypes very Cheap and inexpensive prototypes Mostly just illustrations of how points just enough to communicate The experience to the customers and get feedback from them again this was a Time that they could also get feedback from the extended team extended discovery team as well So after this feedback was collected the core discovery team did some synthesis of this information and Broke it down into what features and enablers they've been they would need to make this come to light remember they were working with the Scale agile framework and so these features and enablers made them made their way to the program backlog What's really important about the stage and we had to emphasize the team is to not over invest in any of these stages Especially with too much of too much detail You know the product owner and the engineering lead that they're part of the discovery Would have an opportunity to work with the delivery team to further flesh out these features break them down into stories And put some meat on the bones of these features that also would leave room for emergence and further validated learning The emphasis was on not forcing this back into a waterfall process So as I mentioned earlier, it was really important also that this felt seamless In what the team was currently doing kind of integrating it with Some existing processes and this is a picture of how that worked for this team. So it was easy And natural for the output of discovery to flow nicely into the sprint delivery cycles Of the delivery teams And the discovery efforts really informed delivery But were not prescriptive The delivery team still had the opportunity to apply their creativity and problem solving skills to identify the best implementation of that proposed solution So i'm going to pause here again for some reflection Now I described the discovery process within the context of this organization Pearson Just think about what aspects of the discovery process would need to be different for your organization And as I pause here, I'm also going to ask if you have any questions up to this point And jay if You know that any questions in the discussion of q&a. I'm happy to take one now Yeah, hi, angelie. There aren't any questions as of now, but uh guy do posting your questions. So Angelie can answer them and Get it all clarified. So Yeah, use this opportunity Awesome. Thank you, and I'll pause again in a little bit and you know, let me know how things are going Give me a thumbs up. This stuff is resonating with you and you're finding it valuable and useful It's a little bit difficult in a virtual environment to to see all of you But I hope that this is uh, this is resonating with you So i'm going to switch now switch gears a little bit and talk a little bit about how we rolled it out And what hurdles we had to overcome when we rolled it out So while there was buy-in from the organizational leaders and key stakeholders, but on board Actually rolling it out. We encountered some things that we had to take into consideration In hindsight, it feels uh, that it was You know, it was easier than we had felt at that time So the first thing is we had to make sure that we found a way to Get everybody bested in the process, right the discovery team members and the extended team members This was something new that they were embarking on. There was some some level of uncertainty and discomfort and we wanted to make sure that they were set up to succeed So this meant aligning everybody to a shared vision And each of these discovery efforts were Launched with a introductory kickoff meeting And some of the early discoveries we made sure that this kickoff meeting included An opportunity to really understand the process And allowed the team to ask any questions that they understood the why behind what we were doing And then with every one of these discovery kickoffs The product manager made sure that they provided the context and goal of the discovery that they were embarking on Again making sure that everybody understood and had a shared vision of what they were going to do next But a couple of the product managers also planned to do some team chartering activities during the kickoff And this really helped the team get to know each other And they co-created some working agreements and set some clear expectations of what they wanted to accomplish together Now this was huge in setting the conditions for collaboration And since became a pattern with all of the product managers For us who had come up with this initial framework This was a huge win And in the fact that the product managers felt that they could make this process their own And massage it and and bring in some new ideas into the process as well The second hurdle while we had figured out how You know the the output of discovery would flow flow nicely into the delivery cycles We had to see how this kind of fit into the established safe framework without it feeling awkward So at Pearson, there was a huge investment already made in the safe framework and it was serving them well And the team the product managers were already Engaged in portfolio and program con bonds as they progressively Elaborated on the ethics and features and moved them down the con bond board and got them ready for PI planning What we realized is that the discovery process phases Or stages aligned nicely with the various phases Various stages of the portfolio and program con bonds So for example when the discovery team was empathizing with the customer and understanding their needs And to find the goal, this was a really nice This aligned nicely with the reviewing stage of the portfolio con bond But those of you who are familiar with safe this might resonate When they were ideating and experimenting it aligned nicely with analyzing Stage of the portfolio con bond and then when they were doing the defining work It fit in really well with the analyzing stage of the program con bond They established whip limits of the safe Con bond systems actually worked really well in terms of managing the flow of the discovery The the discovery process as well The hurdle number three was this was a completely distributed organization now six seven months after COVID this feels like hey, this should not have been a hurdle at all But this was back at a time when we weren't So familiar with all of the tools that are available out there. So Our hurdle was how do we create a creative collaborative environment That design thinking And creative work Requires, you know with the stickies and sharpies and drawings and mind mapping And whiteboards. How do we create that similar experience virtually? And what we found we found the answer in tools and some of these tools are very familiar to many of you now So for us zoom was a huge win It was a great video conferencing tool everybody could have their camera on people could see each other's faces And that made a big this Difference in terms of feeling like a face-to-face kind of setup The options for the breakout rooms allowed for smaller group discussion and more importantly The recording feature was one that really supported and helped the team In being able to capture some of these interviews and look at them later or to share An output of one of these meetings with those who might have missed it The real game changer Was this tool called mural again a tool that some of you might be familiar with And this is an infinite virtual whiteboard. It has built in templates and stickies and Anonymous voting and timers And it really allowed for everybody to contribute just like we would in an in-person setting The introverts and extroverts had a place in this virtual space You know, I'm a big advocate or at least I have been a big advocate for face-to-face interaction But this tool opened my eyes to what was possible with virtual Digital technology and sometimes it was even better than an in-person experience Some of the other tools the team used one was aha And aha was a way that they were already Capturing the ethics and features and this became the place where they also Captured some of the artifacts coming out of this discovery. This is attachments to the ethics and features in aha And the team had an internal wiki site called neo And the product managers actually used this really well to blog about the progress of their discoveries And keep the very curious internal stakeholders and leadership Up to date and what was going on in terms of their discoveries The fourth turtle here Was one that you might all recognize and might have challenges with as you're putting these if you're going to put Discovery discovery into action in your organizations and that is the capacity of key participants You know, there's just not enough of us to do all of the work that we need to do And so we had to constantly inspect and adapt to address How do we manage and balance out the capacity of all of the participants in this discovery So some of the things that we had to do was kind of Align the discovery to the roadmap. So we've been much more intentional About what discoveries were happening and when they were happening and who would be involved that they could be Aligned based on that and what I mean by that is, you know This platform had discoveries that needed to happen in these various components of the platform different areas of the platform But they might have still involved the same UX designers and the same architects and maybe some some of the same internal stakeholders So a little more intention about how and which discoveries were happening at which time Established with limits and the safe framework helped But we had to introduce some additional limits for the number of discoveries that were active at any point in time And then provide a space to mindfully engage So the product managers who are mostly the facilitators of this discovery Had to really be thoughtful about when and how they engaged with the core team members and the extended team members And they had to do some extra preparation in order to make sure that the collaborative sessions were meaningful and Were worth worth the investment of time of all of these people who came together So i'm going to pause again here So if you were to put a discovery framework in place in your organization and it resembled something like this What are some hurdles? That uh, you might have that you might need to jump over in order to be able to make this successful in your organization And jay, is there any any questions at this time? uh Yes, we have a couple of questions I'll just Let me actually finish. I have a couple more slides and then we can take all of them at that point in time Awesome. Thank you. Sounds good. Thank you All right So i'm sure that you're curious about how other people felt about this and was this successful So I have a little bit of evidence around what were the outcomes of this Framework being put in place. So here's some feedback about this process from the team itself And I love this one from katie. She was a product manager For another part of the organization who was Part of the extended discovery team for one of the discoveries and she said I don't like how you roped me into this and how much i'm enjoying it. Damn you daemon and daemon was one of the product managers And this one is one for one of the dev leads and this is the kind of insights about From this of this discovery from people the technical people on the team And this dev lead said I have no idea. I had no idea That the user did that it's awful. We need to fix it And this is one from sue the business stakeholder What a manual nightmare these folks have been going through. I can't believe we made them do that So it really built empathy from within the organization for the customers And users of the system And here's some feedback from actual customers. So The initial rollout of some of these features And the road showed that some of the leaders went on got some really good feedback from school leaders And from teachers on the features that were put in place and there was one quote from one of the school leaders that said Wow, we have really thought about how we are going to actually use these tools and it shows And that's kind of a reflection of The fact that this this investment was made in really understanding the need of the customer So i'm going to end with some Sage advice in case You want to implement something like this in your own organization some things that we learned And in the q&a you can ask some additional questions about other things that we might have learned So the first thing that I would have to say that was the most difficult is to fall in love with the problem and not the solution So discovery really requires patience To empathize with the user and really understand the problem before we jump the solutions And we are in a culture of problem solving getting things done And it's hard for us not to jump to solutions too quickly. And so it really takes some intention here Number two Ensure a clear goal for the discovery So early on sometimes we started without that clear goal and you know discovery can be a forever endeavor So when you embark on a discovery make sure that there's a clear goal about what you need to learn what you need to uncover What assumptions you need to validate before you go on that discovery? And set some clear boundaries like time boxes and whip limits for your discovery efforts So that you're able to converge on what you're discovering Relatively quickly You know the best way to ensure that you're building a great product Say try to include the people who are going to use the product and co-creating the product So yes interview customers, but then keep them in the loop Engage them with regular feedback cycles ask them You know to give you some feedback on Some of the things that you're trying to validate and if it's an internal customer Then you might even be able to include them in your ideation stage and when you're coming up with your your ideas for your solution Number four is apply both data and judgment to inform your decisions So sometimes we have biases blind spots In our decision-making and what data can do Is help you validate those decisions so include some analytics include Analytics in your features so that you can use that data as you're making decisions further down the line But sometimes Data can defy common sense data might not Include the context around which that data is collected So make sure that when it defies common sense you trump data with judgment So it's a delicate balance That you need to strike there And then the discovery process did not really offer a framework on how to collaborate when to collaborate, etc So our teams use the spam framework. We already had that In place and so the the core discovery team just borrowed patterns and elements from scrum just that they shortened their Their cycles their sprint cycles because they needed to get feedback much more quickly but they use the same mechanisms of planning and The daily regular check-ins and a review process that was built into the framework So our last Self-reflection here. I will leave you with what are you doing? To ensure that you are building the right thing And I hope the session today gave you some insights on what you might be able to incorporate in your own organization And if you have any questions about this or would like to learn more about what we did or engage me in Co-creating solutions with you. Here's my contact information. Please contact me on LinkedIn I'm very active there twitter and I'd love to stay in touch and with that I am going to stop sharing See if there's any questions Yes, we have a couple of them. So Let me put them one by one So the first question is from so big yeah And she's asking what was the duration of the discovery process as compared to the sprint cycle So I'm going to give you two aspects of that. So the duration of the discovery process Typically when we initially looked at all of those different phases, we gave a recommendation of about one month for discovery But it really depended later on On what the discovery was so some of them took much shorter period of time. It went through that understand ID 8 validate define stage and some took a little bit longer depending on the goal of the discovery But when the discovery happened since they were using the scale agile framework and The product management team were coming up with features and enablers to go into p.i planning The discovery efforts for a p.i happened one p.i earlier It's not ideal in terms of getting quick feedback, but it kind of fit into the context of that organization If at all possible what I would recommend is a continuous discovery Where it flowed very quickly into the delivery cycles But for this particular organization and the time where we were At what happened was the discoveries happened in one sprint that fed into the discovery Fed into the delivery of a subsequent sprint. I mean subsequent p.i I hope that answered your question So big yeah, you're right awesome Yeah, okay. Yeah, she's replied in the chat. Okay, so the next one is by shreeter And well, yeah, he's asking can discovery teams And extended discovered discovery teams be formed by organizations adopting this framework So discovery teams and extended discovery teams be formed I Can you put a little little more on that? Yeah Because I mean in this particular case. Yes We actually were very thoughtful about How these discovery teams were established and I do want to say the common Of people in it, you know the the discovery teams that kind of stayed with each other were typically the product manager with the architect and the ux designer And depending on the discovery the product owner the engineering lead and the qa lead would be Might have been different for different discoveries So that was one of the things it was a little more dynamic Then long sustained teams the same thing with the extended discovery team when they the team embarked on a discovery They identified who would be the extended team members and they dynamically formed that extended team And I hope that that helps answer the question It is a little in there's a little more intention that goes to it and it keeps you have to keep reforming those teams