 Hello everyone. Good morning. Thanks for being here. Welcome to our session. Rome was not built in a day. You have heard this quotation a lot of times in your since your childhood. But there's a modern interpretation to that as well, which says though Rome was not built in one day, but every single day they were laying bricks to actually reach to the beautiful city of Rome that we have today. And the same analogy, if you kind of extended further into our digital experience platforms, for example, same, it's not built in a day. So you can't build great digital transformations in a day. It has to be done in an iterative fashion, in a strategic fashion, in iterative way, right? And that's how you build great experiences for your customers. On the similar lines, we at Strygian, back then, two years back, when we all were stuck at homes in the pandemic, we got a chance to work with one of the largest media conglomerate in Singapore called MediaCop, which had a very similar use case of building large digital transformation across a lot of portfolio products for their different brands that they have. And they had mobile apps, they had web apps, API gateways, right? A lot of different platforms, which wanted an entire digital transformation across the board. And that's where our learnings came in. And this way, we are here today to share the recipe with you, right, about how you can use the, how you can actually build a portfolio of products and do the discovery and actually develop those products. Hi, my name is Anubhav Gupta. I work as a product manager at Strygian Technologies and my co-author Rupa Mistry. She's a senior delivery manager. She couldn't be here today for presenting. We both have co-authored this session where we're going to share a recipe, a takeaway that you can take it along. So be it if you're a business owner or a site builder who is looking for exemplifying the customer experience, the digital platform, you can take this recipe out in your project setups, in your use cases, and kind of use these to actually build successful products. And so yeah, that's where we are today. So as we, as I said, so we have been in the pandemic from two years and our style of works have changed. Our approach has been radically different now. Our whiteboards on which we used to do collaborations have now been replaced with digital canvases and, you know, our meetings which we used to do for interpersonal, right, in person have now been replaced with Zoom or Teams meeting, for example. So how do you kind of do digital transformation or build these mammoth projects, right, when you have remote working as one of the new ways of working? And that's where we are today, right? I'm going to explain you the entire journey, how we did it, kind of through the process, we have done thousands of discoveries and kind of evolved through the process as we have gone along. So there are a lot of learnings and recipes that we would like to give out today. Now for the audience context first, I would start with explaining about what's a discovery all about, right? For any product, right, if you are looking at, say, a news product, for example. So the brand that I'm going to talk about is MediaCop, which is Singapore's last largest media conglomerate that we were working with. So they had a lot of products across news, across podcast, OTT platforms, right? How do you do discovery, right? So it starts with basically problems, right? What you're trying to solve for your customers, for your internal business teams, right? So typically somewhere around this section where you're discussing with your business stakeholders, your technical teams, from your customer side, trying and understanding, reaching out to customers and understanding what are the problems, right, that they have and what are we trying to solve when we are building a digital product, right? It could be for editorial teams, for example, making lesser clicks for maybe publishing a content, right? So what this discovery what we are doing generally when we start a project is about trying and understanding the problems and then actually figuring out the problems and then going from that problem to actually a solution, right? So as Einstein says, if you have 60 minutes, I'll spend 55 minutes thinking about the problem and just five minutes about the solution. So discovery as a whole is a mix of understanding your editorial requirements. It could be from the product side in terms of user navigations, building nice UIs, right? What your customer needs and likely from technical side as well, what are the different requirements? So you kind of go from here with all the problems and kind of come to a situation where you now have a solution in place, right? So that's a discovery as a whole. Now if I go and extend this analogy forward in terms of when you're doing a discovery for one product, now extend this thought further when you have a variety of products, a portfolio. So overhead, as you see, I've got an example of Pepsi, right? Though they have a lot of more products here, but taking few examples here, so they have thirst quenchers, right? Products which are quick bites, right? Which are positioned in such a way for customers, right? Which solve a specific problem, right? Similarly, if you go and use this context in digital landscape, right? Each of the products are solving different problems for customer. So in our case, when we were working with MediaCorp, we had a use cases about news, right? About podcasts and different products, which is suiting different kind of personas, right? And each of the brands have their own requirements, own set of stakeholders. So say for example, when we were working with one of their main flagship news, news brand, which is Channel News Asia, the scale of it is half of Singapore population reads Channel News Asia every morning. So that's the scale we were dealing with. Now, it comes with their own challenges. They were doing digital transformation. So a lot of stakeholders like ad steam wanted revenues to be increased, product team wanted how they can serve their customers better, kind of make it more engaging. Then there were tech teams who also wanted to make sure that the go-to market is quicker and the maintenance of sites are quicker, right? So when you have a portfolio of products, how do you actually get to all the requirements kind of and actually build a product? So we were on a journey of like two years, right? And how do you do this, right? As I mentioned, Rome is not built in one day. So how do you iteratively plan for it? So we have a very structured approach that are a CB that you can take along with after this session. So what I'm going to talk about for the next 30, 35 minutes is going to be the approach that you're going to take when you're dealing with kind of an enterprise, large-scale digital transformation. What is the approach you should go with? How do you plan for it if you are also in a remote setting, right? We are now all in a hybrid way where we're asking customers if you want to go and do interpersonal kind of discovery sessions or even remote. So how do you do that, right? So approach, I'm also going to talk about how do you plan and execute and some challenges that came on the way that we championed over that you can use as well so that in your project settings, you don't face that, right? So takeaways as I mentioned, we're going to make sure that you get a recipe for driving portfolios in your project setting and also how to deal with challenges that may come along, right? So the first about approach to discovery. So this is kind of an iterative approach. As I said, with MediaCorp, we were working with dozens of brands with each focused across different personas, right? Different type of problems that each of them were solving. So we can't just go in with all the products as a whole and gather requirements for all of them together. You have to do it in an iterative fashion, right? So for that, we kind of followed this entire cycle. So the oval that you see here is something that keeps iterating as the program goes further, right? So we start with a portfolio discovery where we're kind of understanding each of the individual brands, what they need, and then kind of iterate as we go along, building each and every product as we go along in the program. Now it's also important, like if I talk in terms of Drupal, when we are using Drupal as a solution to have an enterprise level solution, you kind of look at multi-site architecture kind of solution where you want to build a common code base of features that can be reused across different brands just to make sure that the feature rollouts are quicker, the go-to market is quicker, right? So it's important that you kickstart with overview of the business of individual brands, right? So as I mentioned, we had 12, 8 to 12 brands. So understanding individual brands, kind of finding out what is the commonalities, right, in terms of the requirements that each of them have, right? And what is the best list? What is the pain areas that we're trying to solve? So like for example, from the editorial standpoint, one of the key pain area was they had, since MediaCon was a government of Singapore undertaking as well, so there were a lot of content which were accidentally published by editors. So how do you make it accidental proof? Now to make sure that none of the content got accidentally published in case it has to go out at a specific time. So how do you solve that? That's one of the common problems across all brands at MediaCon. So kind of kickstarting with business overview of all the products, right, as a whole. And then finally understanding in your roadmap which products you want to pick up first, right? So finding out your initial brands of focus and then deep diving into if you kind of doing a full service in terms of doing design thinking at the beginning followed by an engineering side of Drupal implementation. So you would pick up the initial brands and do the deeper discussions around those two brands or whatever brands that you're picking. You develop those brands and iteratively then again go into the discovery as I showed here in this oval. So you pick up the next brands in your portfolio, again go through the discovery and spring zero. If you have mobile apps, you have web apps, you kind of build those, deploy that and again pick up the next product, right? So this could be done iteratively. You can do sequentially or parallelly as well depending upon the capacity you have in your teams as well as you know what how the timelines look like, right? So for us we had a very strict timelines of 24 months to deliver everything in the portfolio brands. It's equally important that you kind of plan it based on what your setup is, you want to do sequentially or parallel as well, right? So that's about the approach. So once you have kind of set up an understanding about how you would approach your discovery, the next is about you do some planning as well, right? Before you actually get into your discussions in a meeting room with your customers, right? So before I go to planning are there any questions from the audience at this point in terms of approach or in terms of discovery or portfolio as a whole? Yeah, please go ahead. So your question is how much time did you spend initially preparing for your discovery? So that's I'm coming to. Hopefully I'm going to solve that. I'll possibly give you the answer to it as well. But generally it depends on case-to-case basis. So we were dealing with eight plus brands across multiple platforms with mobile apps, web apps, tablets, and API gateways as well, right? So it depends upon how fast you can kind of plan with all the information that's needed to actually get into the conversations, right? But you have a deadline, you kind of work backwards with it. So I think I'll be answering that question again here as well, which in greater details, which is about planning now. Now you have done the approach. You have a solid foundation place, how you're going to actually go ahead with gathering all the requirements for your portfolio. You kind of do some groundwork, which is planning, right? So I call it a four-step process which has worked for us. A scaled-on version or a scale-up version of this would work in any of your setups. So first up is designating the team, right? So you have to, since you're working in a remote setup, you have to kind of understand what is the team that's going to be needed, right? So in MediaCorp setup, we were working with a lot of different stakeholders team, like a team related to S-years or a team who's absolutely very focused towards ads revenue, for example. Then a team focused on editorial experience and likewise for product as well, right? So we had different teams whom we were interacting with and it's equally important when you are planning for this, you identify a team for yourself as well, who's going to be there for you together or through this discovery process. So if I've put in place like a full-fledged, what would be there in any project setup if you have, you start with the design thinking. So you would have some people from the design side. You might have people from product side who would help you on the editorial experience perspective or different features that you would like to put in your product, likewise from the tech side who would help in solutioning and the process side who would kind of help you actually going through the success of the product, right? So first very important step is identifying the right side of people. The next step that I call it is despising the discovery prerequisites. I've intentionally put a lot of text there. This is for later reference. Just wanted to make sure that you have a right recipe in place when you use this slide deck later on as well in your project setups. Essentially, prerequisites, right? We have to understand that we don't have, we are not in a same setup where we had an full day of sessions with the stakeholders. We all are brainstorming together and kind of finding ideations and kind of coming up to solutions. The time is short. We have to keep it productive and actionable as well, right? It's equally important when you're planning for discovery. You have the right set of information that you need for pre-processing of the data, right? So that when you are getting into discoveries, you have the right information and you can kind of help in and serve and facilitate the discussions. One of the examples that I remember is like one of this I've mentioned in the design is about the UX research about comparators. So Mediacorp has a lot of comparators across the Asia, since they are one of Asia's leading media company. So they had some specific comparators that they would look at, right? Like Washington Post, for example, like New York Times. And we had done some UX research for them in terms of what different comparators are doing good. And then when we are actually going in, you know, for a design discovery, for example, these kind of data points do help in terms of how well the comparators are doing recommendations or personalization, right? If you have those data beforehand, it kind of helps you take decisions early on. Another example was hamburger. We were discussing about where should we place the hamburger on the mobile apps? Should it be at the top right, top left, on the middle, bottom or bottom, bottom left or bottom right, right? So all of these things, you kind of do some pre-processing before you actually get into these sessions. So I've again broadly categorized into four, which is design, product, technical and process. Not all of these might be relevant for your project setup. It depends from case to case basis, but I've tried to list down what has worked for us in majority of the engagements, right? You kind of get all of this information beforehand so that when you work with these teams with yours, right, when you're kind of preparing for the discovery, you have the right set of information with your stakeholders, you sit down kind of plan for the discovery. So that's the second step. The third step, which is, I call it the backbone of the discovery, which is going to be there. Just to add, we had a four to five weeks of discovery, so it's important that you have the right calendar set in your discovery. So setting of calendar is the heart, right, when you would actually go in. The easiest way to actually use, to actually set up a calendar is kind of define themes of each of the weeks. Defining themes kind of helps aligning your internal external stakeholders, as well as define, helps you define what should be the meeting that's needed for each week as well. Now for us, for example, as I mentioned, if you're going full scale, we start with design discovery. So a design team would come in at week one. So this is not a recommendation saying that, hey, it need necessarily only week one. It could be two weeks as well, right, depending upon the scale of project you're doing. Then week two, probably, you know, you're specifically doing product. Third, where you're specifically about talking about technicalities and lastly about the process, right. And defining what's the expected outcomes of each of the weeks, right, is important as well because that helps you kind of work backwards in terms of what's needed out of each week. It helps you define each day's in the week, what you're going to discuss. Now, once you have kind of defined what is the theme of each of the weeks, this is one of the ways where you can do it. Other ways, which we have seen it in the past is you could do brand wise as well, where you're doing brand one on day one, a brand on day two. However, with the remote setup, what we have understood is a lot of functioning teams kind of overlap with brands. Like for example, we understood that SEO is one of the strategy that's common across the board. While you're doing enterprise level digital transformation, they also want to make sure that things are standard across the brands like security, like SEO, like ads management, for example, right. They want to make sure it's standardized. It's not working in silos with different brands. To make sure on that, we kind of avoided a strategy where we had brand one on day one, kind of went with kind of an hybrid approach where started with all the brands, kind of got the overview. And then with week one, we started with pure design on a two focus products, right, that we had at the initial part on our portfolio. And then further went along on the other sides for the week. Now another important part, just a relation to this is while you have defined the themes, now it's important you kind of define how your week looks like, what are the meetings you're going to have, right. And what has worked and this is a clear explanation in terms of what should go in with every meeting. What you've understood is when you're doing remote meetings, it tend to go long, boring, unproductive, right. We have all seen that experience, it kind of learned and evolved through our times. What we have seen is how we kind of do pseudo simulation, even before you're getting into meeting with some actionable expectations, right. When you're defining what is the title, what is the agenda, right. And with each agenda defining some time, hey, I'm going to spend 30 minutes understanding your business and another 30 discussing about your vision as well, right. And then defining a expected flow is equally important as well, because we have seen it has gone funny where the first five minutes of the meeting, everybody's thinking who's going to start, right. So you don't want to be in a situation where nobody knows where, maybe what you want to achieve, right. And who's presenting what. So having a expected flow of the session actually helps you to get started right from minute one when you have dived into a discovery meeting, right. Specifying the attendees equally important to start with when we when we went, as I mentioned, we were working with 15 plus stakeholders team. A lot of times we had 40, 50 plus people on a call with just five people contributing, right. Doesn't make sense to have 50 people on a call with five contributing. What's the point, right. We're wasting time and you kind of you multiply it with mandates, it's super, it's and you multiply with the dollar value, it's huge, right. And beg your pardon, but the customers we were working with, right. It was very difficult to get time of the stakeholders, right. So we had to be equally wary of the fact that we only get the right people at the right time, right, and at the right place. So equally important to specify who attends what meeting and an expected outcome at the end of the day, right. So once you have all of this, I've kind of placed a glimpse of how each weeks look like. We kind of created an Excel sheet with each of the week, how it looks like. So since we were working with Singapore, so different time zones, understanding, getting what slots are available with different teams. And then with each meeting, you see a meeting. What is the, what is the title? What is the agenda? Who is the expected flow? Who's gonna, what is the expected flow of the session? And what are the required stakeholders and outcomes for each session, right? You kind of have each of it created for individual weeks, and then kind of go into approvals with, with each of the stakeholder teams to make sure that they're available at this time. Even before this, what we also make sure is we kind of got common slots of individual teams. Since we were working across, though Singapore India is, is in one continent, however, we also had stakeholders team who were working from the states, some of them working even down south as well. So, you know, different time zones becomes huge challenge. So you see two rows here, we have seen portfolios that have worked with, with five, five rows as well, right, with different time zones working. So important that you kind of work with your core team, who's planning the discovery to have some common slots, and then have the meetings defined of that week, right? So important step, have a calendar ready for your discovery week. Lastly, the outcomes. Like at a micro level, we have spoken about outcomes in meetings, with every meeting. There's a broader outcomes out of the discovery as well. That's important. So you have to, you need to kind of think of the future where your four weeks down the line, you have completed the discovery. And now you are, actually, your SCUM teams are ready to actually go ahead and develop it, right? So you have to kind of think backwards and go with what is the expected outcomes where you can say, okay, my discovery is closed, right? And my SCUM teams are ready to go in, right? So thinking from, from reverse engineering perspective, again, four broad categorizations are kind of put in. Again, some of the documentation here might apply to you, some might not. But for us, it was important that, you know, we had these defined. So like from product perspective, there could be somewhere on KPIs, like we are working with different brands, like for MediaCorp, it was important that we had capture like the business vision, right? What, what, like a director of digital operation or digital officer would have for all the digital properties, right? And then kind of refine for individual brands further. So having success matrix for individual brands, and then a common vision as a whole, right? I want to increase my personalization or the way I'm giving content to my users, the increase, right? So all of that, you kind of define the outcomes will be of your discovery to actually successfully mark closure of your discovery. So broadheads in terms of technical, in terms of process, I'll talk briefly more about these and in the coming slides as well. But yeah, I think that's the final step before you actually get into a discovery meeting. So I'll take a pause here. I think few more before I take a pause is just put in here just for your reference, if you check this probably months afterwards. There are a few more things that have worked for us with different customers, which you could use. If you're working, you're doing design thinking as well. It's important that you send out some questionnaires out. I've put in some questions here that that could work like what's your existing strategy, right? How's your three years goal? How's your customers doing? What do you feel are the hero products for your customers? Where do you want to be at, right? Or your strategy, for example. And where do you want to what what is the ROI that you're kind of driving? If you kind of have the numbers already, you kind of work backwards through your portfolio. And mind you, this product project was a 23 months long project. And this is the first step to it. If you have, if you have taken the right steps, if you have a numbers to work with at the very beginning, it then helps you in the entire duration of 23 months, right? And then you work backwards, make sure that you have what you have achieved at the end of the portfolio for individual brands, right? Because there are a lot of times your stakeholders would say, hey, are we going in the right direction? Is this portfolio actually successful? Are you actually delivering enough value for us or not? So all of that matters. So having all those well defined earlier with each KPIs, if you're working with non-functional requirements, what is the accessibility score you're looking at, right? Or what is the SEOs that you target to achieve, for example, right? So all of that, if you have already in place, would actually help you. Likely on the similar lines, this portfolio account map as well, so while you have defined the teams, another thing that helped us is kind of do A to B mapping with how the stakeholders of individual teams are and who actually maps to whom from your vendor side and also from the client side. How it helps you is while you're on a long discovery and a long project implementation, you know who to reach out to and you know who are the key stakeholders looking after what, right? So that it also helps you have a refined meetings, a refined people, a list as well when you're going along, right? So some of these that we had, right, like from technical product process, these may vary based on your case to case basis, right? I've removed the client's name just in the interest. And then there is tools, right? So I've listed out few of the tools that we used. These are just for references, not our recommendations. But since we're now all remote, it's important that we kind of use certain tools that helps you drive collaborations, right? So these are some of the tools that we used for taking notes, confluence, decision trees, right, that you have. It kind of works wonders because you're doing remote. There are things that are discussed left, right and center. And you also want to make sure what decisions you took. So confluence was one of the life saviour for us, where we use decision trees, what are the key stakeholders involved, and what decisions we took, right? And likely about collaborations, Myro worked wonders for us. There are a lot of tools in the market as well, not advocating any of it. But just saying that there are a few of the tools that work out for us as well. And lastly, the setup of Ray C matrix. This is also important, like when you have done the mapping of stakeholders, it's also important that you define who does what. And Ray C does that brilliantly, where you have defined who is responsible for each of these items. So you could have a person who's going to sign off on the UX wireframes, for example, for individual brands. So if you have that person defined already, that will help, that will kind of ease out and also tell the person that hey, you are responsible for it. So you should be well aligned to it, right? So if you have this very clearly defined Ray C for individual brands, that also helps. So this is all before your discovery have actually gotten. But this may sound like a lot of work, but believe me, this is the actual work. If you don't get this step right, the remaining part of the discovery might become unproductive and non actionable, right? So yeah, I'll take a pause here if you have any questions before we move into the execution of discovery. Yeah, go ahead. Yeah, so his question is, how often do we come back to the responsibility matrix through the course of a portfolio discovery? Because in certain scenarios like he mentioned, it's just created once and forgotten. So how we approach it is this is a really powerful tool and difficult to maintain, I agree. However, it's important that you continue to maintain this because like for example, if you don't have a UAT responsibility assigned to the right product owner for a brand, it might just go places, right? You have your scrum teams working like five sprints down the line and there's no UAT signed off done, right? So that's a risk to the project. So for us, this has worked wonders. We make a point. So Scrum Masters try and make sure that if there's a change in alignments on any of these, those are well updated. So kind of confluence has helped and with portfolios if you're working, making sure that these are all shared and well updated would actually make sense. Yeah. Thanks for the question. Any other questions? Okay. So now we move to the execution part of it. Now that we have done all the planning, all the hard work in terms of getting into the discovery. So next is actually the execution, right? At the ground level in discovery and I'm talking about portfolio, right? Just for reference, right? So some of the key things that I've kind of mentioned here that you can take note of while you're doing and actually in our discovery meetings. So first is while in the meeting, right? We observed that during meetings, oftentimes we were running more, more than the stipulated time. And there were a few more agenda items to cover. So making sure you have something called a plugin timer. If I go back to our meeting, if you look here, right? Where you have these timers defined about individual items. Often they're not, we don't actually follow this. We might be going five minutes over or five minutes less as well at cases. But having a plugin timer, someone invigilating in terms of how we are progressing to the agenda items would actually help. In case we are running short of time, we kind of make sure we park those items and use buffer sessions in your calendars, right? We had buffer sessions through the days, through the weeks as well. So any, any pointers that have been missed out or any additional items that came in while discussing, you could use that car park lot. We used conference for it. You can use any Excel or running sheets of the topics that came in the discussion and needs further discussion. So car park is one thing that acted as a boon for us. Next up was asking attendees to drop off. We generally don't do this in person to push people out of the room but with remote. I mean, we have to vary of the time of people, right? We have to understand that it's a high stake game and we have to respect time and be productive as well. So few things we can do. We can do breakout rooms. So Zoom does that brilliantly. You can have parallel sessions with multiple teams, different stakeholders at the same time. So that saves time. And second is dropping off, right? Don't feel shy to just carry the long tail forward on your calls with long calls you're having and, you know, some of the stakeholders work is already done. They're not contributing anymore but they're still on the call hanging around, right? If you feel that they're not needed anymore, you can always advise them if they feel free to drop as well, right? If their part is done and if they feel that they're no more contributing or they don't need any further information on the call. Next is cameras on. So this is one interesting concept that we learned through the mist from last two years. There's a concept called social loafing that did the rounds quite often from the last two years in the pandemic. It's actually a notion for people to often get distracted when they're on remote calls or in groups. You have lesser percentage of responsibility, I would say, when you're working in groups or when you're on remote calls, you tend to kind of try a WhatsApp, check your WhatsApp or, you know, what's happening on your slacks or different messaging tools as well, right? So you can, people have that tendency and I'm guilty of that as well, right? Where you have the tendency that, hey, my work is done on this call. I'm still there as an inactive participant. How about I check my Slack messages or finish some of the work that I had, right? So that was the case as well, where we had a lot of inactive participants to begin with, right? And then we kind of got this feedback, right? That we have a lot of people but they're not contributing enough and it's not engaging enough as well. How do you do it? So though we had this thing always on, right, that you should have cameras on but it was not kind of asked too much but we kind of made it one of the meeting etiquettes that if you're coming in, it's always better if you have a meet cameras on. We always cut some slack around if you want to take some breaks as well but cameras on always help if it gives you the face to the voice as well and also avoids this social loafing that I'm talking about. So yeah, and lastly, I think breaking room, break rooms I've already spoken about. After the meetings, right? Another important thing is you kind of, we all have been doing this, right? Minutes of meeting, sending out the clear action items and meeting recordings. But if we kind of extend this further and say we have 150 plus meetings through the portfolio, it's really difficult to manage all of your MOMs, right? All of your action items. How would you do that, right? So that was one of the challenge we faced and how we evolved is we kind of had a running reckoner list with each brand we were discussing, each functional teams we were going with and made sure we have the right side of action items defined, right side of stakeholders and due dates defined as well, right? And a common place where we know, okay, this meeting has been done, what are the action items, right? And that action items also goes to my action items repository, right? Which further gets tracked and likely as well about what are the meeting recordings that we have done as well. So for people who have not joined in, we can also do it as a reference. Next is summarize and retrospect. While you're doing discovery meetings each day, we felt that are we actually going right or not, right? Because we're often not talking to the customers, we are just discussing with your stakeholders and individual meetings, but are we on the right track, are we doing enough, right? So we made it a point that we had a buffer time fix at the very end just like a daily scrum, a 30-minute daily scrum, wherein you can sit with your client stakeholders, a few of them kind of daily scrum just to reckon about what we have done right, what we can improve in the coming days, right? And some key action items or dependencies, right? Which can be solved right away during that call, right? Or could expedite it? Because while you're in a portfolio, there would be times that there are a lot of action items and dependencies which is blocking the team, right? So it's equally important you have this everyday retrospective, 30 minutes kind of a daily scrum at the end of discovery where you get all this information. So this is what we use, right? This is one of the idea board that screenshot I placed here, you know what went well, what didn't go well, what can be improved, right? So one of the items that we felt and this came out from there itself which was the meetings are running over, the stakeholders are complaining that, hey, I'm often spending 15 minutes more and I'm late for my next meeting. How do we solve that? So glad that we had this summary and perspective every single day. So when we just kick-started the discovery, we had this initial feedback very early on and then we kind of course corrected and went along, right? So that's the second step, right? Thirdly is a weekly governance. So now you have done a retrospective daily. It's equally important that when you're doing portfolio, right? And a portfolio discovery which is spanned across multiple weeks, you also want to share it to your stakeholders that how as discovery has been progressing through weeks, right? So just bringing this slide back, right, that I showed you earlier, how has the week one gone in, right? And then use possibly any kind of tool for radiating. So I've placed here a RAG status kind of a place with red, amber, green kind of statuses, what's going well, what are the highlights of the week, what are the low lights and mitigations, right? One of the key things that came out with this for us is kind of you're collaborating with your customer, right? You kind of go into these meetings and kind of find solutions for your problems. So since I mentioned we were in the midst of pandemic and you're doing remote, some of the members were not available, right? And it had a potential risk on the overall timeline from the discovery. We kind of amicably discussed it together on these calls and kind of find the root cause on, you know, how we can find a backup team and we can how we can move few sessions here and there to make sure, you know, the overall timelines are not disturbed. So that's the status and few other documents, right, that can be created. One is raid logs very frequently used, right? Radiating the right risk at the right place, the dependencies, issues and assumptions, keeping open action, open items list at the end, right? With each brand and each due dates and owners defined would help as well. Yeah. So that's about how you kind of execute your discovery, right? When you're running meetings or what you need to take care of. And while you're in the process of your discovery weeks, what things you need to take care of. I'll take a pause here if you have any questions. Okay. The last section is a few outcomes, right? So I have a place right after you have done your discovery. If it's a portfolio, remove the logos here intentionally. So but for us, we kind of have had a roadmap around quarters, how we are delivering across quarters. And then further radiating it about how we are delivering about each phase, how which product goes when, what gets delivered when, probably a vision and then kind of come up with a portfolio kind of timelines. So as I mentioned at the beginning, we are discussing visions and requirements with each of the brands and then going with the focus brands. Since we have gotten some information, you can use some ballpark figures or estimations like T-shirt sizing, where you can get some estimates are out and timelines about how your product portfolio would come up to. So this is, I've hidden the brand names, but this is how some one one portfolio timeline looked like for us, right? That you can use. And then last couple of things, deliverable summary, right? So we did see a slide about outcomes, what outcomes are expected. It's equally important you continue to show what outcomes have been completed, right? Like for us, one of the important thing is what we need to use for Drupal, for example, right? Since one of the key things that we're trying to solve is lesser clicks, the more visible kind of features and easy previews of content for editors, right? So kind of we had a lot of deliverables listed as well during the start of discovery. So when you're kind of going to the end of discovery closing it, you kind of show a reconner about what's in progress, what has been approved and what has been delivered. Similarly, there is a decision log. So this is a screenshot from Confluence. So we created decision logs as well. So Confluence has a decision tree where for any decisions that you've taken like from base distribution, right? Or you want to go coupled or decoupled for certain brands, right? It's a big decision to take as well because MediaCop had few products which had web apps, but some visibility around how they're going to go decoupled or do they want to go in a couple strategy? So it was there. So having a reconner on this also helps. And then a canvas of individual brands, what is the key pay eyes and key KPIs of each brand and what's the success matrix look like? Lastly about the challenges and planning. So some of the key challenges I've mostly discussed about all of them, but some reconner to take care of. We found hard time finding common time slots for stakeholders. So what we did is we kind of worked with them, gotten prior approvals on what slots work for them. And then once we had the calendar in, we sent it out for approvals even before the discovery so that they're available during the sessions. Though it always doesn't work the way we planned, there were some modifications through the midst as well, which we kind of managed it with buffer sessions that we had. Sticking to meeting timelines, as I mentioned, timers, keeping the audience engaged, try asking them to skip the meetings or use breakout rooms whenever needed. Accommodating public holidays and unforeseen circumstances wherever meetings are changed. So buffer sessions do help. Common communication platforms. So since we were working with 15 plus stakeholder teams, we found it hard. It was an information overload with different teams discussing different things. So tech teams discussing left, right, center, right and product teams, UX feedbacks coming in as well. So Slack worked wonders for us. We created different Slack channels by vendors, by clients. So we were working with different vendors from AppSide who were responsible for iOS and Android and then different vendors as well, right, for different things. So we kind of created communication channels based on functional teams, right, and kind of segregated the discussion, obviously having governing bodies in individual channels as well. And then this one was mostly for discovery teams. So your discovery teams might get overhauled with like four to five weeks of discovery. They said we don't have time for processing. There's so much overload of content. How do we process it, right? So we made a point that, okay, let's keep the discovery maybe five weeks, but make sure that we have enough time to process the information, right? So we used to have sessions in the first half and second half was mostly around pre-processing and working as a group together to kind of work on the outcomes. Yeah. And lastly, I think giving face to the voice, right? That's the biggest downside of working remote. You kind of miss that interpersonal connect. You kind of feel that, hey, how do I give, how do I get that trust from the customer with all, you know, behind the screens, right? So having that cameras on does help and playing some engagement games, right, the beginning itself, a guys breaker, right, know about each other, not just pure business, knowing about each other at an informal setting, probably, though we can't like meet over some bar or something, but yeah, possibly an informal setting could be done where you can give face to the voice and have some trust building as well. I think, yeah, so that's the story. So this is all it came down to. I hope I'm finishing it on time. So this is all it came down to. So we had eight plus brands, right, 15 plus stakeholders group that we worked with, right, through the process. It was 23 weeks, right, or 23 months of project with five weeks of discovery. And kind of this is what I've presented today is the recipe of, you know, what worked out for us. And kind of, we did have a very strong foundation early on as well about how we go about discoveries. But this was different because this was all remote. We had to kind of re strategize fall, get up, learn and again, repeat, right? So that was our strategy. And our honest intention was to kind of give back to the community so that you can use this as a reference. And in your project setting, just use this and possibly go about building great products, right? Because eventually, if you build great products, the community wins, right? So that's the intention. Thanks a lot. Yeah, thanks for listening to me patiently. I'm open to questions if you have. Yeah, please. So question is about rag status. I mean, you're sending it to customers. How do you identify which category do you belong to? Red, amber, green. So our honest approach was dependent upon what is our low lights, you know, what are we struggling on? How are we progressing? So a very clear definition or how you can define a rag status is based on the outcomes of each week that you kind of defined when you're defining themes of each week of your discovery. It helps you then look back again, are we actually aligned with that week, right? You look back, okay, these were the outcomes planned for the week. Have we actually delivered, right? Or are there any blockers? So that's how you kind of define where are you actually are you at the green zone or red or an amber zone, right? So there's no strict rules around it. To be honest, but based on the outcomes expected, based on the themes that you have placed at the very beginning, you can appropriately define. If you have like a lot of risk, your teams can't move at all. You don't know where the discovery is going. Definitely it's a red flag that you should go on your teams. Yeah, thanks for the question. Yeah, please go ahead. Yeah, so our question is, since we were dealing with a lot of stakeholders, how do you kind of help solve problems where the stakeholders are not aligned to each other to help drive decisions? So one of the key important thing, I think, which is towards the end of the slide is the decision summary, right? I'll possibly place another slide here that would help show how the decision trees look like. So generally, when we are in a in a in a in a person setup, right, when we are meeting in person, you kind of discuss it with the stakeholders in person. But sending out emails, conversations to and fro becomes tedious, kind of come to a conclusion. Decision trees actually helped us a lot. It kind of has what is what is topic of discussions? What are the approaches that we are discussing here as alternatives? Who are the stakeholders involved? Who is the decision authority and what is the final outcome, right? So it's all in confluence. You get notifications with everything that's as as it progresses as the decision progress further. You kind of take that decision around it and eventually sign off on that decision tree. So one of the use case that we had was, it was about content sharing. So MediaCorp does a lot of cross content sharing as well. Like like entertainment content would show up on the news platform as well. So different brands. So they had a lot of content sharing across different brands. So we had to define about what strategy you want to go with for, you know, for content sharing. So do you want to use different CMSs or do you want to use just one CMS for like a content sharing for editors, right? Where they want to manage content of individual brands as well as kind of to cross sharing as well. So decision trees work wonders for us. Any other question? Yeah, please go. Yes, thanks for the question. So sorry, I didn't catch your name. Shane? Jane. Okay. Thanks for the question. So Jane's question is that often working with product teams, while we are in the discovery sessions, there's a limited set of information that you can gather. And then while you're working with your agile teams, you go through story refinements, you kind of get more requirements. So how do you kind of manage the requirements and the scope changes through the process? Have I got your question correctly? Yeah. So absolutely, right? So we all work in Agile and with Agile mindset. We open to change. We work in a VUCA world. Absolutely. And so the idea with discovery is actually to get an idea about a portfolio, you know, what is actually needed as a whole, right? If you can kind of give a ballpark figure and kind of get a scope defined early on, right? Basically to come up to some, some level of story points, right? That you want to actually deliver to your customer, right? And then once you have defined a specific scope, right? That this is what you want to build for this brand. And then we're still open, right? As you then iteratively go to that brand when you're discussing it, you again kind of reassess what you had earlier put as a ballpark figure for this brand on their portfolio. Does it fit in your timeline? Is it actually increasing? You kind of do some planning around, you know, what has actually changed, right? Can we move around few of the story points from, you know, the earlier scope that we have defined on, right? So early on, in the discovery, it's important that you have some level of scope defined for individual brands, right? And then when you are actually going into an iterative discovery for that specific brand, you further deep dive and actually harden the scope, right? Which again is open to change. But then it's about, you know, how, how well you manage the number of story points and the scope that you have put in place. Yeah. Thank you. Did I answer your question? Yeah. Thank you. Any other questions? Okay. Thanks a lot, everyone. Thanks for listening patiently. I hope this session was useful to you. Thank you. Have a nice day. And just lastly, we are in the exhibition hall as well. Please stop by the Streogen booth. In case you have any questions, if you want to brainstorm together on any of the use cases that you're working with, right? If you're working, so this is a scaled-up version, probably on a scaled-down version, if you're working with one single product, multiple products, how we want to strategize. We're open to like collaborate together, think about and kind of solve problems together as a community, right? So feel free to stop by or write an email to us as well at Streogen. All right. Thank you. Thanks a lot. Have a nice day.