Design, Decide, Deliver: Masterclass in Product Management

1. Why is this a masterclass and why spend time on it?: Hello, friend. I'm asilKaFenJip, and I'm here to tell you something most product courses never will. This course isn't about giving you just product management knowledge. It's about helping you get hired, helping you change your life, helping you switch into product management, regardless if you're starting from IT, UX, project management or something totally different. I'm here to get you promoted. I'm here to get you noticed and get you in the driver's seat you deserve. What you hear here is about helping you make a remarkable living and lift yourself into a career most people only dream about. If you're asking yourself, why should you be listening to me? It's because I've done it myself, not once but several times. I've transitioned across industries. I've lifted myself from standard roles into global product leadership positions. I've worked at VMware, HP, and now I'm a staff product manager at Rafana Labs, one of the fastest growing, most admired companies in the global observability space. I've gone to where many peers back at home in even worldwide dream of standing. Now I'm here to tell you how you can do it, too. And here is the truth. I didn't get here by luck. I didn't get here by standing still. I got here by using the exact tools, mindset, and strategies I'll be sharing with you throughout this course. This isn't just a learning journey. It's a transformation. And here is what it feels like. You see the path ahead, you hear direct, tested advice shaped by real experience. You smell the excitement of new challenges. You feel the stretch as you push into unfamiliar territory. You taste the satisfaction of progress. So let me ask you. Are you ready to stop waiting? Are you ready to start building the career you want? Are you ready to make your work matter to yourself, to your family, and the teams you lead? Let's get you hired. Let's get you building. I'll see you inside. 2. The T.A.R Product Management Framework: Just before we start, I'd like to introduce you to the Ta methodology, which is the foundation that supports every part of this course. Think of tar like the sticky black substance that it is named after often hidden, but essential holding everything together behind the scenes. In a sense, tar is just like strong product management. Think of it as your personal compass, your guiding scent when you feel lost. Your flavor packed recipe for navigating product management. Here is what ta stands for. T is for Tory. This is what you need to know. These are the books. Articles and insights from top minds in the field that I have curated to give you a clear picture of how product management works. It's about seeing the landscape, understanding frameworks at play, and sharpening your vision as a product thinker. Not fluff. Not just few good ideas. You see the concepts. Hear the wisdom in the voices of practitioners and feel those aha sparks. Light up your understanding. This gets us to the second letter A, A is for actions. It will direct you to what you should do right now. This is where you move. Taking deliberate hands on steps after each module to put theory into action. You feel your confidence strengthen as you build muscle memory through practice, not just by knowing, but by doing because knowledge alone, while illuminating won't move the needle. You might see the road ahead, but you won't feel ready to walk it without movement. It's the difference between reading a recipe and actually cooking. Smelling the spices, feeling the sizzle in the pan, and tasting that first bite. Now, once we have the actions, we need R, which stands for results because only what's measured can be managed. Every results section will show you what good looks like. These are the outcomes you hear echo as validation, whether in peer feedback in the metrics you track or in the wins you can touch and measure. Results let you taste success. Check if you're on course or know when it is time to adjust. They're not just numbers, but the shift in your mindset, the sensation of real momentum, and the sound of goals coming to life. Measuring results helps you see clear progress. Here the alignment, building in your team, and feel the sensation of knowing your work makes a difference. So let's dive into the tar. Smell the freshness of a new start, feel the excitement in your fingertips, taste the thrill of the challenge ahead, and hear the voice inside you saying, I'm ready. Let's go build something real. See you in the next lecture. 3. Product vs Project Management: Now, when we have the Ta methodology at hand, let me take you into this story about the everlasting question about the difference and similarities of product and project management. Picture this. You're building a bridge. A project manager makes sure that the bridge gets built. This is their primary focus. Handle the timeline. You can almost see the rift schedules pinned up, the need gang charts unfolding like blueprints, the blinking lights on progress dashboards. You can hear the ticking clock, the steady drumbeat of deadlines, the click of milestone check marks. You can almost feel the solid weight on the concrete as it is poured, the sharp snap of tension when timelines are tight and satisfying grip of tools well used. But a product manager, they're both the architect and the governor. They step back and picture the whole ecosystem. Who's crossing this? Imagine the bustling traffic, the faces in the crowd. Is this even the right location? Sense the ground under your feet, the flow of the river, the wind in the air. Will this bridge still serve needs as they change? Hear the future murmur of shifting demand, taste the excitement or frustration of the future users. They make sure the bridge adapts, scales, and feels right, not just today but tomorrow and beyond. As Marty Kagan puts it in inspired, great product managers don't just deliver features. They deliver outcomes. Now, let me tell you what this looked like in practice. When I was in Viemere, I worked on a project to build an endpoint management system, a tool to remotely manage over 20,000 employee computers across the world. The work had a clear shape, budget, scopes, deadlines. We could see the progress makers, hear the buzz of project updates, feel the pressure as we hit every single milestone. At the end, we built it, we delivered it, and then people wanted just more. They wanted different problems solved. They wanted flexibility, richer experience, integrations, better scalability. Oh, my God. You could sense the hunger for more. You could almost taste the exception in the air like sharp tang of anticipation. So we stepped in. We listened to the service desk teams and the IT admins. The employees on the ground, we asked, What is frustrating you? What does this system feel clunky? Where does it flow smoothly? Where does it stick? What would make this not just functional, but delightful? And this is how we called our team, delightful experience team. Once we sensed, we were onto something, a good hunch, a product market fit. We switched our mindset. We became an empowered product team. That meant we weren't just completing tasks. We were owning outcomes. We worked cross functionally, blending the voices of product managers, designers, engineers. We had autonomy to explore, experiment, touch real problems, and shape real solutions. We stayed deeply connected to our users listening to their stories. Seeing the challenges, feeling their pain points, hearing the excitement when things worked well, and being receptive to feedback when they went south. The reason I'm telling you this story is because I want you to understand that true product work is not about just delivering what is asked. It's about stepping into ownership, curiosity, and responsibility for creating continuous value even when the pad ahead is not clear, this is the key shift. Project management is about building the bridge. Product management, on the other hand, is about continuously building, improving, and adapting the bridge, making sure is the right one, in the right place for the right people. Here's the theory I want you to walk away with and picture it clearly in your mind. Project management focuses on delivering within constraints, time, budget, scope. Once the project is done, it's done, job well done. You can almost hear the applause, feel the relief, smell the fresh paint on the newly finished structure. Product management focuses on continuous value delivery. It's about ensuring what you build keeps adapting to real evolving needs. Not just finishing the bridge, you're watching who crosses it, listening to their feedback, feeling their shifting needs, smelling the change in the air, tasting the opportunity ahead. Now, this isn't just theory for you to listen to. It's a mirror. You need to hold up to your own work. We go to actions. The first action is to audit your work. Are you only tracking how well the bridge gets built or are you questioning why you're building it in the first place and who for? Are you focused only on deadlines? Or on how the bridge feels for those crossing it. Second, super important is to talk to real users. Who's crossing the bridge? See their faces, hear their stories. What are they stuck? Where does the bridge feel shaky or flow smoothly? What would they miss if the bridge disappear tomorrow? Can you taste the sense of loss or smell the relief when problems are solved? Which one? Then we go to use your own product. Think of it, walk across the bridge yourself. Where does it creek underfoot? Where it is solid? Does it carry the right traffic? Does it feel balanced? Would you recommend the crossing to someone you care about like your mom? Can you hear yourself asking, Trust me, um, it works. Track outcomes is the next thing. And not just outputs. Who used the last feature you shipped? Picture them, hear their feedback. Ask your mom, Mom, how was it? What changed for them? Did you make a real difference? With all of these questions asked and answered, let's go to the mindset check. Here's your honest gut check. Do you see the problem your product is solving and for whom is the first thing? Would you use this product if you weren't paid to? Can you name the last three real users impacted by what you shipped? The one was your mom. Who are the other two? Was the last time you heard from an actual user, not just a stakeholder, not someone from your team, but other people. If any of these answers are hard, that's really good. That's not failure. That's feedback. That's where your best product instincts are willing and waiting to grow. So with this, let's go to results. When you start working like a product thinker, not just a task finisher, everything shifts. You stop measuring success by how much you deliver and start measuring it by how much you improve people's lives. You build stronger alignment with engineering because now you're solving problems together and not just handing over tasks to them. You begin leading with confidence because you're grounded in what actually matters. Can feel the difference. Hear the clarity in your own voice, see the impact that you're making. And yes, sometimes clarity things. As Fire Williams says, truth will set you free. But first, it will piss you off. So here is my ask. Take the next 10 minutes to write down your answers to the mindset check. Highlight where you are unsure because that's where your best instincts, your next big breakthroughs are waiting for you. Remember, you're not just here to build the bridge. You're here to be the architect and the governor, ensuring that the bridge is the right one, in the right place, constantly evolving to serve the people who rely on you. Let's keep building together. See you in the next lecture. 4. What is a Product Manager: Now, when you know the difference between product and project management, let's go to the heart of the role. What exactly is a product manager, and what do you really need to do? You often hear people say, PM sit at the intersection of user needs, business goals, and engineering capabilities. That sounds neat and tidy, but what does it really mean in practice? It means you own the product success. You're the one ensuring what you're building is valuable, usable, feasible, and delivering outcomes. You can see the puzzle pieces in front of you, customers take business or waiting to be connected. You can hear the cross functional conversations, the trade offs, the tough calls. Everything is on your plate. You can feel the pressure, the excitement, the tension as you push towards alignment. And sometimes when things are off, you can even sense it like a bad taste that something is missing or out of tune. With that, let's go to the theory. Some people call the PM the CEO of the product, but honestly, that can be a little misleading. You don't have the formal power. You don't hire, you don't fire. And you don't control budgets, but you have accountability. You're the one who connects the dots, mixed of decisions, drives clarity in the middle of chaos. A lot of new PMs ask, do I need to know how to code to be a product manager? And my short answer to that is no. However, it's important to note that no matter what product you're working on, especially in software, need to understand at least three things deeply enough. One is the technology that stands behind the product. What technology are you solving for? Second is the user problems. These hair on fire jobs to be done. And third is how your product solves the problems through the technology, and for the technology it is dedicated to. You don't have to be a wizard, but if terms fly over your head, and if you freeze in technical discussions, that's a flag. It doesn't mean that you're in the wrong row. Rather, it means you need to dig in. You need to educate yourself, start feeling the rhythm of how the system works. You need to hear the terms and make sense of them. See how APIs connect, understand latency, follow how the data flows. So think of it as your guiding book because engineers don't expect you to build with them. They expect you to understand what they're building and why it matters to the users and to your company. To the VMS story. Let me tell you how this played out for me. After our earlier shift to empowered product work, remember, when we delivered the first project and people got excited, I set my sights on the core business. I wanted to go on the big stage. Wanted to move to enterprise product management and work for the V realized orchestrated product. I told you I was ready. I have shipped things before. Evased the interviews. Then I was actually given a chance to start. So I jumped in head first, and I was wrong. Despite my experience, I lacked the technical depth and worse, I didn't know the users well enough. The feedback that I inherited was mostly noise noise from the loudest voices out there. It lacked quality, and it was huge in quantity. I was standing in a noisy room trying to hear the true signal, but all I got was static. So I went back to basics, and this did me well. I did more customer calls. This is the qualitative data that will save you more usage data, got the reports, understood where people are clicking and what they're doing for quantitative data, and more time with sales support and UX, because without these without their understanding, your product will be shelfware. Finally, more focus on understanding the real users, what they need, where they felt pain, what outcomes they cared about. The reason why I'm telling you this story is because I want you to know being a PM isn't about looking like you have it all figured out. It's about stepping up, asking the right questions, relentlessly pursuing clarity, even when it is humbling. Even when it's things, you need to leave your ego aside, like Jeffrey Moore says in crossing the chasm, a fantastic book. Without a clear understanding of your target users and their compelling reasons to buy, product development is just guesswork. So with that, let's jump into actions. That's why it's not enough to simply know what the product manager is. You have to live it through your actions, through the choices you make every single day, through how you show up in your role. So let's talk about what you can do right now to show up well. First, is identify your key collaborators. Make a list of the people that you mostly care about and put there why you care about it, and why do they care about? Who are your engineers? Who are your sales partners, support contacts, designers, legal contacts, all of them picture their faces, hear their voices, understand why they care about your product, and how they shape it. Because if you don't have internal buy in, chances are you won't have external one. Second, is focus on the real user. And this is paramount. Pick up persona. See them in your mind, if you reenact what they're doing. You need to actually be the users see through their eyes. What's their role? What's the problems? They keep them up at night? What does success feel like for them? What are the hair on fire problems that are trying to solve? Three, collaborate and don't assume shadow someone from sales, shadow someone from support or design. Ask them, what's something you wish the product did better? Listen. Product management is at least 20% listening. What are customers telling you that product isn't acting on? Again, sit down, listen, and absorb. Notice what surprises. Notice what resonates with you, what leaves a sour note, what sparks excitement? All of these are the keys to changing your mindset, changing your product, and getting buy in. Now when we said mindset, let's go to the mindset check, and let's get honest. Before we jump to results, I want you to please, again, sit down, write down the answers to the following questions. Do I know who my product is really for beyond the generic label of users or everyone? Can I explain the product's value in one sentence? From the customer's point of view? What was the last time I got feedback from outside my team? Have I heard an engineer say, That's a good problem to solve? Would I bet my own money that this thing we're building solves something important? What's the thing, how it solves it, why it is important? Those are hard to answer, you're not behind. You're just finally starting. Let's go to results. Here is what happens when you show up with the level of awareness and action. You stop being the middle person and become a connector, the one who links right people, right insights at the right timing. You earn trust from both engineers and executives because your thinking is grounded both in the why and in the how. You start shipping things that actually move the needle, not just dig boxes, do sprints and t shirt sizing. You can feel the alignment, hear the clarity in conversations, see the progress, even taste the satisfaction of product that truly delivers. You're not just moving things in the Cavan. And as Daniel Karman says, intuitive expertise is learned from prolonged experience with good feedback. Product management is a feedback game. The faster you step into the loop, the faster you grow. So start now one stakeholder map, one use a deep dive, one real conversation with someone closer to the customer than you. That's product management in action, not guessing, not posturing, learning, connecting, and building over and over again. Let's keep building together. See you in the next lecture. 5. Enterprise vs Startup Product Management: In our last lecture, you learned what a product managers. And in the next couple, you see how the role changes in different contexts. Let's talk about a decision that can shape your entire product management path and experience, whether you're choosing between a startup and an enterprise or just trying to get clear on where you're headed after your next PM interview. This decision matters because while the fundamentals of product management stay the same, talking to users, shipping value, collaborating across teams, environment you're in completely changes what and how you do. I've worked in both at VMware at a global enterprise with thousands of employees and at Grafana, a fast growing startup in the observability space. I can tell you the difference isn't just in size or speed. It's in how you think, how you execute, and how much risk you're expected to handle. Now, with this, let's jump into the theory so we can understand more. We'll start with the enterprise PMs. In an enterprise, you often be working with mature products, larger teams and many layers of decision making. You spend time aligning with stakeholders, navigating systems, and managing cross department trade offs. As a PM, in an enterprise, you see the vast organization charts. You hear the hum of back to back meetings and feel the slow pull of established processes. Every decision carries weight. Every step has structure and sometimes red tape. If it sounds scary, don't worry. There are benefits to it. You get deeper resources that can help you shape the product like legal, analytics, partner managers, customers success teams all there for you to form a wide, cross functional product team. However, are challenges as well. You need to make progress despite the layers. Lead without formal authority and get multiple teams moving in the same direction. Now flip that the startup PMs. In a startup, you're expected to do more with less. Less process, fewer people, tighter deadlines, not a lot of certainity no certainty at all, most of the time. You wear multiple hats at so many occasions like PPM, part UX researcher, part firefighter and part engineering manager. You rarely have the data all the time. Your best work will be the cycle of ship, learn, and literate. An example, Edgar Fana, I was handed a product that was from a Hacketon. It was named Pubert Monitoring. There were no specs, no clear strategy, no more than five people building an MVP. Still, despite all of the odds, we have turned this into a multimillion dollar product. It became successful not because it was perfect, but because we stayed close to users, move fast, and kept it simple. As a startup PM, you can hear the urgency in every sprint. Feel the deadline of pushing boundaries, sense the raw energy of constant adaptation. Here's the truth. The job of a PM is the same in both worlds. Solve problems, create value, ship, learn, and repeat. But the tools, the tactics, and the pressure points are radically different. There is something most people miss. Whether you're in a startup or an enterprise, product management requires an entrepreneurial mindset. You are responsible for the outcomes, not just outputs. You need the same urgency, creativity, and resilience that founders bring even inside a 10,000 person company. Talking about a ten K person company, let's go back to the Grafana plus VMware story. Over the time, the product diversified, multiple squads on pieces, the environment was stable, supportive and supported. Things were going great, but eventually I craved change. Wanted to see the direct impact of my actions in a different setting with higher velocity to hear the customer feedback firsthand and to feel the rush of creating new value. I'd often hear, if you want to truly master product, start small, help something grow. So I made the jump. I transitioned to a startup PM role at Grafana, and I quickly realized the core responsibilities of a PM are similar, but the context and the space you operate in makes all the differences. The reason why I'm sharing this with you is because I want you to understand where you drive, what pace you can handle, what environment you need, and how you show up when the ground shifts beneath your feet. With this, let's dive into the actions. The main point of which is that understanding the difference is one thing. Exploring how it fits you is what matters. Here's what you can do to feel where you fit well. One is check your energy profile. Ask yourself, do I thrive in messy, fast moving environments or do I feel more grounded in a structure and stability? Picture yourself in both. Does chaos make you energized or drained. Does structure com you or make you feel stiff. Feel your reaction to those answers, and this will be your first clue. So we can go to the second point. And this is do an ecosystem scan. Pick one startup and one enterprise that you admire. Research how their product teams work? How are they structured? What tools and rituals do they use? What do they say on blogs and podcasts? Immerse yourself in their world, get a feel for their culture because culture is what is going to push you forward. Three is, talk to a PM in each. Interview someone at a startup and someone at an enterprise. Even if you distantly know them, just link them them a message. Ask them, what surprised you most about working in your current company? How do product decisions actually get made? And what's frustrating and what's energizing you in your current role? Listen for sparks, put yourself in their shoes and see the world from their eyes. Which stories excite you? Which ones leave a bad taste? That's your gut speaking, and you'd be better off if you listen to it. Listening to your gut is one thing, but a mindset check holds the value that will guide it. So let's get honest. If you're thinking of picking a side, reflect on the following. Do I get frustrated when things move slowly or anxious when they move too fast? Do I want to test and break things or refine and scale? Am I ready to deal with ambiguity, technical depth, and wearing multiple hats? Do I want adrenaline or structure? And finally, do I want to build something new or make something big work? There is no wrong answer, but there is a right fit for you, and if you write down, take 5 minutes to reflect, you get it right. After we got honest and have a hunch on where do we want to be? Let's see the results of it. As you are clear now on how those two worlds operate, you start unlocking real momentum. Choose roles that match your strengths and learning goals. You stop comparing paths and start owning your own. You develop habits that match the environment where that's experimentation, alignment, or both. When you stop trying to force fit into someone else's mold, you start becoming the kind of PM that's energized, confident, and effective. As Guy Kawasaki said, in the out of the start, entrepreneurship isn't for everyone. It's for those who can handle the terror of uncertainty and the joy of creation. So, which side are you on right now? And is it where you do your best work? Let's keep building. See you in the next lecture. 6. The Enterprise Product Manager: Now that we have explored startup versus enterprise, it's time to zoom in to the enterprise product manager's role because it's an animal of its own. This role, it comes with its own unique challenges. You're not just building features. You are managing strategy, scale, risk, alignment, and a whole web of dependencies. You're balancing the needs of global customers, internal politics, legacy systems, and performance expectations, all while keeping the product relevant and valuable. So with that, let's go to theory. I want to tell you again when I was at Wiemer managing VializeOchestrata. And what I learned quickly was that it wasn't about building quickly. Rather it was about building right with predictability for fortune 500 customers who couldn't afford downtime. I had to balance significant technical depth while keeping at least three major enterprise customers satisfied. I often sat in project style meetings discussing upcoming features rather than delivering them because going through the gate sometimes matters more. And let me tell you, if your goal is to make everyone happy, you'd be better off selling ice cream than managing enterprise products. Is always someone that it is unhappy, but you need to balance that out. As an enterprise product manager, it's about navigating complexity. Managing mature products or portfolios, balancing innovations, stability, scalability, and team alignment all together at the same time. I often found success by pitching features intended for one customer to others, testing the scent of market resonance, avoiding hypertailored builds because this can harm your backlog, just building something for this one customer. Technical challenges felt overwhelming. I leaned heavily on engineers, and I wasn't afraid to admit when I didn't know. That built a learning culture both in me and the peers that I worked with. And when my engineers felt overwhelmed, I stepped in to negotiate trade offs, shield them from external pressure so they could focus on what matters most. When I like to tell them, I cannot code, but you do. So let's do things that we are all good at. I'm telling you this story is because I want you to understand what it takes to thrive as an enterprise PM, where you must manage scale, complexity, cross team alignment, and still stay steady when the ground shifts beneath your feet. Here is what you're really doing. You're designing a system where multiple teams can move forward without stepping on each other's toes, and these teams usually work in silos. You are not the loudest voice, rather you are the clearest one. As Mick Kirsten says in project to product, the biggest bottlenecks to innovation isn't ideas. It's the flow of value across organizations. Your job is to unblock that flow. So with it, let's go to the actions, the dos. These aren't just theoretical challenges, but they demand practical moves, moves that let you cut through noise, manage risk, help teams progress despite complexity. Let's break down what you can do right now. And the first thing is map stakeholder power early. Remember, you did the stakeholder map. Now you're mapping power to it. This means who holds influence, who shapes decisions, who needs to be involved upfront. Picture your organization's network, the formal roles, and the hidden influences. Can you hear where decisions get stuck? Can you feel the undercurrents shaping your roadmap? Because sometimes loud voice and influences can be hidden. Two, audit your technical depth. Where are legacy tools or code slowing you down? Walk through the system. Where does it creak under pressure? Where does it run smooth? Don't be misguided. Engineers will put a lot of emphasis on technical depth, which means that you should pay a lot of attention to it, but don't get dragged into just doing technical depth work. Can you sense the drag on the team's performance, the invisible cost lurking below the surface from not taking these decisions? You need to answer those. Three, align cross functional teams bring engineering, UX, support, success all into the same room. Clarify the goals, surface the conflicts, and put them to rest. Let the room hear the tensions, feel the push and pull so you can create shared alignment. Hs are the dos now the don'ts. Don't wait until things break to address technical depth, please. The cracks you can see today will widen until they stop delivery code. Don't assume everyone's on the same page. There never are, even if they look like that. Silence often hides misalignment, force the conversation. Don't leave key stakeholders out of early decisions. All stakeholders need to be in early so you can go with it. Looping them in late cause time, thrust, and momentum. And with that, let's get honest, our mindset check. Enterprise PM work looks fantastic on paper. But are you ready for what it really demands? Please ask yourself and write it down. Do I know how to influence decisions without formal power? Have I ever had to say no to a big customer and still keep the relationship strong? Can I explain the business impact of a technical trade off to a non technical stakeholder? Do I know the roadmap and how to defend it without hiding behind Jira tickets, flashy names or titles? Then when priorities shift, can I adapt without derailing my teams? Because in enterprise, the biggest wins often happen behind the scenes through calm, clear, strategic moves. Let's see what results will these action when you get this right, here is what starts changing. Teams stay focused because they understand why the roadmap is shaped the way it is shaped. Engineering trusts you because you protect their time and push for quality over urgency. Leadership sees you not as a backlog manager, which is great, but as someone who risks major initiatives and drives scalable outcomes because it's not what you do, it's what you do that matters. As Jeffrey Moore reminds us, without scalability, innovation is just art. In your job to turn innovation into something that works, not just once, but across teams, markets, customers, and quarters. So are you optimizing for delivery or driving long term enterprise value? Let's keep building C&D next lecture. 7. The Start up Product Manager: All right. Let's dive into the other side of the spectrum startup product manager. Startups don't have a safety it. The product either works or it dies. That kind of pressure creates an environment where PMs need to move fast, experiment constantly, take ownership from day one, fail, and learn quickly. You're not waiting for research. You are the researcher or best case scenario. You're working shoulder to shoulder with one. You're not just reviewing specs or product design documents, you're writing them, testing with users, sometimes even jumping into slack to answer support tickets the same day and help a customer get them blocked. You can almost hear the ping of user questions. Feel the urgency of fast releases, sense the raw energy of an idea coming to life in real time. With that, let's go to Terry and my Grafana story. So when I joined Grafana, I was handed a loosely formed prototype from a hackaton named Cabernis Monitoring. It was not too validated. There was no clear roadmap ahead, no strategy that will push it forward like a bullet train. However, what we had was a hunch, a hunch that developers needed something to monitor Gubernis with, a faster, simpler and easy to start with solution that could aid their foundational needs. So we launched fast. We stripped things down. We focused on quick wins, simple improvements that made the developers feel Hey, this is actually solving something for me that early momentum, I gave us so much breathing room to go deeper. Yes, it was crappy. It was imperfect, but it worked. And that was what mattered most. We stayed close to users, and we kept moving. We asked them questions. We perfected the product as we go. That's what startup PMing looks like. You solve real pains fast. You learn, you adjust and you repeat. Are not the process. You are the engine of the bullet train. It's not always comfortable. It really is, but it's widely rewarding. If you can drive in ambiguity, or as Reid Hoffman says, if you're not embarrassed by the first version of your product, you've lunch too late, and hey, if you spot a glitch, a rough edge, something a little scrappy in our conversation in this course. So me poking the microphone. That's not a mistake. That's me practicing what I preach. Lunch early, learn fast, improve, and repeat. I'm not just talking about this. I'm doing it right alongside you. The reason I'm telling you this story is because I want you to understand. Thriving as a startup means stepping boldly into uncertainty. Trusting your instincts, learning to create momentum, even when the path feels half built and shaky, even when things get strange and you don't know where to go. And here is what you can start doing right now to make it happen. First, build a bias for action. Take one idea, find the fastest way to test it without waiting for permission, but rather waiting to ask for forgiveness. Picture yourself pushing the first domino, hearing the subtle tap as it sets things into motion. What's one thing you can validate today? Even roughly. Ask yourself. Tell me too, set up fast feedback loops. As we said, product management is a feedback game. Talk to three users this week. Ask. What's slowing it down? What have you actually used? What do you actually hate? Here their pain points. Sense what excites them. What leaves them a bitter taste in the mouth is something that you can change to a fantastic relationship. Feedback isn't an event. It's a conversation you keep alive and how you build your most trusty allies in the faces of your customers. So three is stepping into the unknown. Volunteer for something messy. Volunteer for something that it is far more technical than you can do. Growth starts when your comfort zone ends, and I'm not trying to be your motivational coach. But again, feel the stretch, feel the uncertainty. Feel the thrill of figuring it out on the fly on your own by yourself because this is what will prepare you to become or to be a better startup PM. Now the don'ts. Don't wait for the perfect plan. Oh, my God. Please don't more ship fast and learn as you go. Don't treat feedback as one off event. This is everything that you need to own and you need to drive forward feedback. It's a continuous pause, so keep listening. Don't cling to what's safe and don't think that your current project will thrive. It may not you may scrap it tomorrow. If it doesn't scare you a little, it won't grow you that much as you want. This is the final thing before our mindset check. So let's get hot. Startup PMing looks cool from the outside. Yeah. You're this half entrepreneur, half owner. But here is what you need to check in with yourself before diving into it. Do you feel energized or overwhelmed when there is no clear path forward? Can you ship something imperfect and improve it in public, or do you need things to feel polished before you launch? Do you need process to feel productive, or you can create a structure as you go? Are you okay being run three times before you get it right and people knowing about it? Can you make big calls without the data but with strong user signals? If your stomach drops a little, that's your growth edge. You don't need all the answers, but you need to move. And with that, let's see the results. Here's what happens when you lean into this kind of product leadership. You build faster because you don't wait for perfection. You validate fast, you build stronger because your teams trust you to take ownership and not just assign tasks. You build smarter because you're learning with every experiment, every user conversation, every wrong turn. As Eric Ries puts it in the lean startup, only way to win is to learn faster than anyone else. That's what startup PM is, and this is what we startup PMs do best. So are you waiting for clarity, or are you building your way toward it? Let's keep building. See you in the next lecture. 8. Build your PM Practice: So far we've covered what PMs do, how the role shifts across environments, and what kind of mindset you need. Now, let's talk about the daily mechanics of being a great product manager. Here is the reality. Even the best vision, strategy, and roadmap mean nothing if your team is out of sync and drowning in ambiguity. Your job as a PM is to create clarity through rhythm, through how you plan, reflect, communicate, and show up. Here is the theory behind building your product management practice. At Rafana, one of the transformative realizations we had was that success didn't come just from bold product ideas. It came from establishing a strong cadence with the team and creating direct connections between engineering and customers. We set up rituals like sales and customer calls where engineers could hear feedback firsthand. Regular cross functional check ins with UX, docs and support were a great team, public roadmaps that aligned internal external expectations were a head. All of these backed up by lightweight process for planning, retrospectives and decision making, designed to keep everyone aligned without overwhelming anyone. These rituals let our team hear the user's voice, feel the urgency of real needs and see how their work translated into meaningful outcomes. One of the boldest and most effective moves we made was offering free playground environments where customers could explore features at no cost. Not only did this give users hands on access, but it let us track features they interacted it with most, providing invaluable behavioral data. They shaped our roadmap. This wasn't just about guesses or loud customer voices. It was about measuring what matters. As Peter Droker said, what gets measured gets managed, even when it is people, trust, or direction. Rituals, experiments, and transparent metrics are how you build momentum and trust week after week, sprint after sprint. The reason why I'm telling you this story is because I want you to understand that product work isn't about rigid process. It's about designing the conditions for your team to align, move forward together with purpose and clarity. Covered the theory, let's move to the actions, the dos, and the dons. This isn't theoretical. These are the practical moves that help teams break through ambiguity and build shared momentum. Here's what you can start focusing on today. One is set a weekly rhythm. Create a consistent cadence for check ins, metric reviews, planning, and retrospectives. Picture the steady pulse of a team that's moving in sync. Let your rituals become the drumbeat that everyone can hear and feel. This way, they'll know where they're headed together. Share your roadmap publicly, make your roadmap visible to engineering, sales, support, and even customers. Of course, if your company permits it, be bold but thoughtful and only share when you're confident in your direction. Transparency will build trust, but it must be managed carefully. See stronger buyan here better feedback and sense deeper alignment, people can connect the dots between their work and the product direction. Three, create clear sources of truth. Whether it's a dashboard, a simple doc or a KPI board, everyone should know what's being built, why and how success is measured. Grafana, when we started sharing ARR and feature level KPIs with the engineering team, it transformed the way they talked about their work. They were no longer just coding. They were driving the company's success. That clarity is something that the whole team can touch, on, and act on. Now, when we covered the dos, let's go to the Don'ts. Don't over process. Your rituals should enable flow, not bog it down. Don't hide the plan. If people can't see the roadmap, they can't align with it. Don't scatter, key info across a dozen tools. One clear place beats ten fractured updates every single time. You now know what to do to build your product practice. Let's do our mindset check so we can put the topic to bed. Let's get honest. Here is the part where I challenge you directly. Ask yourself, can every member of our team explain why the top three items are on the roadmap right now? You creating clarity or adding to the noise? Do your engineers trust the decisions behind your prioritization? When was the last time someone outside your team understood your plan without the need of a 30 minute explain a call? Are your rituals building momentum or just filling up calendars? If those questions make you uncomfortable, that's your growth signal. With our mindset check done, here are the results you get out of it. When you put cadence, transparency, and strong metric backbone together, your team trusts the direction. They can see it, hear it, and reflect on it regularly. You move faster because decisions don't need to be re explained. You adapt faster because your rituals surface risks early and reduce surprises. You build a culture where data and feedback aren't just reports they're a living tool that empowers everyone. As Marty Kagan says, the best teams don't need more process. They need more trust, more context and better decision making rituals. This is how you stop spinning your wheels and start shipping with clarity, intention, and confidence. So, how are you showing up for your team today? Are you creating the clarity, momentum, and trust they need to thrive? Let's keep building, see you in the next lecture. 9. You PM Toolbox: At this point, you know the mindset. You've seen what great product managers do. Now it's time to give you the tools. You can actually run product like a Pro. The bespNs don't rely on luck. They have a toolbox and they use it to bring structure, clarity, and speed into the chaos. These aren't fluffy templates or pretty slides. These are working tools. You return again and again to tools to prioritize what matters. Tools to learn from your team, tools to plan effectively, and tools that build momentum without micromanagement. This lecture will be a bit different. I'll start with this quick walk through, and at the end, we'll do an exercise. The goal is for you to put your knowledge into practice and feel what PMing is hands on. So without further ado, let's jump into the tar. The first thing that we'll look at is the four quadrants of the tools that will help you. The two by two decision metrics for prioritization will help you prioritize what matters. Plan realistically with a quarterly session held on a planning board, build momentum is the third one, and essentially this is putting your backlog, your issues, your things that you're working on into a broadly shared backlog. With a dashboard behind it so people know what's in progress, what is done, what is on hold, et cetera. Finally, learn from your team. A simple retrospective like the mad, sad glad will help you immensely into learning what's happening with the main focus to get actions and get better. We start with the two by two prioritization matrix. Have three things to do here. One is to define the priority axises, which here are effort and impact. Then map and discuss ideas visually by moving stickies into the four quadrants, and finally prioritize strategically. What does that mean? So if you see on the top right, this is low effort, high impact. These are your quick wins. This is where you should go first. Then you have below it, high impact, high effort. These are your strategic projects you need to plan and execute. On the left, you have low impact and high effort. This is the money bit. Don't do that. And finally, on top left, you have low effort, low impact, these are productivity killers. So stuff that will lie to you that they are valuable and you put 100 small efforts in them, and at the end, you'll die from 100 paper cuts because they won't mean anything. A more visual way. This is how it looks. Low effort, high impact, the annoying org screaming, yes. These are your annoying quid quins. They're annoying for your competition because you're going to drive them mad with it. Below it sounds like a plan. High effort, high impact, big projects planned well, deliver big value. On the left, the money pit. Low impact, high effort. No. Oh, my God, please, no. And top left is low impact, low effort. He, no one has time for that, for sure. Going further down the lane. This is planned realistically. And to plan realistically, you need just three things. Put all things on a table. Trust your squad and ask them how much time will this cost you? Don't shirt sizing and story points together or some kind of exorcism. Use one thing to size, one thing that you all understand. Make it simple. Finally, put buffers in, have owners and stack rank your things that you're going to be working on this quarter, this week, this print. This is how it looks. Easy, ugly, but it works. We have several columns from left to right. We have an issue description with a link to your backlog board, an issue owner. This is extremely important. If there isn't an owner, no one owns it. If there are five owners, it's not going to be really well executed. I can guarantee. So one owner, one issue description. Then we go to stack ranking from one to whatever you want, but make sure that you have only 11. You have only one major top priority that if everything fails, you need to deliver. So just 11. If you know dependencies eon, map them to the issues. If you want to drop it, just drop it. Footnotes and indicate if box work or user experience work and some designs are needed beforehand. Then we go to the retrospectives dos and don'ts. So do show up prepared and make it safe. Don't wing it, and don't overthink and get into solutioning during the retrospective. The idea of the retrospective is to align actions and have allss to these actions, but not solve during this 1 hour. Otherwise, as you might have been through, a retrospective can go up to two or maybe 4 hours. There we have it. A simple, mad, sad, glad retrospective. And this is something real. This is from one of my retrospectives. Essentially, we outline our feelings with gifts, which is extremely important. If you know how your squad feels, it's going to be far easier for you to outline actions and notice patterns if something is going south. Sometimes people just know how they feel, but don't know why. And when you go deeper, they'll essentially tell you why they think they are feeling that way. So outlining feeling patterns, SAPM will guarantee good delivery of your backlog. Person's name, person's gift, then we ask, why do you feel that way. Afterwards, we give ourselves some time one by one to fill in what we are mad, what we were mad during this quarter, what we were sad, and what we were glad. At the end, we have an emotional statement if we want to, and the most important thing that I'll show you later is outlined actions and oness. With this, we go to our mindset check as every time, answer truthfully, put it on paper and reflect for 5 minutes after. Do I prioritize with intention or I wing it each sprint? Are we learning from what we build or just shipping more stuff? And finally, do our rituals and tools drive clarity or just check boxes? If you have the mindset in place, if you have the tools in place, you'll go to the results. So you shift from reactive to intentional. Your team will take ownership because they help shape the work and not just receive it. Finally, your roadmap will drive momentum and not just aspirations. You know which way to go, not like those two kids. Before we go into the exercise, one of the best quotes related to tooling in process is instructions from Marty Kagan. The best teams aren't defined by their structure. They're defined by how they make decisions and what they choose to work on. That's it. And with it, let's jump into our 10. Prioritization Exercise: All right. Let's dive into a long and uncut exercise. We start with a mirror screen. This is mirror if you've seen it. Fantastic. You've not just go into mirror.com. It is a free tool. Of course, it has its paid version, but as you see here above, I'm going to use the free version, as I don't want you to buy, like, anything or advocate for any software. This is just easy to use. So let's start with create a blank board. Okay. Great team board. It's going to pop me up with this thing. These are all types of templates that we might want to use. I can try to see if there is a two by two, let's see, two by two. Yep, there is something. We can use that, something that it is less colorful. Yes, here it is. So we'll use that. See straight out of the box, it gives you water two by two. So we said here, we're going to have low effort. On the bottom, we have high effort. This will be high impact, and this will be low impact. Just grab these, get them out, and here is the easiest way to do. Now, let's get dt and divide this like feature feature one feature two. Feature three. And let's delete these. Just for the sake of easiness because otherwise the exercise will become cows. Imagine that the colors are people. So person one will be yellow. Person two will be dark blue. And person three will be light blue. What I'm doing is just copying. Control C, Control V, easiest one, two, three. Okay, we zoom out. We can delete this. Hi. Hi. And what does the two by two stand for? Imagine that these people need to decide on three features. And usually the two by two is good for exactly that. Big features, big themes that you don't have full clarity or full agreement on. Person one says for feature one, I will go here. Sorry, this is all feature one. Here we go feature one, different people features. Person two says for feature one, I think it's high impact and a little bit high because feature one, according to the yellow person one is low effort. I think it's not low effort. I'll put it here. I'm the dark blue person two. Light blue person three feature one says, I don't know, put it here. In this situation, I would advise you to either take dark blue person one high effort and don't go into yellow person one low effort because usually that indicates unknowns. And if you have unknowns better plan with a little bit of buffer, then be sorry afterwards. More thing. If Light Blue feature one person, sorry, I Light Blue person three, feature one is the lead developer, and he doesn't know either what impact it has or what effort it has, plan with higher buffer for effort and do a spike. So you can uncover the unknown unknowns. Let's do this again. So this will be feature two, feature two. Feature two. Feature two. Let's delete let's leave feature one. Feature two. Person Yellow person one says, I think feature two is low effort, low impact somewhere here. Dark blue person two says, I think it's higher effort, but I don't know. I don't know exactly what the impact is. I'll put it here. Finally, light blue person three says feature two goes low effort and maybe here. Now, here we are having a discussion around impact, and everything goes here into the low impact more or less. I would usually advise if you have other more pressing priorities in your backlog to scrap the feature. Maybe do a spike to uncover if it is such low impact, but scrap the feature. Everything that is low impact, even if it is low effort, will kill your productivity. So this was the two by two. 11. Backlog Grooming Exercise : Okay, so out of the two features in our prioritization exercise, we chose feature one. Let's get feature one. Expand it. Say, give a good description of the feature. Maybe a short definition of success of how success looks like. When we have those two, we know that we want to prioritize these feature, and this is the same for every single feature you can have ten, 12, 20, et cetera. We need a place to put all of the features that we have prioritized then so people know where to go, where to look, and what does that mean? A good tool to do this is Trello. Trill essentially gives you some board tools that are either Camban or hieros style or whatever. So we'll go with the super basic thing. I have an account with Trello. Again, it's free. I'll go with a basic board. In the basic board, you should be able, and I hope this works. Actually, let's create one. Create a board, basic board. Port, create, here it is. It's super basic board. This is how it starts. First, you go with the links. We start with backlog. We go into Committed in progress, testing. Done. We don't need that. With this, we go back to the mirror board and give the description, give a good description, we'll just call it feature one. So we go with feature one. Let's open feature one description. A good description. Let's say that we're building what we're building. We're building a dashboard. Build a dashboard that as a dashboard user, when I try and observe something I can see actionable insights. How does success look like a dashboard that solves problem A, problem B, problem C, for a user that is a good characteristic characteristic. There we go. Characteristically defined persona. What do they feel? What do they see, et cetera? You should know this. Okay, let's save it and now move it to this basic board to backlog. Move. Here it is. This is your feature one. You can imagine you have a feature to feature three. And all of these, I don't know if this is possible. Yes, feature three, feature two, et cetera. And this is for one squad. If you have two squads, you might have multiple boards that are connected. Don't have disconnected backlogs and boards. So what does it happen? When you run the priortization, and you commit to it, you move it to commit it, and then you say, Okay, we have committed. Let's move it into in progress. So we have some in progress, some in testing, some done. The nice thing after testing when everything is done is when it goes to done. It goes to done, and when we have completed our sprint or our quarter, and when we have all of the testing done, when customers are happy, when we have validated everything and the quarter is done, it's time for retrospective. And this will be our next topic, retrospective. I hope that this was extremely easy for you. The different stages of a feature are almost always the same backlog committed in progress testing and done. Good definition of the feature is paramount. Good definition of them is paramount. Everyone seeing the swim lanes and your backlog within your organization is key. And for you as a PM, knowing when a feature is about to get released is also extremely important because you need to evangelize. All of this is covered, and you have this as knowledge. This is just tooling. And this is why I told you, I really doesn't matter what tool you're going to be using. It matters what mindset you're going to put behind it and that you're always trying to be clear, crisp. Don't put noise, build what matters, build minimum viable products, and just ship it when it's ready. Ship it. I when you ship, you don't feel a little discomfort and a little embarrassed, as we saw, you've shipped too late. So that's it. Blog committed in progress testing done a simple bold, simple backlog for all of your teams to use. The one thing that matters, all of the issues, all of the work should be in one board for this respective team and you need to broadcast it. Easiest one, two, three. Let's go to the retrospective. 12. Running a Retrospective Exercise : Finally, the retro. I'll be using another ball from my retro that we had. So on the left hand side, there are these gifts that provide the emotional statement. We have the names here. Dev Senior, DX person, everyone. So we get a little gift from here, put it next to our names. And we can check out what's happening. Then we ask every single one of us, who feels in what way and why? And here is what I was talking to you about in the Tory pot. You can see that people are happy with what we were achieving, see? However, you can start noticing this, this, this, again, this, this. This indicates that they're starting to get overwhelmed. And it's only on feeling basis. So when you see it, you start to ask questions. Is there too much on your plate? Are we having too much work in progress, things like that? And you notice this only because humans easily define how they feel, and then they dig deeper. It's hard to do the other way around. So once we're done with it, we go, This is a stop, start, continue doing. It's like the MDS at guide, but stop start, continue. And you can even see that exactly this happens. So stop, keep an eye on the channel for questions, but here is groom the board every two weeks, have epics for each big feature, Epics with more details. Start fewer projects, more teamwork. Now, these are the little EOGs. You should already be aware before the people put the stickies in that something is a mess. So here it is, fewer projects. In cross cluster, T cross team, et cetera, et cetera. Continue using dog food, talking to customers, good communication and decision making across the team. You'll see all of these pop up on your board. Finally, the one thing that matters most discussion and action items. Here is one a seal to create an epic template for us to use that will be good with bubble. Every time you should have an action and the nom. This is done in so little time, like 1 hour, but it gives all the insights that you need. And it's easy to create. All of this is just come here, take a shape, put it, and this is one of your swim lanes. Give it some color. That's it. It's easy, and it works. However, the mindset behind it, that you need to understand your team, that you need to have owners behind the actions is rather key. You need to learn how they feel, what they're shipping, what they like, why what they don't like, what they're sad, mad, glad about. Actions and make it better. It's not the tools. It's the actual product mindset that you already have. So with this, our exercise is over. And just to recap, we learned how to prioritize with the two by two metrics. We learned how to backlog, groom, and backlog, store and track our deliverables with the board intrel and finally, we did a retrospective where we asked ourselves, how do we feel? We have outlined the patterns. We know now what to stop, start and continue doing, and how to outline actions and put Illness next to them. This was a great exercise. Hope you got the best out of it. See you in the next lecture. 13. How to do Product Discovery: In our previous lectures, we've covered how to shape your product mindset, how to apply powerful tools, and how to guide your team's work with clarity. Now, we come to the heart of great product leadership, the essence of which lies in knowing your customers and knowing your business. Here's the hard truth. The one you should already feel in your bones. It's not enough to build fast. You have to build the right thing for the right person at the right time. So let's jump into the theory about product discovery, the one that drives product leadership and separates feature factories from product teams that lead the market. This is not a one time research print. Also not a box you check with a survey or a kick off interview. Discovery is a habit, a rhythm, a pause you can hear every single day. It's your constant curiosity about how your work can impact the world, about how people get stuck and what they hope for but cannot reach yet. Product discovery is uncovering what your prospects and customers expect, what they hope will feel right when they use your product and it solves their problems. Your job here is not to get a feature request like a shopping list. It's to dig for real painful problems because solving those delivers a kind of emotional relief, and when users can sense it, they will crave more. It should come to you now that if you rush into solutions too early, you risk sounding, condescending or locking yourself into a half baked pack. On the other hand, if you don't know what competitors are doing, you're not discovering. You're guessing. Remember, if your discovery game is one of chance, you eventually lose. So let me give you a story that you can picture clearly and learn from my experience. We built communities monitoring at Grafana, discovery there wasn't limited to interviews only. We dug into developer ransom Rdi it. We could hear their frustration in absolutely every post. We map competitors friction. We watched where their users churned. We noticed their setup and scaling flows and even where their existing solutions fall short. The key for us was that we didn't aim to be the best at everything. We zeroed in on the critical pains others were neglecting. We solved it better than anyone. Thus, we built differentiation of features first. These features enabled us to secure our first customer. Once we had real users to talk to, we started building the other foundational features. Our main advantage was that we were building collaborative relationships instead of just pushing features out. Such connections formed our product to stand out as it helped real users with their hair on fire problems. We solved only what mattered in an opinionated way, a way that competitors could not do fast enough to be relevant. All of this without losing time in guesswork. Exactly what Jeffrey Moore describes in crossing the chasm. Big prospects share the same pain points. However, they're more cautious. They wait, they watch. They want to be certain that you are covering their use cases. They listen to what their peers are saying, and just after all of the above, they may start becoming your customers. When you solve a real problem beautifully, people talk about it. That's how you win. Gei Cavazaki nails it and drive your competition crazy. Don't ask your customers to create the future. They're too busy dealing with the present. Your job is to understand their problems better than they do. Now, as usual, let's dive into the actions for building real discovery loops. Let's get practical. If you want to build products that resonate, peer right in users hands, sound right when your team describes them, here is what you need to do. And also don't forget the traps you need to avoid. We will compare one do versus one don't at a time, and additionally, I will give you an example at every single step. Do number one. Be crystal clear on the problem that you're solving. Don't settle for surface level answers. Go deeper. Keep asking why until it stings until you feel the discomfort of the real pain behind the request. Example. If someone says the reports are too slow, don't stop there. Ask, why does speed matter? Maybe they need insights before a board meeting. Maybe they are getting blamed for poor decisions because they didn't have data fast enough, or maybe they're embarrassed presenting outdated numbers. You should know that. The corresponding don't and it is treat discovery as a one off. Discovery isn't a kickoff event. It's a continuous loop, a background process that always runs. If you're not constantly listening, observing, and asking, you're missing the music your customers are making and your product will drift out of tune. You should now be ready for Do number two. Know exactly who you are solving for. Not just users, not a generic persona in a slide deck. People, people you can visualize, whose frustrations you can feel, whose dreams you can name. Here is the example. Are you solving for a frontline engineer debugging live production issues, a frustrated manager juggling team metrics or an overwhelmed ops lead helping with alerts at 2:00 A.M. Each one sees the world differently. Each one measures success differently. And knowing that you should be well positioned to understand what keeps them up at night, what makes them sigh with relief, what would make them tell their team, Hey, you know what? You've got to try this. Now the corresponding don't. Jump into solutions too early. Don't do that. So please hold back. Don't rush to show screens, prototypes or demos, sit in the problem space longer. Make sure it's a problem. Your users are willing to pay, advocate, and fight for. With this, the final do number three, know your market and competition. You need to be painfully aware of who else is tackling your space. What are they doing better? Where are their customers frustrated? Are they loyal? Who and why is leaving? The example, at Grafana, we didn't only list competitive features. We felt their onboarding pain. We read their customer complaints. We notice what features never got adopted, and we build an experience that solved what others missed with fewer clicks, cleaner steps, and faster time to value. That's it. Now, the last corresponding dt is rely on your gut. There are signals all around you. Please use them instead of your gut. Use online forums, support tickets, call transcripts, cancellations and feature usage data. If you're ignoring those signals, you're not discovering. You are gambling. And as I told you previously, if you are gambling, you inevitably lose. Now, when you know what you need to do and what you need to avoid, let's get to our mindset check. Let's get honest. Please ask yourself and write down the answers, then take 5 minutes to reflect on them. Do I truly know the top three problems my product solves or am I guessing? Have I heard those problems directly from users this month? Would I personally want to use this product not as a PM, but as a customer? Can I describe the emotional frustrations users feel before and the relief after using my product? Do I know how my product stacks up visually, functionally and emotionally against my top competitors? If these questions the discomfort, that's great. The signal that real discovery is waiting to begin. And when it begins, you'll definitely get some good results. Here's what changes when discovery becomes a living habit and not a task on your roadmap. First, you stop relying on hunches and start hearing patterns emerge. Your roadmap becomes clearer, guided by real user needs and not internal assumptions. You get a customer quotes that resonate with buyers, with stakeholders and most importantly, with you and your team. As Sd Godin says in the practice, serve the smallest viable audience, make it perfect for them, and they will tell the others. That's how you build a product that spreads, not by chasing everyone, but by obsessing over the right someone. So are you truly doing discovery or just guessing with confidence? Are you seeing your users world through their eyes? Are you hearing what frustrates them, feeling what excites them, tasting the opportunity to solve their biggest problems? You tell me, Let's keep building together. See you in the next lecture. 14. How to execute Product Delivery: You've learned how to sharpen your product mindset, how to drive discovery, and how to prioritize what matters. Now we turn to the craft of delivery. This is how you balance what customers want with what your business needs without losing your team's focus or your own. You can feel the tension. Because here's the truth. If you're building for everyone, you're building for no one. If your roadmap becomes just a wish list for customers as, you're not managing a product, you're managing noise. Even if it sounds hard at first, here is the theory that will help you manage through. As a product manager, you'll hear constant noise from two sides. One, existing customers demanding for more of what already exists. Two, prospects waiting for just one more feature. Before they sign. Your job here isn't to say yes to everyone. It's to say yes to the right things at the right time. Moreover, to explain why these choices matter. Here is the sensory reality you're working with. You need to see the trade offs clearly. Here, the urgency but not get swept up in it and feel the weight of promises before you make them. Sometimes even sense when a deal or request just doesn't taste right for your long term strategy. This is where you shift from being a feature taker to becoming an outcome owner. So at Grafana, we work with both massive enterprise clients and passionate developer communities. Early on, I have overcommitted. I wanted to please everyone, but I burned out the team. I've created friction with engineering and left our roadmap cluttered and confused. Had to reset. We started talking openly about trade offs. We made our roadmap transparent so teams and customers could see what was coming and why we got internal alignment before making external promises. That shift didn't just change what we delivered. It changed how our team felt about delivering. As Marty Kagan says, if you're going to be serious about product, you can just take orders. You need to understand the problem. Validate it and solve it in a scalable way. With this theory in your hands and minds, we can jump into the actions, the dos and don'ts for smart delivery. Here is how you build delivery discipline that smells like confidence, tastes like clarity and feels right to both you, your team, and your customers. Do number one. Balance stability and growth. Stability keeps the product solid for your current uses. On the other hand, growth pushes it forward. You need both, but don't get stuck just fixing bugs or adding shiny features. Keep your hands steady on both the levers. Do number two, use a Y filter for requests. Ask yourself and your team, is this solving a widespread problem? Does it unlock value we couldn't reach before? Can I scale beyond just one customer? If you can't say yes confidently, you need to pause and reflect. Do number three, make promises you're proud to own. Commit only after validating the real impact, aligning fully with engineering and being ready to stand behind your word. No sugar coating, no vague timelines, no slippery yeses. Now, when we cover what to do, it brings us even more value to do so with what you should not. Don't number one, confuse noise for priority. Just because a request is loud doesn't mean it's the right next move. Listen carefully and always validate. Don't number two, offer fuzzy yeses. Saying, maybe, or we'll try without clarity, kills trust. Say what you mean and mean what you say. Don't number three, hide behind vague roadmaps. Explain why you are choosing certain paths, why you are saying no for now to others and how it all ties back to what users truly need. I'm sure you're expecting the mindset check. So let's get honest. Ask yourself, am I saying yes to requests just to ease the tension or because they're the right pets? Do I fully understand the cost to my team when I make a promise? Can I defend my roadmap with clarity and not excuses? Am I building with engineering or just tossing tasks over the wall? Do I know when to say no and how to say it in a way that builds trust rather than resentment? If these questions make your stomach churn, that's the discomfort where real leadership grows. Are you ready for the results? This is what shifts when you lead delivery with purpose. You earn respect from engineering because you protect their time, not just escalate tickets. You build trust with sales because they know what's real, not just what's hypothetically possible. Customers stay loyal, not because you say yes to everything, but because you solve what matters and they feel that focus when they use your product. As Daniel Canman says in thinking fast and slow, nothing in life is as important as you think it is while you're thinking about it. That goes for customer requests too. Don't get trapped by urgency. Zoom out. Stay clear. You're not here to manage opinions. You're here to drive outcomes. Can you see the path clearly? Can you hear the priorities through the noise? Can you feel the weight of your promises and still stand confidently behind them? Let's keep building together, see you in the next lecture. 15. Crafting you PM CV with real life tips that work!: Before you rush to apply, I want to give you something most courses never cover. They never cover it, but it might be the most valuable 5 minutes you spend here. Here is the deal, as I promised you. It's not just about learning frameworks or tools. It's about landing a real job, one that pays your bills, feeds your family, and lets you change the world through the products you help build. And to do that, you need a CV that smells sharp, tastes clean, feels focused, and looks irresistible to hiring managers and screeners. Here is what you need to see. Hiring managers are scanning dozens, maybe hundreds of resumes. They're listening for signals, feeling for focus, and sniffing out clarity over fluff. Your job is to give them something they can bite into quickly, confidently and memorably. Rule number one, make it one page, no excuse says, Yes, one page, not 1.5, not two, please, not then. If trimming it down feels painful, that's good. That's the signal you're learning how to distill, which is exactly what makes a great PM. Hiring managers don't care about your hobbies. You love for spicy cure or your guitar skills unless they directly link to the job. They want your highest education, the skills relevant to this job that you're applying for, and the reason to believe you can deliver measurable impact, the rest, save it for the coffee chat. Room Number two, start with two, three tangible wins and put them first, right at the top, before jobs, schools just give them the headline real. Here are some examples skilled, self serve onboarding for ten K to 150 K over six months. Cut customers' chum by 50% after product led onboarding overhaul. Build MVP that lended ten better users and secured preced funding. However, if you're fresh out of school, just tell them what was the hardest thing you did. Where did you show grit, leadership, or initiative? Make them taste your ambition. One centers per win, no filler. Rule number three, focus on outcomes, not tasks, managed stakeholder communication is not a win. Delivered MVP that unlocked first Enterprise Deal, now we're talking. So for every role, start with a Vb. Be specific, show what changed because of you. Make the reader see the before and after. Here the improvement, feel the shift you created. Rule number four, use tools to help you. You don't have to do this alone. Use free tools like enhanced CV, Novo resume up, all of the different resume builders. Use AI helpers to tighten your bullets and scrape LinkedIn job posts to pull out some keywords. No need to wrestle with word from scratch just seriously. Here are the distilled dos and don'ts on how to present your skills like a pro. Now, first, we start with the does. Match your skills to the job description. If it mentions user journeys, for example, and you know them, just say it. Be confident but accurate. Most people overstate. If you're holding back, you're most probably undeserving yourself, especially with AI filters. Highlight relevant certifications or referrals. PMI ACP, safe Scrum product school, keep it clean, keep it upfront. Put those referrals front and center. Now the don'ts. Don't assume something doesn't count. If you have run a retro, handle the customer interview, or prioritize features, just own it. Don't undersell your impact out of modesty. Hiring managers one guess your greatness. You have to spell it out. Don't clutter with irrelevant extras unless your hobbies tell a compelling story that is relevant to the job, leave it out. Reason I'm telling you all of these is because I so truly believe in them. I have lost a good friend telling them that the advisor they were working with was wrong for telling them to add hobbies at the end of their CV. We no longer talk. So with this context, let's jump into the mindset check. Let's get honest. Before you hit the pi, ask yourself, does my CV show? Not just tell my wins. Am I letting the hiring manager feel my confidence or making them guess? Is every line adding clear flavor or just padding? If reading your own resume makes you feel like, Yes, this person delivers, you're on the right track. Remember, you don't need a perfect resume. You need a clear, compelling story. One page tangible wins, honest confidence. And of course, a product mindset, even in how you present yourself. If you can do that, you are already ahead of 90% of competition. You are not just applying for a job, you are building your next launch pad. Make your voice clear. Make your story sharp, make them taste, why you are the one to watch. Now, stop perfecting and start applying. Let's keep building together. 16. It's a wrap!: It's a wrap, but just before you go, I want to show you something most product managers don't see clearly. Now, if people don't know about your work, if they don't hear about it, if they can feel its impact, it's like it never happened. You can build the most elegant, delicious product. But if no one smells tunity, taste the difference, or feel the buzz, you won't get the support, adoption, or credit you deserve. Your job isn't just to ship code, it's to evangelize, is to connect people and outcomes and build what matters. Think about it like this. You are the bridge between users and engineers between roadmap and reality between what people say they want and what truly feeds the business. And it's not about shouting louder. It's about telling truthful stories, stories anchored in user pain, team effort, real outcomes, and measurable business value. Here are the final accords of MPN Journey and the story about Grafana. At Grafana, I realized that even when we ship brilliant features, if we didn't broadcast the wins with numbers, quotes, and visuals, it was like the victory had no scent, no flavor, and no weight. Internally, people missed the progress. Externally, customers didn't feel the evolution. So we changed. We shared wins in Slack. We demoed features live. We connected fresh functionality, back to user stories, so everyone from execs to engineers to customers could feel the pulse of progress. So if you're wondering how to become the product evangelist your team needs and your company deserves, here are the actions you can take right now. Do number one, be your product's loudest advocate. Celebrate wins publicly, show numbers and not just feelings. Make the impact so clear, people can taste it. As I like to say, we'll become so good, it will be impossible to ignore us. One example, instead of saying we improve the dashboard, say, we cut report generation time by 40%, and customers are telling us they feel the difference every day. Percentages need to be from actual measurement and not from your gut, of course. And if you are saying that customers are telling you something, you should have been talking to them for real, right? Do number two, tell a story worth repeating. Keep your message tight. Why this product? Why now? Who does it help and how? Make your narrative something people can hear once and repeat back easily in slack in meetings, in demos. Do number three. Make your team feel like co creators and not order takers. Ask better questions, reflect their thinking back to them and make sure they feel proud of what they're building. Now when we have the des, let's go to the Ds Dt, number one. Don't disappear after delivery. If no one knows what's shipped or why it mattered, it's like baking a perfect cake and leaving it locked in a room. Let people taste the wind. Don't number two, don't confuse opinions with insights. You're not here to guess or echo noise. You're here to connect the dots, validate, and bring clarity. Don't number three. Don't just move tickets around. This should be clear now. Managing a backlog doesn't build influence. Driving meaningful outcomes does. So with all the dos and all the don'ts, let's get to our final mindset check. Let's get honest. One last time. Write the answers of the questions down. Take 5 minutes reflect. If I left tomorrow, would the team miss my clarity or just my task juggling? Am I leading an owner or just keeping the machinery running? Does everyone feel the value of what we're building or am I hoping they'll figure it out on their own? If these last few make you anxious as a kid before Christmas, that's the growth edge you need to lean into. And with it, here is what happens when you evangelize effectively. The results are your team gets energized because they know their work matters. They feel the progress and hear the gratitude. Stakeholders trust you because you speak in outcomes, not just tasks or tickets. Your product grows because your voice carries its value beyond your immediate circle, and people want to rally behind what's working. As Steve Jobs said, the people who are crazy enough to think they can change the world, are the ones who do. That's you now. You got the mindset. You've got the tools. You've got the stories. So are you just shipping features? Or are you building something people can truly see, hear, feel, and even taste the success of? You're not just a backlog mover. You are a changemaker. Thank you for walking this journey with me. Now, stop watching courses and start building the product you want to use and the story you can't wait to tell. Thank you for choosing this course. I'm certain you'll get hired and you'll find happiness, purpose, and meaning. And now, my fellow product manager, let's keep building together.