 Hi, I'm Divya, I work as a PM in Microsoft and today I'm going to walk you through, based on my personal experience of how to ship a V1 product and I'm sure you're from the product school, you would have understood, you have a great understanding of how to build a product of features and things like that, but I'm going to talk something really different, like if you imagine you want to ship a product that is not there in the market and it's a V1 version, then what are the different checklists or the tips and tricks that you need to adopt in order to launch the product. So with that, a quick biography about me, as I mentioned, I'm a PM with Microsoft, I have worked on various areas of the product, like 18 years of experience, I worked on ERPs, ERM technologies, client server technologies, down to cloud and digital modernization. So yeah, with all my practical experience, I have jotted down a checklist to share with all the fellow PMs here so that we can all learn and grow together. Challenges on a V1 product, basically you need to understand who is it for, why is it important, what value are my building, how is it that is taken from the other products, what are the current in-market products that are providing, are they really not working well, not working well, where does my product fit into the market demography and what's your goal, what's the purpose of your product, it's very important. And then revenue projection, like I would say that comes last, first you need to really understand what team you're going to solve, what value prop you're going to get, then you can think about revenue, which I'm sure you have to meet your stakeholders requirement, but yes, make sure that you are very confident about your product. The checklist, it's about 15 checklists, but if you follow this, I think you will not feel that burden, but 15 is quite a lot, but yeah, it's very important that you're not delivering a feature, you're delivering an entire product to a market. So yeah, so let me get started with first on analyzing your market, you really need to understand your market costs. To create a successful product launch, you have to create focus groups, have to partner with your product marketing team, the duty of being in a startup is, you know, you get to do everything, you can become a product manager, you can become a marketing manager, you get to do your own campaigning, but if you're part of a big corporation where you have designated product marketing, you have sales and inside sales, then you will have to partner closely with them, under a lot of analysis, understand your competitors, you know, what merits and demerits of those in-market products are, again, validate your purpose, after doing all that research, again check, okay, is what I'm building, is that going to deliver value to our customers? And inform your stakeholders, now that you have identified a market opportunity and you're very excited, identify your stakeholders, like form a small four team, a V team that comprises of your, you know, your PMs, your fellow PMs, your engineering managers, your dev managers, and not only your, that's not the four team, because you're going to work day in and day out them, your print planning, your execution, your testing, so you all have to be like one team. Now, along with this four team, you need to bring your supporting team because this is all about go-to-market, you need to make sure you have the right infrastructure team, you have your sales, marketing, you know, buy-off, you have your support team, your operations team, or your product dependency, sometimes you're dependent on another team to build something, you know, so you need to make sure who those dependencies are, so form a supporting team at a very high level. And then product marketing team, as I mentioned, they will be like very, very early on, even to analyze whether this V one is in a good fit, right? So once you're identified and you're bringing them right at the beginning, you're bringing them along in this journey. And then finally, your cab team that is customer advisory board and they are your your representation of your market. So pick a diverse cab team, like saying your product is a generic product, right? Then try to identify a cab where you have a segment, a vertical segment where a customer from a hospital industry, a customer from a retail, from supply chain and so forth, and build as much diversity as possible so you get various feedback. Now that you've formed your stakeholders, the next important thing that we usually ignore and that comes and bites us once we, you know, become big and operationalized, you know, is not understanding your local laws and regulatory compliance requirements. You must have that as part of your design, your industry today is all about, you know, foundation of built on the foundation of security trust, privacy, you have to understand your local regulatory laws, such as like GDPR or European Union data privacy and so forth. So you have to make sure that you understand each geographical laws and regulations and should be part of your core design and make sure you partner and you bring your dev team along because you are engineering your compliance as part of your product feature. This is important because you know, customer wants to make sure that data are not being used for marketing or are not being sold to other companies, it's their privacy, so they want to take control of the data, they need to understand where the data is stored, who is processing, who is handling them and there are some restrictions where, you know, you cannot store a data outside of the geographical boundary of their presence. So if a customer is in Europe, you cannot store the data in the United States. So understand all of that and make sure where the data needs to be stored and processed and handled. Once you identify stakeholders, you understand your regulatory laws, you build a prototype because quite often what happens is without even building a pilot or a prototype, you go, you know, big bang on the schedule, we start pumping money and then you discover things, the roadblocks and that slides, right? Because you are as a V1, we have to be very, what do you call, usually in big companies, you don't market about V1 until it comes out, right? So you need to be very careful in building that closeness or keeping it a little secretive about what you're launching, you have to make sure the prototype will work by gathering lots of feedbacks from the marketing and their design team, sign an NDA with your customers, your CAP team to make sure that your ideas are being validated and just sharing with the stakeholders, make sure that whatever idea that you have, you have built a small prototype, you have identified unknown swell in advance, you have your hypothesis explored and you have done your basic hypothesis. So please, please, please, I can't emphasize, have a draft customer experience more in place before embarking in the big bang project. Once you identify your prototype, you have, you know, identified your roadblocks in advance, you know, and then you can carve a path, okay, which path should I take, like, you know, path A, path B, path C, all of that. And once you have identified, okay, now I have high confidence on which path, now I'm going to define what is my minimal viable product is going to be and what are my portfolios, that is my objective results. Without that, that vision of what your MVP is going to look like, and how are you even going to progress on MVP? It's not necessary that you want to build a big bang product and release it. You can release in phase, right, and the trick is you have to divide your MVP into sub features, where the feature set itself is cold enough for a customer to go use it and they realize its value and they provide speed back, right? So make sure that you divide your product into those milestones, confined to a feature set, and the feature set must be as ready, and it has undergone a lot of iteration in turn. And okay, this is super important because if you don't know what your success metrics is going to look like, then you will not be able to track your success, or you will not be able to track your progress in the back. So make sure that you have easy to measure your key results. For example, your key results will be, I want to launch this product in the United States, for example, and I want to capture 60% of my consumer market. What is a consumer market? Define that, right? Or you want to attract customers who are corporate customers. Then identify how many big corporate customers in that region, and what percentage you're going to attract those specs. So once you define all of that population and tell what is your success going to be, like your usage metrics going to look like, or how am I making sure that I will be thinking about 9% of the time available, how will I be able to see index of women look like. So all of that will be sure with targets start tracking. And then be open on your features and your design. Your foundation should be able to fail fast, learn from it, and move on. Your foundation should not change a lot. That's why I said make sure that early on you have a very strong security trust and privacy inbuilt, right? Because those are the external factors that will change your force. So make sure you have it as your design. And based on the features that you're iterating, right? Over the course, you may find that, okay, that feature, it didn't go well because customers give feedback, then you have to have ability to course correct the other feedback immediately and share it with their dev team, address it, prioritize it and release the next iteration. So that open to flexible design is super important. You don't need to be, you know, we don't need to understand or write coding, but at least, you know, you need to have the business and the technology and the architecture really well so that you are the voice to your dev team. And you are a customer for your dev team. So make sure that you have that a holistic understanding of the technology and business and the customer. Plan your infrastructure. So it's not just releasing features. It's the entire infrastructure that goes along with it, right? Because you need to make sure, like, if you're planning to launch globally, then you don't want to, day one, release the product across the globe, right? You need to first test it out in one region and slowly scale to other regions. So probably my recommendation is start small. Take one region where you are very comfortable with where your most of your cab audiences are, where you make sure that your supply chain and all of that, you have good connections. So you know that, okay, this region is easy to land and all that. So pick that region. If you're planning to get into, you know, cloud model, then identify which data center, which cloud that you would love to go, what type of monitoring that you will have to build and security, which I cannot emphasize, security by design is the new trend. Every feature that you build must have in-build security in place. For example, you need to have the right role-based access control. You need to have the governance model for customer data, all of that. So planning infrastructure well ahead. Dependency, now this is a very important checklist because from my experience, this can make or break your go-to-market. Like, if it's not just your dependency, a dependency team can be dependent on another dependency. So there's a chain of dependencies and if you are betting your entire time based on those dependencies, then you need to make sure that you have a line of sight of your dependency. You have to, as a product owner, you own your destiny. So you have to take control of your destiny. So you need to talk to those dependencies and their dependencies, get them into a room and understand that, are they really confident to deliver their part? And if they say no, that is one soft field that you need to have as a PM. It's not just building your features. It's about influencing your audience, influencing your teams on what product you're building, what value prop it is, and why it is urgent to go to market by this deadline. So you have to paint the picture and sell your vision to all the audiences so that they buy off on your plan and they can commit to a timeline. Once they commit to a timeline, then you can do a plan. You can add those timelines into your plan so that you can come up with the realistic schedule. So dependencies, don't underestimate. And if you are not confident, the dependencies have a plan B in place. So if that team is not ready, come work around. Have that in your back pocket. You don't have to share with them, but always have that in your back pocket. Lastly, bring your stakeholders along, your leadership along. You need to manage sideways. So all of that is a part of the parcel of a PM's life. Track risk. Now that you've got the pulse from dependency teams, and you also have the MDPs, you know exactly how the progression of your product is going to be, then you start putting together a project plan. It may not be like set in stone, can have like busy rooms, but start somewhere. Start putting a plan and put all your Lego blocks together. And identify your internal stakeholders. Like you have to give deadlines to your team. Otherwise, you know, things can go forever. So you need to make sure there's a time risk schedule and you partner with them very closely and engage into testing as soon as possible. Being a PM, ask to do your testing of your product. You need to really understand the bugs, the customer experience, what will work, what will not work. You can start a dog food experience, the stakeholder, right? You test your own product, you understand, you get the bugs, report the bugs as soon as possible. Once your dog food and your dog food experience is good, then you open up to your stakeholders or to your cab audience, right? And start showing your demo, get their feedback, do some regular check-ins, even with the cab, your customers are busy, they have their own deadline. Set expectations with them to, you know, to do testing and commit, get some commitment from them, follow with them on a regular basis. You know, COVID, I used to travel to customer sites, we used to have workshops and get feedback. Now, with COVID, you know, see if you can set up online time with the customers, don't exceed more than an hour or two, otherwise you won't get their attention. But do some regular check-ins and get their feedback. Maintain risk register, like the risk register can comprise of your dependency, clipping or your bugs, immense bugs. You never thought that this product was built in a certain way, but customers' expectations are different. Start recording all of that. And every risk that you have, identify a mitigation. Now, say for example, you start getting feedback where the customers are saying, oh, I thought I would get that, but I know I only got this. So, understand between what is it, is it really required to build, or is that a wish list? And that's a slippery slope. You don't want to take up scope more than what you had envisioned, because sometimes your gut and your data analysis, the first analysis and the feedback that you would have got is that probably would be a good setup, and you don't want to get all of these different noises. And that we can delay the plan. So, make sure you identify all of those, record all of those feedbacks, but question or retest with other customers and validate that you are getting similar feedback. Put the million risk register, prioritize them, stack them, triage them, and see if there is a workaround, consult with your dev team and just take orders to see if there is a workaround available. Build a diversity. Now that you have identified an MVP, you have identified dependencies, you have put a schedule, build a diversity. Diverse in terms of each team member has a superpower. Identify the superpower. I am good at product design. I am good at system design. My peer is very good in testing and validating bugs. The other peer is very good in writing blogs. So, identify a diverse team member and delegate work so that each one finds that authority and ownership and they feel very accomplished because now they are getting each of them has a place to work on. Release schedules. Now that you have identified your team, you have your MVP, you know your dependencies, start a new feedback, put together release their schedule. So, put a release schedule that you can achieve. Build it realistic. Don't get into this pressure, external pressure or internal leadership pressures because you are in a position, you are the captain of the ship. You know exactly what roadblocks are ahead and you know exactly the dependency is going to slip because you are doing the regular check-ins. So, build a realistic schedule and put some buffers in it. It's okay to under promise and then over deliver but it's put some internal buffers so that you don't make a norm. Flipping deadlines should not be a norm and that means who as a product manager along with features and design and customer feedback and analysis, you have to do check-ins with your devs. You have to go hand in hand with them and work with them in the spring plan, in the privatization, start activating all your listening channels so that you continuously get feedback from different sources. You have a risk register that is un-risk meant to get up to date and you also start creating your bit of key results, your OKRs and metrics and KPIs so that on day zero of your product launch, you already have the telemetric flowing in. You know how the product is getting towards the direction that you intended to do and so forth. Continuous feedback, like I mentioned, you're going to start with dog food and then slowly with your team, you're starting up something for your private community, right? You want to invite your customers and start getting their feedback according to the feedback and service. You can send service right after the testing and or you can do open-ended interview questions or in your feature set, you can have a line this like that to get all of the feedback as soon as possible and start charging them on a weekly or as regular as you can. So now that you've got your feedbacks coming in, you have been getting your regular check-ins at the place, you know how your dev team is doing against the sprint plan. You basically now have a long list of changes, right? And as I mentioned, once we are into the project, these are the different things that can easily deviate you from the plan. You have to be like to make sure you're recording all the features, all the feedback, all the risks together and then you have one list. And with one list, you basically start something with your change management work. Now, who is your change management? Anybody who is going to be part of your your launch that is your best manager, it can be your you know, your support team, your operations team, supply chain team, from your compliance team, right? Or a legal team, marketing, sales, everybody put them in one room and go through all of those risks and the features and the type of bugs you are receiving and validate and say, hey, I believe all of these are p0, p1, p2. Now for us to get into the next iteration, I would recommend that we address all the p0s and p1s and p2, p3 would be part of a backlog. So that way, get there by in so that everybody unanimously agree on what we are trying to address. And once they all agree, and then you basically get into your release plan to make sure that all of these changes are carefully controlled, distilled, and diagnosed, and then be added into your project plan. Operational model. Now, you have started with your MVP, you have opened up to a private peer selected customers, and now it's successful, like region A, you release to a certain region, you've got great feedback, now it's time to expand. Now this, you cannot scale with this type of core team and your stakeholder, right? Now you have to start delegating it. From each of your core team or the supporting team that you identified part of your stakeholders early on. Now you have to now talk to them and say, hey, I'm going to delegate support responsibility to you to start hiring and forming a team of support, of a support model, or you will start talking to your supply chain team and say, hey, I'm going to expand across the globe. So start ordering your infrastructure, your hardware, or your software licenses, and whatnot, start delegating to them. So put roles and responsibilities, and also understand what they feel is full of cooperation. The support will say, okay, I'm ready to support 24 by 7, I will support in US and India, so understand all of the work with them, so that you be the epicenter of the captain of the ship. You are building that operational model. Even July is the launch. Now that you have framed how the operation is going to look like, your identified team members, your building team for you and with your supporting team, you understand all the regulatory compliance, you know exactly how your dependency teams are doing. Now then, you are now comfortable in declaring a date and make it public, right? So this is a file style where you have got enough to look it back. It's definitely what works, customer like it, disliking it, and all that. You know, the engineering is already with infrastructure monitoring, reliability monitoring, support model is when placed, then you start evangelizing launch by partnering with your product marketing. So there are different ways in which you can evangelize, and you have to push your media, blogs, you can either your leadership can start writing an announcement, and these are the ways in which you can engage. And you can start inviting customers or beyond your campaign, you can start inviting expected customers and put your product brochure in place where you talk about your vision, product, value drop, and all of that. So as much as possible, build that campaign and do a product reach out so that the more usage you get, the better it is for you to launch the product. And once you have evangelized, then you start tracking the usage. Remember, I told you the earliest slide, and as part of your release plan, make sure that you already have stories that talk about how to track usage, how to monitor your availability and reliability, your support tools, are they ready? So all of that must be part of your early release plan that here at this point, it should be like the pipeline is built and the data starts coming in and you're starting the usage. They're doing, at what point are they converting, like you have to have that criminalized cycle in mind. Customers who are logging in and they use the product, they register it, or they use but they cancel. They use for a certain amount of point on the time that they cancel after 90 years. So you need to understand the customer's Germany, and those telemetry must be lighted up well in advance. So you really need to get into the details around why the customer can cancel but even it doesn't do that. Why did the customer use the product but they deleted after 90 days? Which segment of the customers are you continuing to use the product? Did they really grow after that? Have they continued to use the same product or the same feature set from day zero? So all of that categorize it so you understand your customers better. And another important listening system that I really love is your support debt. The tickets are a very important source of listening where you know exactly where the customer picked a roadblock and why they had to create a ticket and how should you improve all those product experience. Once you've built your support model and your operation model and you have this listening system spreading or building your backlog, you as a PM you need to be at least six months to one year ahead of your customers. Because that's how you're going to you know keep your customers you know the anticipation is like you keep the customer's anticipation. You keep your dev team involved because we need to be excited. Everybody needs to be excited and customers want to know what next question is coming. Your dev team needs to know when do I have to build? What do I have to build? What cool features do I have to build? Your dependency team needs to know your finance team needs to know like what's my next revenue target. Your sales team needs to know which customer segment and what type of business that I can bring. So there are a lot of people surrounding you who are looking forward for the launch to go big. So being in this portal position, you have to have all of this listening systems, antennas activated. You have to engage with your customers on a regular basis. You have to build your backlog, validate your backlog constantly. Keep researching on your support tickets. Can't emphasize this enough. Understand life-side incidents. Why did why did even customer report a problem? Why didn't our infrastructure or monitoring didn't catch those issues in advance? And how can I improve that? All of that should convert into a feature set and start putting in your backlog. So that will form your next version. With that, I would conclude my session. I hope you all enjoyed. And I'm happy to meet you all in the evening sometime soon. Thank you.