 Good day everyone. Hope you're doing well. Thank you so much for finding time for the presentation today Today's presentation will focus on how to be a successful PM by using structured product deliverables To be more specific, we'll talk about the working backwards framework, which has been popularized by Amazon a Little bit about myself. My name is Shantanu. Nice to meet everyone virtually. I Am a director PM in Microsoft been here for the last two years try to Amazon. I was in Amazon AWS and Amazon.com Essentially building products for the operation and supply chain spaces Now, let me dive into the presentation today The agenda today is to basically understand what working backwards means then understanding a summary view of the different life cycles of product management and then double clicking on the each of the three Life cycles from a working backwards structure point of view We'll end up there the PMG sheet and then we proceed ahead Starting off with the key takeaways today. So this is where the reality check is needed Many people have heard this line that product managers are mini CEOs The reality is very different Product managers are not mini CEOs By the fact that they build products through consensus through influence. There is no formal authority people or costs for a PM What does this gap in perception and reality mean? It means three key takeaways number one a PM role is thrife over scope product lifecycle and organizational influences as Organizations change their restructures or the priorities change is PM is rarely affected by that Now to make sure that a PM become successful in this climate in this challenging product building and organization climate It's important to use structured product deliverables They help drive role clarifications cross team engagement and the business outcomes Now one way of being very effective of using product deliverables is by using a working backwards framework Now let's dive into what is a working backwards framework in the first place What does working backwards mean? Essentially working backwards is a product development approach It starts by putting the customer foods and then working backwards from it Now as you may have understood product of implementation using working backwards is Difficult it requires discipline and org maturity However, once implemented it can reap create rewards the company as the entire ecosystem is working towards one goal Which you know, it's a very feasible goal from a customer point of view Now let's understand the pros and cons of this approach The pros of working backwards obviously is you put the customer first you validate the feasibility and then you start working This allows you to actually get the entire organization of support towards the same goal However, while you're doing this you also create a document or rather the walking part Towards with the product can be built. So affected by uncontrollables of the organization The product part is still there for people to follow However with the pros comes to cons the cons is that this tends to be a limiting on the creativity side because you can start having a very very narrow focus of some features or the other features Right. The other thing is obviously it's pretty time-consuming to run through this entire exercise especially if your organization is not ready for this and Last but not the least the pms bear a huge brunt of it Especially earlier in the product development when they go about trying to engage the business teams the tech teams The leadership and the multiple other support structures around it Now with that, let's move on to what are the product life cycles, right? So Product life cycles really vary cross organizations and companies depending on how they look at it also Depending on where are you set? Are you building towards customer facing or on the critical path versus? Are you creating a product for a supporting structure? However, let's up level this so we can use a three Vertical approach across the product life cycles The first one is product strategy Product strategy deals with why should we build something? It essentially looks into our business strategy Our teams our companies SWOT analysis trends weakness opportunities and trips It factors to market needs the competitive landscape and the technological advances It considers all of these things to create a strategy with the leadership can say yes, too After that from product strategy, we do move to product plan Product planning is literally the what what should we both? It defines the features and the decisions which help turn the online strategy into reality So a good product plan would obviously build on the product strategy and then detail out the critical elements What we need to build especially on the MVP side The key outputs here would be gained a directional alignment and confirm that the resources are available for this After we figured out why to build What to build we focus on how to build and then actually build it Which is where the third pillar product development and launch comes into place Now these are the decisions and actions to turn the plan into a success This is creating the detail product plans Working with engineering tech teams having the tracker view moving with all the changes which are happening and then actually launching the product and key output is Mapping the entire change management across all the teams With launching a high quality product Now that we understand the summary of your product life cycle from a working backwards point of view So let's double click on all the three pillars one at a time Let's start off with product strategy Why to build? This is the famous PR FAQ phase popularized by Amazon and it's essentially three questions. We are trying to answer Is it worth investing? Are there any open questions we need to close out? It should be continue investing in this area To achieve this There are two kind of documents which you need one is a PR FAQ document other. It's a BRD document Let's start over the first one Now PR FAQ document is essentially a Compilation of a vision document and a customer market analysis The idea being here is that from a vision point of view What are we building and how does that help the company and the customers? From there going into a deeper customer market analysis to understand who are we building for? How will it help them? How will it help? Once we nail down the PR FAQ and we get an alignment on that next comes to BRD document It is a business requirement document Here we talk about what's a gap to meet that vision which we're talking about and what Opportunity does the business need to capture based on that? What does success look like a product strategy for a PM? It's essentially about gaining an exact buying on the PR FAQ gaining a business buying on the BRD and Generating interest across the business and techniques now the third one is a understated one People gently ignore that one but using your product deliverables To generate interest across the business and tech teams It's one of the most powerful networking aspects which you can gain as a PR Because these are the people who are actually going to be with you Cross the entire cycle to build the product. These are the people who are going to launch products Hopefully grow more across companies and as you develop a working relationship with them the network grows with them So please keep that in mind Now that we moved on from product strategy, let's go into product line product learning was about what to build and Here, this is the fun structuring the product phase here. We talk about what should we first build first and why? How should the user use the product? How does he see the product and how should we build it? So here we talk about the product right now is it a first stop and The second document is the PRD the product requirement document Now the product road map is essentially broken up into two basic sectors product phasing and the MVP for this Product phasing is about how are you phasing the product in a way that you are best utilizing your limited resources? To pick a biggest impact To the business and to the customers It's about how are you phasing it? How will your phases help the customers and how are they being built one on top of the other an? Important element here is to remember the dependencies you have across the different teams to deliver That frequently becomes a critical element in the phasing The next part is MVP bill and this starts off with just focusing on the minimum on the minimal viable product What is wise and maybe there may be What is the need to have versus a good to have delineation to make sure you're truly building what you truly need? How will the product be filled? What are the policies and the rules and the field mappings that you have to change and what are the high-level Systemic workflows what this helps is it helps the people understand What kind of product and what kind of changes to the ecosystem you're looking at? Once you close that town you move on to the PRT and the PRT is Very very critical document because this is the document which will literally translates Why and what to how to build this is where a product manager has to go into details and the technical Aspects really shine out there when you build the detail view on the MVP Features the fields the user stories the policies the configurations Creating a wire framing effort to unhelp the engineering team understand exactly what has to be built If a PM is technical enough building a Level two or a level three system diagram in this really really helps Because then the engineers start understanding which of them would use and what is the ownership structure across the software tech teams? To make that happen now. What does the success look like here? Success here means you gain the business and a tech team behind on the roadmap Right the engagement you were trying to do is really going to help us here as the teams are interested They know this product is going to shape. They pay you better focus and you give you better feedback on this Then step point number two you gain a tech buying on the PRT Which if they do not sign off then the next state of development will not start The third is planning on the racy chart for product flows and this is something again, which is very understated across teams building a racy chart is Very very critical because from now. It's the development is going to start knowing exactly Who is responsible? Accountable who has to be consulted who has to be informed over the entire development cycle is very very critical Because that's where the changes are going to happen. That's where things are going to slip that's where the direction may change and Having that particular matrix will help you to get that better Now that we have typed into the product clinic Let's move into the product development and not and here is whether rubber meets the road the actual Development has to stop right and the key questions asked in this phases. It's a product on track Did the product launch on time? It's a product successful So I've broken up this phase into three pillars Road map tracker Which answers with the product on track Testing documents which look at the quality of the product that you're building and is the product successful Which is a lot about the launching documents and how are we measuring the product launch? Now road map tracker. This is one of the very popularized and chart views which you have which talks about Breaking up the product into multiple work streams, which make more sense with organization Understanding to cross dependencies green yellow and reds reason for changes This is a road tracker which is has to be frequently sent to leadership Depending on the kind of product you building you may have to send it every week every two weeks every month So having the racy Clear racy with a road map tracker aligned fairly really helps to be and move this forward The testing documents I mentioned the system in uat testing. There are the unit testing another kind of testing also a B testing System and uat testing is something which is a general across all different kind of products that you build and It is very very important to understand the different elements. We need to be tested The data flows across API is to cross system parsing of data the dependencies and the sample data sets Now one thing which is missed out a lot when we are trying to get an ETA and a time understanding of the different components for developers is that the tech teams talk about The things which I need to build within the black boxes The integration time across these different boxes are frequently missed or understated because the teams haven't really Sat together to figure out how will the integration pieces work? I would suggest as a PM you bring that up and make sure there's a lot of focus in the right time lines and understanding being developed over there In the testing documents that gap really really shows up Launch documents the third pillar Launch documents are how about how are we supporting this product launch? It's not just about the launch email but on the launch communication But also talking about how are we supporting the launch? How are we keeping a strong eye on the critical metrics of the launch? How are we catching user feedback and how are we quickly using that user feedback into? prioritizing it to improve the problem now What does success look like here? Success here would be an updated and accurate roadmap communication Which facilitates a discussion around changes of the roadmap and how we can bring it back on track For a testing documents it talks about completed test use cases Which are actually used by the team and they actually surface real problems From a launch document point of view obviously it's a successful launch But apart from that the user feedbacks and how they have been integrated into the Development of the V1 becomes very very critical Now that we got a chance to work all these three Different phases and look at this from a working backwards point of view I just created the simple cheat sheet about Stages the developers and what success looks like in all the developers and with that I wish you the best in your VM journey and I look forward to meeting you all of you Virtually or physically in some space Thank you so much