 Hello everyone. Welcome to this week's Product School webinar. Thanks for joining us today. Just in case you didn't know, Product School teaches product management, product leadership, coding, data analytics, UX design, and digital marketing courses online and at 16 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, live streams, and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Today we have an awesome guest presenting. I'd like to introduce you to Gaurav Kumar. Gaurav has a keen interest in solving complex problems in healthcare with data and design. His experience spans multiple domains, including patient engagement, pharmacy benefits and prescription delivery, data acquisition, analytics, and FHIR applications. Beyond thinking about products, Gaurav stays curious about cosmology, neuroscience, music, and art. Feel free to leave any questions for Gaurav in the comments and we'll be sure to address them at the end. And without further ado, let's welcome Gaurav. Thanks for joining us today. Hi, everyone. My name is Gaurav. Quick mic check here, Dan. You're able to hear me and see me okay? I can hear and see you. Perfect. All right. Let me share my screen and let's get started. All right. So just a quick intro beyond what Dan just mentioned that Instacart currently delivers groceries. I'm leading a team wherever you're essentially trying to figure out how to launch new products on top of grocery delivery. And what I'm talking about today about how to convey product principles, I think fits very well into the sort of organization that Instacart is. There's many moving parts. There's, you know, teams, sub teams that keep getting added, new ones keep getting created, there's new roles. There's always a lot going on in an organization. And as a product manager, over the years, you know, skill that you kind of hone with different types of organizations and people that you work with. And one of the things that came up to me was, hey, what is that one thing I've learned over all these years that simplifies not just the role of a product manager, but also ensures that you have kind of like a 360 degree coverage when you can weigh or talk about your product within your organization. And that's going to be the focus here today on product principles. So just a quick overview here. I'm going to start with, so there's product requirements and this product principles and, you know, what I'm going to convey in today's talk here is the distinction between the two. So I'm actually going to start with, okay, you know, there's product requirements and you, you know, there's some challenges inherent to actually sharing product requirements within your organization and ensuring that all teams are aligned on it. Definitely something that I have faced problems with in the past, which is why I kind of moved over time through the guidance of others, obviously, of product, of leaving behind product requirements and rather talking about product principles. So we'll cover that a little bit and kind of breaking down how you get to a point of leaving behind product requirements and using product principles instead. Just a caveat here. I'm not saying you should not write product requirement documents as a product manager. Absolutely 100%. That's kind of what you use as your working everyday document with your engineering team, with your legal team or your finance team or whoever it is that needs to dive deep. Product principles is more for in an organization where I need to very quickly and succinctly convey why we are doing a certain project and how it's going to have impact. That's what product principles are about. So we'll talk about how you start with the problem that your product or your teacher is actually going to be solving. I'll talk a little bit about doing research of like, how do you get, you know, of all those tons and tons of data that you dig up, the reading, you know, it could be feedback and conversations that you have, how do you distill all of that into kind of like a very simple succinct line. I'll also talk about knowing your audience. So the good thing about product principles is since it's a shorter, more condensed version of an entire massive product requirements documentation, you can quickly tweak it. So the kind of, you know, language that you would use when you're doing an executive summary for your leadership team versus, you know, you're sitting in the support organization with all the support agents and you're trying to convey the same message to them, you can tweak it very easily so that each audience actually gets that impact and understands the same thing. And then we'll talk about, you know, actually presenting them and we'll finally end up with a quick Q&A. So getting right into it. So the challenge that I've had in the past is, you know, I'll be working on a project. I have a product requirements doc which spans pages and diagrams and pseudocode and what have you. And someone or the other comes up and says, hey, I heard you're doing this project, you're launching this feature. I want to understand what it is you're doing. And normally I would just send them a link to this massive quip or this Google doc. And literally a hundred times out of a hundred, I hear back within an hour saying, yeah, I have no idea what you're talking about. Can you break it down and simplify for me? So that's kind of what I'm conveying here is, first of all, it can get very prescriptive. So a product requirement document gets so much into detail. It almost starts feeling like you're telling the teams that you're working with collaboratively what to do rather than conveying what problem you want them to solve. So that's the first problem with trying to convey your product or your idea within your organization by sharing product requirements. This is a big one. What works well because one person doesn't, you know, the other person just does not get it. So again, I'm going to touch upon, you know, knowing your audience and kind of like how you can tweak that and how products, you know, from a vision perspective, how the product principles actually help. Feature overload. Product requirement documents, and this is a good thing, a well-written PRD, will have all the features, will have exactly how they work, what are the edge cases, how do you deal with the edge cases, what are error states. But again, that's too much for someone who wants to get a quick idea of why they need to support you as a product manager, as a product owner. It's a lot. The other thing is there's two types of things that happen depending on the projects or products you're working on. As Dan mentioned, my background has been extensively in healthcare. So there's a lot of legal and compliance that comes in the way. In other industries as well, in fact, right now at Instacart with grocery delivery, there's a lot of legal and compliance. And sometimes, you know, the product tends to get designed with that perspective of, hey, we need to check these legal and compliance boxes off, rather than saying, hey, this is what a great user experience looks like. And a product requirement document kind of gets broken up into one of those two buckets. And it's very difficult to then, couldn't weigh that to a third person who's trying to help you on the project, because they'll be like, wait, this doesn't make sense from a user perspective. The documentation focus, I think I touched upon this, but again, it's too long. If you share this document, a product requirement document with someone else who's either joining the project, it's a new team that's actually being onboarded, they need to understand what you're doing, it's too long, and it probably will confuse them. And also, it's one dimensional. Again, a good thing in a product requirement document is it goes very narrow and very deep into all the aspects of the product that you're trying to build. However, what it does not do is actually can weigh, okay, why is this a business objective? How is it going to impact the business by building out this product or feature and war some of the trade off? So it doesn't give anyone who looks at a product requirement document a 360 degree view. And then finally, the last one is a product requirement document. It's long, there's a lot. We tend to move really fast, especially in the startup world here in Silicon Valley. So it's difficult to actually maintain it, keep it relevant. And when you then share this, let's say two months after you wrote it, there's probably things on there which are not true anymore. And again, that can lead to some confusion and downstream effects. So that's the context of why when you want to communicate within an organization as a product manager, using the product requirement document is great if you have to give detail, but if you want to give a quick overview, it's probably not the best idea. So let's talk about how you formulate product principles. And I will say this, product principles is probably the way I do it. And everyone does it their own way. There's no right way to write a product requirements document or a wrong way every PM. And if there's some advice to aspiring product managers, there's templates and stuff you'll find online, just go with what, you know, feels right to you. So it's a very, I almost call it a very personal thing, the way you write a product requirements document. So product principles in my mind, in my document, sit right at the top of any product requirement document. So it's the first thing you read. It's the first thing that anyone reads, and it can weigh that idea very simply. So again, advice to anyone listening in who's, you know, aspiring to be a product manager, question everything. When you're dealing with a problem, whether it's the customer problem of a partner or a retailer or someone else that to be to be sort of conversation, start questioning everything. My second bullet point actually relates to that. Have the curiosity of a five-year-old. You know what five-year-olds do? They'll ask you, why X happens? And after your answer, they'll be like, okay, why? And then why again? And then why again? So keep asking why and how until you really reach the end. And that's when you really understand, okay, this is the true problem that is actually leading to it. Sometimes, you know, customers or someone will tell you, hey, I need a button that when I click does X. That's a feature. That's not a problem. So you need to try to get to understand what is the problem that requires this person that makes this person think that clicking a button needs to do X. And when you start questioning everything, you have that curiosity, you will actually get to the bottom of it. This kind of like, you know, segues into what I just talked about a little bit as well, filter out feature requests. Feature requests are not problems. They're essentially a mind map of your audience who's actually telling you, this is what I think needs to happen. What's more important as a product manager is to understand, okay, but what is the pain point? What's really causing this problem? This one is actually very useful as well in formulating that the product principle is be very concise, but complete in defining your problem. So if you have five bullet points that can map out the problems, make sure that they're very short. They're not very long. They get the essence and the core of the problem, but those five bullet points, you know, completely, they define the problem, all right? And you don't otherwise need a six bullet point. So just be very mindful of always being able to portray the problem as completely as possible. And then again, I'm getting ahead of my bullet here, but always bring it down to three to five short problem statements. And that should always kind of be your guiding line. When you're trying to build a product, you're trying to solve a problem, those problem statements should really be what you look back to. Because way down the line, you'll be working with design and engineering and you're defining things and suddenly something just changes. And you can always have these three to five problem statements when you go back and you're like, is it still, is what we're talking about today still relevant to these three or five things? And if it's not, then as a PM, you'll be like, I actually guys, you know, listen, it's not solving the problem. So let's try to, and you can bring the team back towards that. Do your research. So when you're formulating your product principles, there's a lot of research that gets involved, right? So there's product strategy that you need to look at. How does this feature or this project or set of features, what have you, how does it die in with your organization's priorities, right? As a product manager, you're always going to be accountable as well as responsible for the products you own. So you want to make sure that everything you're recommending, every problem you're trying to solve at some point in some level ties with that organization's priorities. It won't happen 100% of the time. There are sometimes projects where the PM, it's not a priority for the organization, but it's a must do. So that's kind of one thing that you want to see, want to make sure. The second thing is, what are the guardrails to stay within? So when you're defining your product principles, it's always useful. And this is where numbers come in. This is where you want to say, Hey, the principally, this product needs to change a metric by X percent, right? Those are your guardrails. And you want to ensure that, okay, if we do not see this by this date, or we do not see a certain metric change by this date, what do we do? What's the exit criteria? So be very specific enough to a point almost brutal with your own self in terms of saying, if this product does not show any sort of traction to a certain point, what are those guardrails? And how do I convey this to other people? That's why this is here in terms of formulating your product principles. And then finally, what are your tradeoffs? So obviously, every product part I have worked in, there's no concept of infinite resources that doesn't exist anywhere. What are the tradeoffs? By doing this, you're obviously not doing something else. And it kind of goes back to the first bullet point here is, you prioritize this product, you prioritize this project. What are the other things that are not happening? And why is it okay for those things to wait for one month, three months, or six months, rather than doing it now? So it should be very clear when you're doing your research that you understand that and it should distill all the way into your product principles. Voice of the customer. Great product experiences, customer experiences always think of solving the problem for the end user. So customer can be in the B2B world, it could be the CFO or the finance team off of, let's say, a fintech product you're working on, or it could be an end consumer in a B2C world. So there's many extensions of the term customer. So understand what their problems are and then partner closely with them through the design process. In the typical world of you go away for one month with your team of engineers and your designers, you come up with a design and then you go back to your customer, that can lead to a lot of churn. So partner closely with them, get that data, and going back to defining the problem, it helps you really identify what that problem is and if you're solving it. Remember those three to five problem statements I talked about? Make sure you have a one-to-one relationship between your problems and solutions, because that's ultimately how you're going to show value to your customer that your product has met or has solved their problems. So make sure you're aligned between problems and solutions and features. And this is a very important lesson that I learned over the years. When I first started out as a product manager, obviously you want to impress, you want to be good, you want to do well within your organization and when you're working with your customers and your partners, you want to say yes to everything. Build a dynamic where you can actually say no. There's only so much you can do. There's only so much budget that your team has and sometimes some things that customers come up with are not necessarily a priority because there's two parties in this. It's not always one-sided, I'll do anything for the customer. It's also what can we do given the time we have and just referencing back again, being very clinical in defining those problem statements is super helpful because then you can go back to the customer and say, hey, you've asked for this, but it's not in this three to five things which are your problems. So sorry, no, we cannot build it. Maybe let's take it for this project, for this effort. This is kind of like the box that we're solving for. And then cross-functional input. This is voice of the customer internally. So as a product manager, I view customers as in two groups. So you have the customers outside the organization and then you have customers inside your organization as well. So get their input, talk to every team. Like this literally walk around. It could be in the lunchroom. There's someone you don't really know and what their job is. Be like, hey, I'm the PM for so-and-so and we should talk. Like maybe this will affect you, maybe it won't. And if it does, you're actually getting all that input that's leading into your research. Rally people to contribute. So even if there was way more than 24 hours in a day, as a product manager, you can't get to everything. And sometimes you want to look to the other experts cross-functionally to give you the input. So make sure you're not the only one doing all the research. You're not the only one pulling things together. Rally people to be like, hey, this is why we are doing this. Can you give me this input? And then, of course, the last part of it, make sure everyone is informed. So once you've done the research and that's the product principles part, when you inform everyone, you go back to them by saying, here are the product principles. Let's talk a little bit about knowing your audience. Design looks at things differently as does edge versus ops or legal or support or leadership. So when you're formulating these principles, always know your audience. Who are you presenting this to? Designers require something very different from what your legal team would require or what the support team requires. So just make sure that you're conscious of kind of looking at who you're sending this to or who you're presenting it to and then kind of framing the aspect of it. And as I mentioned right at the start, with a product requirements documentation, it's very hard to do that. The product principles, since they are concise and simple, you can very quickly tweak things and throw in things which are relevant to each group that you're talking to. Also, the other thing is we are all human. Everyone understands things very differently. Some people are very visual. For them, five bullet points or even three makes no sense. Maybe a simple diagram does. Some people like stories, formulate a short little paragraph of the story of, you know, here's Jeff. Jeff has problem X and my product helps solve it by doing Y. That kind of thing. Engineers, they really sometimes like pseudocode. So, you know, I have sometimes written a very short, you know, two line statement by saying, if this, then do this, else do something else. And that's how they understand things. And some people are just purely conversational. You can't just hand out documents and expect that to get it 100%. They're more interpersonal and you need to have a conversation. So, the lesson really here is as a product manager to be really successful in communicating your product internally within your organization as well as trying to get people to get excited about your product. It's very important to understand everyone's unique style and then tailor your conversations based on that style. Simplify your message, you know. This is a very, again, a very lesson I learned. Test it. When you've written your product principles and your short brief statements, you know, ask a partner of, you know, outside of work or a friend at work if they get it. I've sometimes, you know, going back to the break or lunchroom analogy I give you, I've just generally asked people who have never met. I'm like, hey, I'm Gora. And, you know, can you get what I'm trying to say here? And they don't get it. That means you're not going to be successful in conveying what your product is actually doing. Your detailed specs can come later. Try to get the product principles right first, because this is going to be your driving light which can actually help you build your product specs. Finally, rehearse. Before any conversation I have with either of these groups, I always go back, you know, it could be five minutes. It could be 10 minutes. And I look through it and I go through the conversation in my head. I'm actually like, okay, this group needs to understand the impact of this product. And I need to, like, make sure that, you know, everyone's time is precious in the startup world, especially things move really fast. You cannot have a 30-minute meeting anymore. You know, sometimes you have to do 15 minutes or maybe even 10. So how can you be super effective in a very short timeframe? And that's why, you know, know every number, every problem and every metric so that you can be very concise, very clear, and very effective in a short period of time. Finally, let's come to, you know, what it is about product principles that helps you do this. You know, so you've gone from pages and pages of requirements that require parsing through, which different people understand differently. And you've gone to a few lines, so it's very portable. These are the overarching guidelines for your product, right? Now, as I said, it sits at the top of my product requirements doc. It's literally the first thing is product principles. I have these five or six statements, how they relate to the problems and what the metric is we're trying to move. Below that comes all the other stuff. So that's really where it sits. You're quantifying your key objectives and results. You know, this is one thing I think I had to learn over a period of time where, you know, actually giving people a sense of hey, if we don't reach this number or this metric, we're probably not going to do this project anymore. And, you know, we'll have to move something else. So being very conscious of communicating that as a product manager, the what and the why is what we own, right? We communicate what is the problem and why it's important to solve. So that needs to come out loud and clear. Be transparent about strategy, timing, and budget. Again, the most difficult thing about being a product manager is you need to have about 20 different people in an organization to work on what you ask them to. None of them report to you. So how do you make sure you get a sense of, yeah, I believe in this product. I believe in why we are doing this. And here's why I want to help this guy out. Another big thing here, stay away from the house, right? So leave room for interpretation. You are not here to solve the problem. Your experts are your designers and your engineers. Let them focus on how to solve the problem. So leave room for interpretation. Build a sense of trust with them and a sense of creativity. Give people the ability to be like, hey, I want to go back to my desk of what Gaurav just told me. I'm going to sit and think about it. And I want to come back and present what I thought about. Rather than just telling them, hey, I've already thought about all of this. We just need you to execute. That doesn't work really well. So that I think is a key. A thing about product principles is keep, stay away from the house. Just be like, this is what we're trying to do and what we're trying to solve. And always refer back. Continue a feedback loop. When you refer back to your product principles, you can always go back and say, hey, we're not meeting this. And we're far away from this particular objective in our product principles. And regardless of how your product spec or your product requirements document changes downstream, your principles rarely change because your principles are built purely from those customer problems you're trying to solve. So that's why, just to conclude here, a product principle is very powerful in that it's simple, it's portable, it can be taken across an organization very quickly modified, but it still maintains the core essence of the product that you're trying to build. And that leads to you being successful and ensuring everyone, whether it's someone who's taking a support call or it is a CIO or the CFO that you're working with, they all understand why this product is being built and what problem it's solving. And that definitely leads to having better conversations about a product. With that, I guess we can open it up to any questions. Awesome. Thank you so much for that presentation, Greg. I'm looking at the comments here. I don't see any questions just yet, but we'll give our audience a chance to type them out and send them if they would like. So one question we do like to ask all of our speakers though is if you had one piece of advice or wisdom for an aspiring product manager, what would that be? Yeah, for sure. Definitely going back to one of the things that was on my slide, it's curiosity. Always question everything, always be curious. One thing I do is when I look at a new app or a website or it could even just be a certain kind of truck which I've never seen, I'm always curious. I'm like, how does it work? So what are the moving parts? How do they all interact with each other? And I just go and just google and google and try to figure it out. So curiosity about anything, not just the problems you're solving, curiosity in general definitely helps a lot because it actually helps your mind structure a problem. And then when you, whether it's in a job interview for a product role or you're in an active product role, that framework of actually looking at something that you don't quite understand and then being able to ask all the right questions to bring it to a point where you do understand it is super helpful. Well, that's some awesome advice. Thank you for that. Yeah, so I think that's it. That runs it up. I don't see any comments here in the Facebook. So thank you. Thank you so much for joining us today and sharing your insights. It's really awesome having you on the channel. Likewise, thank you very much Product School for having me. Cool. So before we go, I just wanted to give our audience more information on our upcoming courses and events so they have the resources to become a product manager. Product Schools, Product Management, Product Leadership, Coding, Data Analytics, UX Design, and Digital Marketing courses are taught by industry experts working at companies like Google and Facebook. In addition to that, we offer weekly online and onsite events at our 16 campuses across the US, UK, and Canada. So if you're located near a campus, make sure you stop by one of our weekly events every Wednesday and Thursday. You can also find us on social media at Product School and be sure to keep up with the latest product management content at the product blog at productschool.com. Thank you all for joining. Enjoy the rest of your day and I hope to see you next week. Thank you. Go have a good one. Thank you, everyone. Bye.