Category: Uncategorized

It’s the start of a new quarter, and thus it’s time to make plans, share them, and decide how to best execute them. One of my favorite activities during this time is a reflection on plan risks with the development team, for a couple reasons. First, it serves as a venue to share the upcoming plan if it hasn’t already been shared. Second, it lets team members get pessimistic and vent their fears about the future in a safe space. Third, if the reflection is focused on actionable risk mitigations, it leads to a plan that is much more likely to succeed.

Talking about risks and risk mitigation can be tricky for a new product manager as the topic can appear much more complex than it needs to be. Often someone new to risk management will jump to having to calculate revenue exposure, probability of risk materialization, and other numbers that can feel like wild guesses. However, if tbey focus on the goal of risk discovery as identifying actionable mitigation strategies to make a plan successful, rather than calculating the financial impact of risks, these numbers are not important. What the risk management needs to do is identify the top risks and focus on what the Team can do to mitigate the risk materialization.

To identify the top risks, I have Teams first think widely about everything that could go wrong. To then prioritize the top risks, I have the Team rate each risk on two metrics: probability of materilization and impact if it does materialize. Rather than getting numeric values, I have them rate the risks relative to each other via a low/medium/high rating for each. Typically one or two risks will get a high/high rating for probability and impact of materialization, and these are the risks we discuss. Not only can this simplified framework help a new product manager discuss risks with a Team, it can help them think about risks and experiments for their products. By keeping risk management simple, they’ll be much more likely to incorporate it into planning and critical thinking about products and plans.

If you’d like to read more about risk mitigation, I suggest DeMarco’s Waltzing with Bears as an enjoyable and accessible way to understand risk management and be successful talking about risks in product development.

This week marked the end of Jenni’s first two weeks, so we took a moment from a hectic week to see how things are going and how we can improve. I’m a big fan of regularly scheduled retrospectives and checkins. Not only do they ensure a team is thinking big picture, it gives a safe space for giving feedback. Whether a team is doing great or unexpectedly poorly, a regularly scheduled checkin gives a chance for team members to voice complaints or thoughts for improvement.

I kept the checkin informal to allow the conversation to go wherever it needed to go. The goal was to get Jenni’s opinion on how onboarding is going, fill in any missing puzzle pieces to solidify her knowledge, and identify risks to meeting her 30-day onboarding goals. Below are my conversation-starters that you could use in an onboarding checkin too. For all of them, be sure to ask “Why?” to get the most out of them.

• What one word best describes your onboarding experience?
• What’s been your favorite moment so far?
• Has your onboarding matched your expectations for being a Product Manager?
• What’s still confusing in what you’ve learned?
• Have you met anyone that you aren’t sure what they do?
• Are you feeling confident in meeting your 30-day onboarding goals?

I expect to have such checkins at least every two weeks to continually improve Jenni’s onboarding experience.

Recently I had to quickly learn about a product from another expert as he was leaving the company. Through past experiences, there are two things to keep in mind when taking over a product on short notice. First, schedule several 30-minute sessions with the former expert as soon as you can, as their calendar often books up fast in their final weeks before going out the door, and invaluable ‘brain-dumping’ and knowledge sharing can be forgotten. I’d suggest spreading a couple sessions out over the final weeks or days so you have time to digest and research between each to get the most out of them.

Second, instead of focusing on the ‘what’ or ‘how’ of a product, focus on the ‘why.’ Many people in an organization know what a product does as they must sell or support it, or how it works because they’ve had to technically maintain it, but very few understand why it behaves that way. Knowing the ‘why’ relies on historic knowledge, of being there when something was built, and is thus easily lost when someone leaves the company. These reasons may be technical limitations, customer learning, or just features that had to be slimmed due to the time constraints. Others in the company may assume these product limitations are non-negotiable or are based on non-existent research and thus should not be changed. Only the former expert knows the real truth for why they’re that way, and how things that are considered sacred were initially due to temporary constraints.

One example in my recent knowledge transfer for why ‘why’ is important was around the product’s icon set. Some of the icons aren’t intuitive, and the reason why they’re that way is because the UX designer wasn’t available at the time they were added, so a Developer chose them. Without knowing the ‘why’ I might think the icons were based on customer feedback or discovery and thus should not be changed, but the truth is that I could easily correct them to something more intuitive.

When training a new Product Manager, the same focus on ‘why’ is important. Teaching the rationale behind existing features and prior decisions gives a framework for knowing the product, its history, and the customer context. And knowing the ‘why’ gives the new Product Manager confidence to make their own choices and decisions founded on prior research. They can also use this ‘why’ to show expertise in the product when working with stakeholders, quickly owning a mastery of the product by having the lesser known, but very important, ‘why’ behind features.

So whether it’s you learning about a product from an existing expert, or you’re teaching your expertise to another, focus on the ‘why’ for features to ensure you get the full story and know the real reason the product exists as it does.

Thus begins an excellent adventure in the joys of Product Management. I look forward to your company as I train others how to succeed with Agile, Product Management, and whatever cool new techniques I find along the way. I hope you’ll get the following from this journey:

• Gain skills to help you be a great Product Manager, no matter if you’re new to the field or a veteran
• Learn how to train others in Product Management
• Have fun

My name is William Kammersell and I’ve had a variety of roles over my career thus far. I began as a software developer, became a scrum master, then a product owner. I wanted to switch to product management, so I took a role as an associate product manager that soon became a full-on product manager. I then had a short stint as an agile coach, and am now back to product management. If you’d like to see the full story, check out my LinkedIn profile.

I always seek to learn new skills and I love sharing them with others. I hope this blog will be an incredible way to share my learning  and experiences with others, creating a valuable resource in the field of product management.