Many meetings and interviews begin with the same line: “Before we get started, let’s begin with short introductions.” What follows is usually predictable. In a monotone voice, people list their name, role, location—and if you’re lucky—a “fun fact.” If an AI were trained on thousands of these intros, it would probably respond with something about the weather. Why? Because most introductions invite safe, polite, surface-level conversation. But here’s what many miss: your introduction is your first impression and  your tone-setter. When you introduce yourself this way—especially to a new team, hiring manager, or potential client—you come across as vanilla. The conversation stays safe, guarded, and forgettable. If that’s your goal, keep the vanilla intro. But most people don’t actually want to leave a vanilla impression—they just don’t realize how much it limits the tone of the conversation that follows. You want to lead with the impression you want to leave. Think about how a great comedian opens a show—or how a founder starts an investor pitch. They don’t just say who they are; they set the tone. They grab attention, spark curiosity, and make you want to know more—because you’ve been hooked. You can do the same. Lead with something bold, impressive, funny, or simply human. Because when you show more of what makes you  you—your story, your quirks, your energy—you give others permission to do the same. That’s how real connection starts. That’s how trust and stronger relationships are built—not through titles or job descriptions, but through authenticity. Before your next introduction, ask yourself: 👉 What tone do I want to set? When you open up in a non-vanilla way, you instantly shift the dynamic in the room. You move from polite small talk to genuine connection. And trust me—it’s a lot better than talking about the weather. Follow me for more tips to improve the way you lead

If you want people to really listen to you, you have to make what you’re saying important to them—not just to you. Think about it: how many times have you checked out while someone was talking? Was it truly boring or just not interesting to you? Subtle difference, but an important one. The speaker cared enough to share it, but they didn’t bridge the gap to make you care. That’s what separates great communicators from average ones. Great communicators hold your attention by making what they say feel relevant. Without that connection, even important points go “in one ear and out the other.” The other day, I had lunch with a family member in high school who’s taking a public speaking class. He had to do a “show and tell” about himself. His plan was to bring three things: a protein shake, MMA gloves, and guitar picks. When I asked him more about his approach, I realized the problem: the speech was all about him, with no hook for the audience. He assumed classmates would automatically be interested in what mattered to him. I could just picture the bored faces of his teenage classmates. So over lunch, we reworked his speech. The focus shifted from his stuff to the stories behind them—and how those stories could spark curiosity and connection in others. By the end, he not only had a better plan, but also felt more confident and excited to deliver it. That’s the lesson: communication isn’t measured by what you say, it’s measured by the response you get. At work and in life, the easiest way to earn attention is simple make it about them first.

I believe decision making is the single most important skill for a Product Manager to master. Now, you may be thinking—what about strategy, leadership, business acumen, communication, or technical fluency? All of these skills matter, but in my experience, they all depend on your ability to consistently make great decisions. Decision making is the bedrock that determines whether those complementary skills shine or fall flat. Here’s why: Strategy  depends on deciding what to research, how long to spend on it, and ultimately what approach to recommend. Leadership  is shaped by the choices you make every day in how you show up for yourself and the team. Communication  is built on deciding what to share, how to frame it, and even what to hold back. Every PM knows the stress of a big launch or an unhappy customer. But the truth is, you rarely get fired for one  big wrong decision. What really derails a PM is the thousands  of small decisions leading up to that moment. From copy suggestions, to backlog prioritization, to customer call prep—each one nudges your product toward success or failure. When I reflect on my own days, I’m often surprised by how many decisions I make in just a few hours. Some take seconds, others minutes, and a few stretch into days. Over time, I’ve realized I rely on my own internal framework for decision making—something we all have, whether we’re aware of it or not. If you’re not getting the outcomes you want as a PM, it’s worth examining how you make decisions. Once you understand your process, you’ll start to see where you can sharpen it—and that’s where growth begins. That’s why I believe decision making is the foundation skill above all others. Get this right, and every other skill has a chance to flourish. If this resonates, follow along—I’ll be sharing the framework I use to strengthen my decision making in an upcoming post.

Have you ever ask wondered whether standup makes any sense at all? This amusing video captures common standup scenarios that many of us can relate to. I must admit that I watched this video more than a few times than I expected because I have seen these behaviors over and over again. After many years of running standups, I discovered that the patterns that the video makes fun of are actually behaviors of underperforming teams that need to be addressed otherwise you will be left asking yourself, day after day, what is the point of these 15 minutes? Three symptoms of underperforming teams stood out to me that should put you on high alert that we will review in more detail. Scenario 1: Team members that are not prepared for standup I once heard a story from a successful construction manager that tells all their sub-contractors that the when the job starts at 9 am it means that by 9 am they are starting work on the project. Sub-contractors that arrive at 9 am to grab their coffee, use the restroom, and get their tools organized to start working at 9:30 am are warned and then let go when the behavior persists. The expectation is to be ready to start at 9 am not get ready to start at 9 am. Big difference. Think about how that can compound over time and impact the timeline of the project. What does this have to do with standup? The video opens with a team member’s alarm set to wake them up, get out of bed, and into standup 1 minute before standup. These team members act like the sub-contractors that believe 9 am is the time to get ready for work rather than be ready for work. The team is paying a tax when team members use standup to get ready rather be ready. Many of you may be thinking “what is the big deal?” The difference is marginal. I believe margins can make all the difference. Good and great are often separated by margins. Which side do you want your team to be on? In my experience, great teams are more prepared than those that are not and how they operate in standup is a reflection of their work. Scenario 2: Ambiguous updates are a sign that progress is moving slower than expected Have you heard the saying “the best lies have hints of truth?” Injecting the lie with a bit of truth makes the lie more believable. What does this have to do with standup? What if I told you that some of the best sounding updates are a little bit of effort dressed up as a lot of effort? You hear this in the video and it happens in real life too. Why does this happen? It should be no surprise that some people do not like working, but like or need the paycheck. These team members are going to attempt to optimize the minimum of work needed to be done in order to collect the paycheck. It’s a smart strategy. Who doesn’t want to get paid a lot for as little effort as possible? These type of people are going to attempt to add fluff to their updates to sound smart and important even though their output does not match their verbose update. Be watchful and don’t fall for the BS. On the other hand, the video makes fun of the team member that completed various tasks and calls them “overachiever.” In my opinion, most, if not all updates, should sound like the “overachiever” - clear and concisely detailing the work that was completed. Scenario 3: Everything is always  good typically is code for there are problems we don’t feel comfortable talking about. Imagine asking your partner “how was your day?” and day after day you get the same response “Good”. The same bland monotone “good” day after day. After a while you start getting suspicious. You start thinking that this is not normal. You even start getting worried because your experience as a human tells you that each day is different. Some days are better than others and others not so much. You ask yourself, how can every day be just “good?” You know there is more under the surface - you just need them to open up. If you become suspicious with one person, now multiply that by 5 or 10 or however big your team is. Teams that typically always respond “good” without exemplary results means that the team has yet to produce an environment that surfaces and encourages what people like to call the “difficult” or “uncomfortable” conversations. Standup can be a valuable meeting when the team is held accountable to a high standard of performance and communication otherwise it leaves you mired in a loop of ambiguity while you ask yourself “what is the point of this” after each standup and do it all over again the next day.

The two most important skills for eliciting meaningful user feedback are: Asking open-ended questions , and Listening for emotion—not just words. Avoid asking users directly if they like  the product. That question invites surface-level answers. Instead, observe how  they interact with the product, and draw conclusions from their behavior. Actions are far more revealing than opinions. To gather actionable insights, start by observing what users do—and then work to understand why . Ask questions like: “Can you show me how you typically do that?” This kind of prompt invites them to walk you through their real workflow. Watch closely. How do they navigate? Where do they hesitate? What do they skip or work around? As they walk through their steps, keep asking follow-ups—especially when something diverges from your expectations or design intent: “Can you tell me why you did it that way?” These moments are gold. They reveal gaps between your mental model and theirs, uncovering opportunities to improve usability or alignment. But the real magic comes in how you listen . Yes, pay attention to what they say—but more importantly, tune in to how  they say it. Emotions are signals. Moments of confusion, delight, frustration, or enthusiasm often reveal the most valuable insights. When you notice a spike in emotion, pause and dig in: “I noticed you paused there—what were you thinking in that moment?” In summary: If you want meaningful feedback, watch what  people do, ask why  they do it, and feel how  they experience it.That combination will consistently lead you to deeper, more actionable insights.

Victor Cheng mentioned in his newsletter that in life, most major problems start as minor issues that grow because they’re left unaddressed. Major relationship issues often escalate from small misunderstandings that fester. Major health issues usually stem from small concerns that were ignored. Major financial issues tend to grow from early misuse or unchecked habits. I believe this pattern is just as true in product management. As a PM, major problems often arise from a series of small, compounding decisions that seem harmless in the moment but snowball over time. Major execution failures usually begin with minor process inefficiencies. Major strategic missteps often start with a shallow understanding of the problem space. Major UX issues are often the result of small usability flaws stacking up. Like in life, the key to avoiding major product problems is resolving the small ones early. That’s because minor issues are typically easier and cheaper to fix. The real danger is that they seem inconsequential and are easy to ignore—until they aren’t. If you only act when the consequences are obvious, you’ll constantly find yourself reacting to fires instead of designing solutions. Over time, I’ve adopted four steps to help me catch and correct issues early: Anticipate the ripple effects. Before making a call, I ask: Does this reinforce an existing issue or open a new one? Pressure test assumptions. I check my thinking with peers, cross-functional partners, or my manager. Plan around tradeoffs. If we can’t solve something now, I log it, communicate the decision, and revisit it in the roadmap. Follow through. I track minor issues until they’re resolved to prevent small cracks from growing over time. This approach has helped me stay proactive and build better products with fewer surprises down the road. What about you? How do you prevent small issues from turning into big ones?

Over the past few months, I’ve been developing a new muscle—one I had never consciously exercised before. In fact, I didn’t even realize it was worth strengthening. But the more I thought about it, the more sense it made. And after reading this, I believe you’ll start to see the benefits of strategically activating it as well. Chances are, many of you already use this muscle without realizing it. We’ve all heard the saying, “Patience is a virtue.”  Every time someone says it, people instinctively nod in agreement. It’s treated as an unquestioned truth. I’ve never heard an argument against it, and I won’t make one now—because I, too, believe patience has its place. But what about impatience? If patience is a virtue, does that make impatience a flaw? Is it something we should always suppress and replace with patience? That’s what I used to believe. But I’ve started to see impatience in a new light—as a force that, when used intentionally, can drive action, spark change, and fuel growth. I’ve been channeling impatience into my personal and professional development. I want to learn, experiment, and grow quickly, not slowly . While I remain patient with results, I refuse to be patient about taking action. I no longer see impatience as a weakness—it’s a tool I can hone to get things done. For too long, I blindly accepted that patience was always the right answer. But now, I’m learning to embrace the other side of the coin. Each has its drawbacks, and wisdom comes from knowing when  to lean into which. So, instead of suppressing your impatience, try harnessing it. Let it push you forward. Let it get you where you want to go— faster.

A product owner has more responsibilities today than at any point in the last ten years as more companies are consolidating the responsibilities of the project manager and scrum master into the product owner role. Ten years ago, it was common for each development team to have a dedicated scrum master, project manager, and product owner as distinct team members. Today, however, it is more common for development teams to be staffed with just the product owner. It would be interesting to discuss how and why we arrived at this point, but the more important question is: Are you, as a product owner, equipped to thrive in today’s environment? It is essential to stress that if you want to be a successful product owner today, whether at a startup or a top-tier investment bank, you need to be competent as a product owner, project manager, and scrum master. While we all can agree that each of these roles adds value to the team in different ways, what tends to go unnoticed is the stress and frustration that builds up within the team when there is an imbalance in these skill sets. Let’s explore this imbalance further. First, let’s summarize the high-level responsibilities of each of these three roles: The scrum master focuses on promoting continuous improvement around team dynamics and processes. The project manager’s attention is on managing risks and delivery timelines. The product owner stewards the priorities and product strategy. Now, let’s take a quick look at a couple of real-world examples of what can occur when there is an imbalance in just one of these skill sets: I have seen senior product owners explain that the poor team dynamics were simply a reality of the working environment due to the personalities on the team. After stepping into the situation, I quickly observed that the resentment among certain team members was due to their lack of input on the proposed solutions. It never occurred to this product owner that the poor team dynamics were actually a result of how the agile ceremonies were being run and how team members were allowed to participate. Within a few weeks, we made some tweaks to the meetings to allow others to share their opinions, which increased team morale. I have seen a senior product owner be unaware that they were not going to hit their milestones based on how they were tracking project progress. This product owner failed to create a mitigation plan to get the project back on track until it was already apparent that the milestone would be missed, resulting in the project going over budget. These are just a couple of my experiences, and I am sure you can think back on your experiences and find examples of this imbalance occurring within the development teams you have been a part of. Regardless of whether we think it is fair or not that a product owner needs to be competent across all these skills, we can agree that this skill set is now necessary to excel in this role. Even if you are among the product owners that gets support from individual scrum masters or project managers be aware that this may not always be the case. By sharpening our skills across these three pillars, we can ensure that we, ourselves, can provide our development teams with the appropriate support and, more importantly, give ourselves the confidence to excel in our day-to-day tasks while securing our ability to lead teams now and in the future. If you would like to learn more about how to improve your skill-set in these areas please reach out or you can also follow my page to continue to learn more things on this topic.

Are you aware that some members of your team might be reluctant to ask for help? This reluctance affects both your top performers and those who are struggling, although it might surprise you to hear that top performers are included. Today, we'll focus on why even your best team members often hesitate to seek help. I recall a situation with an engineering lead managing a multi-million dollar project. A couple of team members mentioned that the lead had rewritten their code during the review process. The lead was very proud, telling me about staying up all night to complete this feature. At the next day's stand-up, the lead stood tall, as if they had saved day. This lead firmly believed in the "do-it-yourself" approach to ensure speed and quality. While this method initially seemed to produce good results, it eventually led to several problems. It created a dependency where team members relied solely on the lead to complete tasks. When the lead was unavailable, progress would come to a near halt. This model provided acceptable short-term returns but it created significant long-term challenges. Ultimately, this approach led to burnout for the lead, who ironically ended up complaining about the lack of support. Meanwhile, other team members that felt stifled in their growth left for new opportunities. Those who remained relied on the lead to carry the load. This is a common situation that plays out across industries. I have learned strategies that help you avoid this situation altogether as well as strategies that can help you course correct if you are in this situation. If you're interested in learning more about fostering a more collaborative and sustainable team dynamic, please reach out. If you found this insight helpful, please like and share, and I'll continue to provide more content.

Do you recall a time when a deadline slipped through your grasp? That sinking feeling of falling short of expectations, followed by the inevitable postmortem with your team? If this scenario sounds familiar, you may have encountered the culprit: "context switching." It's a term often thrown around when tasks pile up and focus scatters. But do you remember how you tackled this issue? When team members lament about context switching, it signals a belief that shifting focus between tasks eats away valuable time, ultimately contributing to missed deadlines. The instinctive response is to remove distractions, allowing for sustained focus on primary tasks. While this is a common remedy, could there be an alternative, perhaps a more beneficial one in the long run? I propose that teams and individuals stand to gain by reframing this challenge. Consider a day in the life of a lead developer: Providing technical leadership to the team Making architectural design decisions Supporting product and design with feedback on new features Assisting with project planning Making progress on a user story Conducting 1:1 meetings with direct reports Performing code reviews Troubleshooting issues and fixing defects Now, contrast that with a typical day for a junior developer: Making progress on a user story Conducting code reviews Addressing defects It's no surprise that senior team members shoulder more responsibilities than their junior counterparts. But how does this relate to context switching? How do high-performing senior team members manage to juggle multiple tasks without stretching the workday beyond its limits? In my view, mastering the art of context switching is key. Top performers at senior levels demonstrate an ability to pivot swiftly and excel in various tasks without dwelling on the past or worrying about the future. They channel their undivided attention into the present task, maximizing productivity and efficiency. I call this "working in the moment." By honing this skill, you not only boost your productivity but also accelerate your career trajectory. Your colleagues and supervisors will take note of your ability to handle diverse tasks adeptly, paving the way for more significant opportunities and rapid skill development. If you're eager to fast-track your career or enhance your work-life balance, let's connect and embark on a journey to elevate your productivity.

If you want to be a great product owner then one skill you must be great at is managing priorities and if you would like to learn how to become better at this then I invite you to play a quick game with me: Picture a moment when you worked with a team and the priorities were unclear, muddled, or constantly changing. As you do this, try to remember who you were with, the company you worked for, and what meeting you where in. Once you have this picture take a second and think about how it felt to be in that situation. I imagine you were able to feel the frustration, confusion, and stress that you, team members, or stakeholders often feel in this situation. Unfortunately this is a common experience that software development teams find themselves in more often than they would like. The good news is that as product owners we can keep those types of situations from ever occurring by being great at managing the team’s priorities by focusing the team on delivering work that delivers wins to the business. If you follow sports then you may be familiar with the phrase “winning cures all” which means that nothing helps lift the mood more and reduce the tension more in the organization than winning. Winning makes work more fun as objectives are met and when work is more fun we are more creative, more productive, and more pleasurable to be around. I think that as product owners we can greatly influence winning by being better at managing priorities because the priorities influence future outcomes. If you want to help yourself, your team, and your company win more then we need to be great at managing priorities. If you would like to continue to learn more then follow this simple guide or reach out to me to discover a more personalized approach to learn how to get better at this skill. Four easy steps to improve how you manage priorities: Write down your desired outcomes over a day, week, month, or any time period Rank order your outcomes Analyze your current behaviors and decisions as they pertain to your desired outcomes Repeat 1 - 3 Example: My outcome for today is to keep my body in shape, nourish it, rest it, and expand my professional network. I then ordered my outcomes in the following order. Play soccer Cook a healthy meal Get at least 8 hours of sleep Grow professional network Now let’s use this real-world example to see how this works: In the middle of the workday I am invited to join co-workers for happy hour and by going I get an extra opportunity to grow my professional network. Scenario A - Prior to setting my outcomes: Go to happy hour Consume multiple drinks Eat bar food which was often fried and unhealthy food Stay out late Go home Go to sleep late Outcome A: Spent entire evening building professional connections, but did not make any progress on other desired outcomes. Scenario B - After setting my outcomes: Go to happy hour and consume a non-alcoholic beverage Leave in time to play soccer Go home Cook a healthy meal Go to sleep early Outcome B: Was able to achieve all my main outcomes and while making some progress on growing my professional network. The differences between scenario A and B stem from being able to make intentional decisions that are aligned with my outcomes. I was better at this under scenario B than scenario A because I had very explicit outcomes to help me understand the implications of my decisions as it pertained to my desired outcomes. As a result my decision making has improved significantly because I now make more choices that are more aligned with my outcomes. This skill is critical as a product owner because we frequently have to make prioritization decisions and we need our decisions to yield great outcomes. Furthermore when we put our team in a position to produce great outcomes then we then help create an environment that is more fun, creative, and pleasurable for everyone involved because we yield more wins for everyone involved. If you would like to learn more please reach out or share this with anyone that you think can benefit from this.

Product owners are the liaisons between the business and the engineering team. They are responsible for distilling business needs into product requirements. In agile settings, the user story is often the medium that is used to communicate the requirements and acceptance criteria to the engineering team. In turn, the engineers consume the user stories to understand what they need to implement. Over the course of a project the engineers will consume a steady diet of these stories and like food or entertainment or anything else we consume, the cost and quality of what we consume has a significant impact on the satisfaction that we derive from it. As such like anything that we consume, user stories can also please or dissatisfy the consumer depending on the quality of the user story. In my experience one of the most common ways that the product owner begins to lose the trust of the team is by producing low quality user stories. A low quality user story can come in a variety of shapes and sizes. For example, it can be too vague or it can be too long and detailed. It can also be incomplete because it is missing certain scenarios or it may lack corresponding artifacts such as UX designs. Engineers that consume these types of stories will begin to become demotivated as they realize that they do not have the requisite information to fully understand the work that needs to be done. They then have to spend extra energy to figure out how to improve the content of the stories to get it to a point where they have appropriate information. Implementation that proceeds with low quality stories will inevitably lead to defects which will exacerbate the distaste with the user stories and the team’s product owner. On the flipside, a high quality user story is a delight to engineers because it makes it easy to digest and understand the work that needs to be done. This plays a large role in the overall satisfaction in the relationship between engineers and the product owners. As a result, I believe that producing high quality user stories is a key component of successful software development not just because it provides the engineering team with clear directions, but also because of the emotional impact it has on them as well. As a result, this has to be a core skill of every product owner or anyone that is producing stories. If you are interested in learning more about how to ensure that you or your team produce high quality stories please do not hesitate to reach out.