 Hello, everyone. Welcome to the webinar, How to Launch a Big Idea from Inception to Implementation. I'll be your host during the next 30 minutes, and I hope that you enjoy this webinar. Before beginning, I'll make a brief introduction of myself. My name is Sergio Luna. I have more than six years in Proc Management, Building Multilingual Personalized Customer Experiences in the e-commerce and OTT video, both B2B and B2C, across different markets, both in the American continent, EMEA and APAC, driving top and bottom line impact. I mainly focus on buildings 0-1 experiences at very early stages of product development, focusing a lot on automation, building self-service capabilities, as well as scaling. I also do career and PM mentoring, both inside and outside my daily job. On a personal note, I'm a creative writer, poet, and amateur artist as well. I'm currently a Senior Proc Manager in Prime Video at Amazon. Alright, so the agenda for today will be a combination of product theory with a bit of a real example of my personal journey of building a product and scaling that from inception to implementation. I'll first touch a bit on mental models, which is a part of product theory, and then I'll walk you through the personal journey of me launching a product through each one of the stages of product development, finalizing on the product launch. And finally, I'll wrap up with three key takeaways from this webinar. So let's start talking about mental models. Mental models are a simple representation of reality of how something works. It's a way of an abstraction of that layer of reality. And as Proc Managers, we rely a lot on mental models, even if we don't know it sometimes. For instance, we have mental models around prioritization, around product development, around user research, around experimentation. I think the work can be sometimes called frameworks. It's always having a way of how to make sense of something, right? So it's very important that as Proc Managers, we realize what are our mental models. How do we use them? There's no single mental model for anything. I don't believe there's a silver bullet for everything. And I think you can exchange and update your mental models as you grow, as you change industries. I think the important thing here is to at least be aware of what your mental models are and what are the other mental models out there that you could also leverage. There's a quote from Charlie Munger that I'd like to share. He's one of the co-founders of Workshare Halfway with Warren Buffett. And basically he says that in order to make sense of the world, you don't really need to remember or memorize the facts, but rather you need to understand the structure of how things work and that way you can relate better on how different aspects of the world work. So for instance, he has mental models on drawing from physics, from economics, from psychology that help him to have a better grasp of the financial world, which is his specialty. So this is a mental model that I like to use of product development. I did not create this. This is something that I heard in a PM conference some years ago that I thought was clever, was very simple, and that I've been using since then. And it basically has four different steps, ideation, socialization, MVP or minimum viable product, and then the actual product. And what is interesting about this model is that each circle, each step sort of overlaps with the next one in the sense that while you are working on the ideation, for instance, there will be a moment in which you will start socializing your idea, but it could be that you go back to ideation. So there's a sort of handshake between each stage in which you will then move to the following step and continue the same process. So it could be that after socializing your idea, you realize, hey, it's not time to build the MVP. Let me go back and socialize again, or let me go back to the ideation phase because I realized that an assumption was wrong. So this is like this continued flow between stage and stage that is not really fixed. In reality, it is a bit more intangible. It's not really a clear cut. I'll give some examples later on in the presentation, but I really like this mental model as a way to make sense of where in your journey as prog-manager are, where in the journey as a prog development your product is, and that will help you identify whether you're ready to go to the next one, you need to stay or maybe move back to the previous one. So in the first stage, ideation, this is where the magic happens as I like to say it. Here's where you start discovering different problems. You start imagining what solution could look like. Here's where you can do a lot of UX research, speaking with different stakeholders, be very creative on defining different hypotheses. I like to see this stage as like a white canvas where you just go there and brainstorm. You can do some white boardings sessions. You can draw, you can write, you can perform. It's very divergent in the way of not really caring where all this is going. It's just about generation, generation of different ideas. I like to set some time aside to think, to have an hour, one hour, would you really zoom in into a problem and try to evaluate, well, what are customers saying? Is there an opportunity to grow the business in this direction? There are other solutions, products, what are other companies maybe doing? There's this new technology called Blockchain. Let me go and invest a bit more and understand it and see how that can help us or not. There are some frameworks available that can help you with the ideation. One is Design Thinking and Lean Startup. Again, these are frameworks or mental models on how to go about generating new ideas that you could also go and leverage and take the best out of them. So basically here's where you start going from zero to, maybe not one, but to something. As you move into the product development model, you go into a socialization step where here the idea is to share your ideas or your proposals with the world, get different perspectives. I personally like to put my ideas in writing and start sharing them even if it's two paragraphs, one paragraph. Realists are very frugal and just try to validate whether you're after something, maybe someone else is already doing what you're trying to do, maybe someone else faced the same challenges, but you want to discover that really quickly, really soon, right? You want to avoid that case where you're already building something, you're relaunching something to then realize that another team already launched something similar or they knew that that wasn't going to work because of XYZ reasons. So no matter how small your idea or how far-fetched your idea looks like, go and share it, right? You can just write an email, one, two, a few sentences, share it with some close colleague. This makes sense. Let's go. Let's have a coffee chat and just discuss a bit further. It doesn't have to be very structured. I like to start with my close circle, like my colleagues, like my internal team, and as the idea gets a minor shout, then start sharing it with broader groups like external teams, international teams, peer product managers, right? That can bring this diverse perspective. The idea is to incorporate their feedback, their inputs, pay close attention to, especially those who disagree with your idea, what are they disagreeing with, what are their arguments, and try to answer their questions, right? If there's something you cannot answer, then that's a signal that you may need to re-evaluate your idea, or maybe you need to dig up more information, more data. At the end, the objective is to align on what the business problem or problems are and potentially, even if it's not very solid yet, product vision on how to solve it, including some ideas on the MVP, how the development could look like, and again, there are some collaboration tools that will help you with this association that like Google Docs, SharePoints, Slack, there's a lot of them, right? Here's more about being flexible, being quick, and gathering that feedback promptly. Once you have that sort of validation or have gathered a lot of inputs, then it's time to test your idea in a quickly and a low-cost manner. So when you build the MVP or when you're approaching to build the MVP, you ask the question, what is the problem you're trying to solve, and more importantly, where are the hypotheses that you have that you want to validate? My recommendation is that during the MVP, you have to collaborate between product development, design teams, you should not embrace this individually, right? You have to call out also, what are your assumptions, your risks? There will be a lot of ambiguities during the MVP, and that's okay. The purpose of the MVP is to dissipate some of that ambiguity, uncertainty, and have a higher level of confidence that whatever you're going to build later on would have a positive impact, will bring value to your customers, will bring value to the business, right? But in the MVP, you have to balance between quality, frugality, speed. There's a lot of time in building something very, very nice, very fancy, but that might take you one year and you don't want to wait that long to validate a hypothesis, right? So how can you be frugal? How can you leverage existing technologies? Do you really need to have a back-end service or is there a way where you can sort of trade off a bit that quality aspect with the sake of speed, but at the same time, validate a hypothesis? Which is very important to mention in the MVP that your MVP is not your product, right? It will not deliver the value that you expect to customers or to businesses. You need to set clear expectations about that with your stakeholders. And another thing you need to be aware of is success metrics are not the same as hypothesis. You may have 10 different success metrics on how you're going to measure your MVP, your product. It could be engagement, conversion, retention, whatever, but maybe the hypothesis at the end is are customers able to engage with this new type of technology, right? And that's different. Your success metrics will help you answer your hypothesis, but the main thing is you need to be aware of what your hypothesis is and your hypothesis more often will not be I can drive 10% engagement. It could be, but oftentimes it's a bit more higher level, more abstract. Obviously you need to capture data from your MVP both quantitatively and qualitatively. Again, going back to validate that hypothesis and answer that question. There are some frameworks also for how to move fast and iterate and all that. Agile development is one of them, but again the main idea in the MVP is to figure out what's the minimum feature set that will be. How are you going to measure it and go and build it? Lastly, you have the last stage which is the product or the product launch where now you go for real, right? You have incorporated your feedback from the MVP. You've analyzed what are the pain points, what are the must-haves that should have the delighters or nice to have from the customers. You may also reassess what are your priorities in terms of features like your P0s, P1s, P2s based on that feedback and those learnings. Here what you will end up doing is having a more expensive investment. You'll still have assumptions and risks, but you'll have a higher level of confidence that whatever you're building, whatever the progressions you have is going somewhere. There's some alignment. There's some product market feed. You have some validation and that, right? If you want to go beyond just that MVP you can start defining your performance KPIs, inputs, outputs, how do you measure economic performance which may not be that important or should not be that important during the MVP and especially how would you continue measuring throughout times depending on your product every day, every week, month or quarter whether you're adding value or not and whether you need to stop pivot, re-evaluate, go back maybe to the definition or not. Again, as many say launch is only the beginning you're far from over in the journey but at least it's one big milestone from that zero to one experience or how you want to build something and make sure that PKD that you have resonates with your customers. So now I'm going to shift a bit the mechanics and I'm going to walk you through my journey of launching a big idea from inception to implementation and I'll be touching upon each of these four stages of product development but making reflection on my own experience and to give a bit of spoilers ahead so this example is how a small idea of building a chatbot resulted in building a chat platform across multiple countries across multiple languages building a team from a few engineers to almost ten engineers including content moderators having funding from different teams having higher visibility influencing different parts of the organization having broader goals in terms of the impact and customer experience so it all started with with a question how can technology help me solve business problems before we have very manual standardized processes that require a lot of time that were not scalable, that were prone to errors, that was not possible to learn from those interactions so how could we use technology to scale that to standardize it a bit more to maybe automate some parts of it and bring more value to our customers and to a company and I wanted to have a more tech-driven approach to our solution because in the past it was more business-driven like, hey, we have this problem Proc Manager help us how to solve it, so I wanted to include my engineering team more in this ideation stage so what I did is that I collected a short list of 15 different pain points identified by my business teams very rough pain points like productivity related or hey, our tools are very slow we need to wait x days we're seeing these problems with our customers that we don't know how to solve so it's a very high level, we just get a sense of what was business facing and then I met with my engineering team that back then was based in India and I ran a series of brainstorming sessions where we discussed what is the business context, I gave them some overview of where was the business going, what were the main problems, what were the processes what were the main key stakeholders what were the different projects already in motion and at the same time there was a different session a whiteboarding session where we went one by one each one of the pain points and we were exploring what could a solution could be for that, we were time boxing the discussion and just to get an initial idea of what could make sense from a technology point of view so basically in other words this was more meant towards divergent thinking, just write down different ideas and where we saw a bit more of opportunity or more excitement then we may spend a bit more time there just to flesh out that idea a bit more after that the output of that session was a two-pature with a high level business problem and how the solution could look like, this was very very generic rather than specific, there were two or three ideas that were the best ones based on our own assessments one of them was to build a chatbot just in specific technology because it was a good way to increase customer experience we're also scaling our operations bringing productivity impact and so on and so forth and what I did with this two-pature was to start socializing that with my internal PROC team then with my brother's business team my reporting line PROC peers in different teams, different organizations with engineering different engineering groups and also cross-functional teams that had nothing to do with my organization but just to get that feedback the learning was very important because one, we realized that no one else was building something similar, there were no in-flight projects there were no overlaunch projects in the same dimension so there was no redundancy in that sense two, a lot of people agreed with the idea we can see this working this could work with our line of business or hey this sounds good but cannot really work with our line of business because XYZ reasons so there was a lot of appetite and buying from different stakeholders and even though they didn't contribute with I can bring you an engineer or a designer to help you with at least I already knew that I could go back with those teams and partner in the future once I had launched the MVP and the product because I already got there buying and this is very important especially when I went back to my leadership team asking for funding, hey we need to build this, we need to prioritize our roadmap let's go and build an experiment next year it was very important for them to hear that all these other teams and stakeholders were already considered and that they didn't have any blockers so that really accelerated and made that discussion with me leadership but hey we have this big idea we want to start small we need this amount of the size of a team help us build it, this is the plan so in other words the socialization aspect of this project also helped going from a divergent thinking where we were really thinking out loud into something more now or more converging into an actual solution with a specific look and feel so after socializing my idea leadership approved the funding of it and we set on the task to define and build the MVP so I think one of the interesting parts here is that at some moment I asked myself the question well how do I even build a chat but how do I start by defining the scope I want to deliver value but also at the same time being frugal and I also need to build for scale because if this works how are we going to build it in the future at scale right down and start kind of drafting a business requirement with different features a bit of the vision, the narrative I ended up building a 20 pages document with a lot of different details on how to go about the MVP I received a feedback from one of my senior business stakeholders hey I'm not sure what you want to build I'm a bit confused like what are we talking about here and at the same time as I was discussing this with my tech partners there was a strong appetite to build complex and fancy features from the onset like NLP, natural language processing or machine learning there was a lot of eagerness to explore those areas of technology because they're exciting right and it makes sense but from the onset so I had to sort of figure out how to manage how to solve these challenges for the first one I knew that I had to simplify the scope and what I did was once again creating a mental model for that feature set that I didn't have before and what I realized is that it was way easier to make sense of what I wanted to build and also to communicate that if I could divide the feature sets into four different modules which I called UI content systems integration and targeting and then under each one of those really specify what are the P0 features needed for the MVP, what are the nice to have the P1, the P2 and so on for example at the very beginning we thought that we had to integrate with some internal systems to how to generate some tickets and some sort of alarms and therefore we needed to integrate our app with those other applications but in reality it turned out that really P0 feature after discussing with business team, with the account management team we realized that there was a way in which that could be a semi-automated workflow in which someone could create those tickets manually because that was the business as usual process and that would have a lot of impact on productivity but it could help us to move faster and avoid investing X weeks when integrating with those systems we didn't know if there were IPIs available and so on so that was one example of how having that mental model helped me really understand what are the minimum features for each one of these modules at the same time it helped me also to better communicate with tech because I was creating the user stories under the lenses of each one of these modules and what I realized is that at the beginning NLP ML was not part of the initial feature set, those were more nice to have but at the same time what I realized is that leading with the product vision of how the product could evolve in the future and then at the moment start investing on NLP ML all these other fancy technologies really helped my tech team to understand that progression, that evolution and have their buy-in and say we're not going to include any of these fancy technologies but we know how the product can evolve and therefore here's the best way in which we can design it and also help them to keep them engaged and sort of trust in the product and the idea with this is also change a bit the mindset of not going super big at the beginning but instead focus more on building proof of concepts, prototypes and see if that works, put that in front of customers get the feedback on iterating into it and again it's more about raising the level of confidence rather than going crazy from the very beginning so after all this discussion and rescoping of the MVP at the end I ended up defining the MVP of a chatbot and I'm putting quotes because it was in reality more of an interactive wizard rather than a really intelligent bot powered chatbot, it was more a click guided experience but at the end turned out to be a good option because it allows us to move fast I suppose of having investing in all these other technologies so once the scope for the MVP was defined then it was a moment of developing and one of the things that really helped me to keep track and make sure everyone was on the same page was to designate a core team of myself, a product business players and also tech players who would make all these low level decisions in terms of how should be the copy here, how should be the copy over there what type of colors, the UI things that do not require leadership sign off because that will slow us down and just to move fast right so it was a very agile team that was meeting once or twice per week and making all these different low level decisions I felt that that really helped with the progression we also had mechanisms for progress updates weekly by weekly status updates via emails or some other formats just to keep my leadership team aware take leadership aware of the progress over the different options that we were reviewing and the different decisions as well and finally creating a go and no go meeting prior to launch with leadership with everyone where we went through the entire conception of the product from the UI all the way to how we're going to capture metrics measure success which are the customers that we were going to invite to this kind of beta program in a way and the idea there was to get a green light and then we're going to onboard it of how the MVP could look like so then came the moment to launch very important moment in prog manager career when you hit the button let's go live and let's start looking at the results here what was very important is to capture that customer feedback both quantitatively and qualitatively I cannot stress how important it is to really get close to your customers to really speak to them in this case what I did looking at the quantitative data like the behavioral data I started calling customers and I would have a one hour call sit with them and really share my screen hey this is the experience what do you think you're already engaged with it this was the results we just want to understand a bit more in detail in depth why do you perform certain actions or what do you think when you read this this specific message and that gives us a lot of breath in terms of understanding what was the actual interpretation of the customer of that product to the most part it was consistent we were seeing in the numbers but it's always very powerful to have an anecdote that tells you hey I really like that you're investing in this area I can see the potential benefit that this will have in my company you're not there yet because you need to invest in content you need to invest in these other areas but I'm grateful that you're investing in this let me know if you need something else I can help you with so it was very valuable to hear that from an actual customer validating the idea in itself and also validating where are the areas that we needed to invest a bit more once again one of the big learnings for us or for me was that it was not really clear from the beginning what was the purpose of the MVP so after we reviewed the results we saw high engagement we saw good conversion we had positive feedback overall from our customers and we were seeing a lot of financial impact and during one meeting we were reviewing these results one of my senior business stakeholders asked me the question should we continue investing in this product if it's not bringing in any financial results compared to other initiatives we invested X amount of time and resources building this but it's not really moving the needle in our business why should we continue investing the year that comes so that was a question that I was not expecting and now I know how to answer or to avoid to start with and the answer to that question is that the MVP is not about bringing financial impact moving the needle being a game changer right again the MVP is a way for you to quickly and as a low cost validate the hypothesis which are different from the success metrics in my case one of my hypothesis to validate was are customers able to engage with this new channel because it was something new for them are they even receptive to this new experience or would they not be touching it at all would they be confused would they have different expectations and the success metrics helped me to answer that question if I'm seeing a high engagement it means that yes if I'm seeing a good conversion it means that they are even deriving value from it it's not only that they are able to engage with this new experience and then the positive feedback regarding it continue investing in it so success metrics help you answer that question that hypothesis but it was not really clear from the beginning so I should have done a better work at setting those expectations from the upfront when I was creating the MVP and I was driving my prohibition that was not very clear from the onset so after reviewing these results my recommendation was to continue investing and move away from the MVP and really launch a more compelling product and at that moment I had to take a few steps back and redefine the scope really pay attention to now that I have validated the hypothesis and having some data that supports the argument that this product is driving value to customers and potential to a business what is the long-term vision of the product in my case it was a three-year plan however depending on the industry on the product on the company that could look six months or a year and for instance one of the things that I realized is that this could become a platform rather than just a standalone application in a very niche environment so how can we build this into a platform involving different capabilities more fancy things like as we were saying NLP and machine learning how can we improve what type of content how can we scale the content generation so things that you can then continue to go back to the to draw inversions like a mini ideation stage but looking more at the future now that you have a higher level of confidence in my case this required aligning with different stakeholders spoken in the past and then go back with the results hey this is what we are seeing this is where we want to go and with some of them I really needed to partner for instance there were teams that own specific real-state and in the gateway in the online page so I wanted to inject or embed that chatbot functionality in their real-state and I needed their collaboration and one of the challenges that I received was sounds good but how will your product will help me achieve my goals I have my own goals that have nothing to do with what you are telling me so why should I even collaborate with you why should I even share some of my bandwidth to help your team and that was one of the mistakes that I realized at the beginning where I did not speak that much with those teams up front to really understand what they care for and ultimately after some discussions it became evident that there was an overlap between our goals but it was not very evident from the onset and so one of the things we end up doing here is to figure out how we could have shared goals in which for instance my goal was to increase the touch points by embedding this application in a different platform whereas for them they were maybe having some goals around latency or how to decrease customer contacts and maybe that chatbot product would help them in that regard so how do I frame the goals and the features in the way that it helps them to achieve their goals as well not all of the teams were at the beginning there was some churn so that's why it's important to engage with these teams during the socialization step early on and once in this step I also decided that I needed to define better and more broader product goals again in terms of adoption engagement conversion but also in terms of business goals what are my projections in terms of revenue or cost savings or productivity impacts that I could have and that way also line with my business stakeholders and have a clear understanding of by end of the year we will achieve this much financial impact this is the customer impact as well here's the plan in each month in each quarter how we're going to expect it these are the assumptions and then have mechanisms to review that so that way you bring everyone on board everyone's in line with your plan and after that it quote unquote only becomes execution and communication of the different kind of results learnings that you're having throughout the year so in conclusion to wrap up I have three key takeaways the first one is that you want you need to understand what you want to learn from the beginning you need to be really clear with your hypothesis and you need to make sure that your different stakeholders are aligned with those hypothesis again hypothesis is not success matrix 60% engagement is not a hypothesis try to think of what are those more abstract hypothesis especially when you're thinking about big ideas things that are groundbreaking things that didn't exist before that maybe you don't have any reference point you don't have a benchmark so at that moment you cannot compare success matrix right so you need to focus on I want to experiment this I want to learn if this is true or not and here's how we're gonna do it and this is a time frame so you really need to be clear on those learnings from the onset the second one is as you grow into your product especially from when you move from your MVP to the actual launch of the product you will most likely have to partner with different teams right especially if you have bigger orgs if you're working across different domains different countries territories at some moment you will need to partner with these teams the best way to do that is having shared goals from the onset and bringing them on board from the very beginning so they are aware of what you're planning to do what you're working on and also ask them for their inputs in that right but ultimately in in order to drive better alignment and collaboration if you have a shared goal that both teams are responsible for that will be an intrinsic motivation to work well together and finally and this is something that I don't see happening that much is involve your tech teams your engineering teams to do that matter also design teams right in all product development stages they are your partners they are the ones who can bring a diverse perspective into a business problem right especially if you are trying to tackle a business use case or a business problem business opportunity you want to open a new market and it's very business driven bring on board your tech team give them some context of the PNL the different problems that business is facing and open the conversation to what would you do from a technology point of view what is out there that you believe could help us they will bring some ideas that you have never thought of believing that that's for sure try to change also mindset let's build quick prototypes let's do something very frugal let's build some wireframes and mock-ups and just put that in front of customers and they try to get that early feedback but again bring them on board from the beginning an ideation they are very a very good partner to bring new ideas also while you are defining your MVP scope and all of that they will help you tell you what is possible what is feasible what is the cause better way of doing it right so you don't have to do it on your own and all in all when you're trying to build a big idea and move from reception to to implementation I think a lot has to do with be really bold with your vision try to influence teams with that provision that you have how it could look like leverage visuals leverage data anecdotes and keep on iterating on top of that as you learn more as you get more feedback from your customers right I think when we're talking about big ideas that by definition maybe game changers or no one has seen them before it's very difficult for different stakeholders to really understand what they're about and what their impact will be so you really need to invest time on that sort of narrative that storytelling of how this could become something big and as you move on add and more data either quantitative or qualitative and again over indexing communication make sure that everyone's on the same page and just share the results right and never forget to also involve your customers and speak with them directly at every stage of the process never assume that the numbers that you're seeing tell the full story because sometimes an anecdote can surface things that the data will not tell you and that may make you reconsider change your strategy or pivoting alright so I hope that this webinar was useful and that you were able to at least take one or two things out of it I'm happy to I'm happy to engage with anyone who wants to connect with me I'm available on LinkedIn so reach out to me in case you have any question I'm always happy to start different conversations with different people so again thanks for your time hope it was helpful have a good rest of the day and talk to you soon thank you