Situational Product Management Episode 2: Confidence in Product Management
The Confident(less) Product Manager
Hello Product Protégés,
Happy belated Thanksgiving! I hope your holiday was a refreshing break from the world of product management. But now, as we get back into the swing of things, let's dive into the next episode of our Situational Product Management series.
Today, we're addressing a cold hard truth: confidence is a cornerstone of successful product management. Without it, your journey to success will be difficult.
This episode focuses on Jimmy, a product manager at 'On the Clock,' a mid-sized B2B SaaS company. Jimmy faces a crucial challenge: how to build confidence and effectively communicate his vision for the company's dashboard tool, which tracks employee appointments and meetings to optimize efficiency and resource allocation. We delve into his journey of learning from customer feedback, refining product strategies, and navigating team dynamics to enhance his product management skills."
Let’s dig in!
Have you ever been in a role where you're executing someone else's vision, and had moments of doubt: "Why are we doing this?" or "I'm not sure this will work." These thoughts are amplified if the person leading lacks confidence.
As product managers, we are leaders. And leadership demands a high level of confidence - not the arrogance of always being right, but the certainty in your vision, strategy, and ability to empathize with and advocate for your customers.
How do you build this confidence?
It starts with mastering the essentials of product management: understanding the product lifecycle, effective communication with co-creators, and proficiency in creating key artifacts like pitch decks, epics, user stories, roadmaps, and vision & strategy documents. Your co-creators should see your preparedness and be inspired by the work product you present to them and the confidence you exhibit when sharing.
But remember, confidence isn't about clinging stubbornly to your ideas. It's about holding strong beliefs while being open to better paths and ideas, regardless of their source.
Let’s meet Jimmy
Meet Jimmy, a product manager at a mid-sized B2B SaaS company, “On the Clock.”
On the Clock provides businesses a dashboard for their employee’s appointments and meetings across the company to understand efficiency, redundancy, and resource allocation.
Jimmy is six months into his tenure at On the Clock. With little to no formal training about the business, he was advised to "talk to the customer." His background in B2C product management comes more from self-education through YouTube and podcasts than formal training. In his previous role, he transitioned from a project manager to a product manager, but without this self-initiated learning, he might have remained confined to Gantt charts and executing leadership's directives.
Now, in a new team and at a new company, Jimmy aims to hone his product management skills and make significant contributions to the product's progress.
He is the third product person to join the team. The first two, initially business analysts, were transitioned into associate product manager roles without formal training. Their work mainly revolves around operational maintenance, whereas Jimmy's role is more innovation-centric.
While talking to several paying customers, it became apparent that employees at these companies using their software found the tool interesting but had concerns. They worried it might recommend evening meetings to accommodate senior leadership. Additionally, they were uneasy about the increased scrutiny on their calendars. Some felt compelled to accept "recommended" meetings to avoid missing out, while others feared appearing unproductive if they attended too many meetings. Essentially, employees used the tool out of necessity, not fully understanding its benefits.
Conversely, feedback from business managers, another customer group, was positive. They appreciated gaining better insights into the number of meetings their teams were asked to join. The feature suggesting optimal times for weekly meetings, based on team availability, was particularly well-received. By dynamically scheduling weekly meetings, the tool helped minimize disruptions caused by meeting overload.
After getting back from meeting with customers face to face, Jimmy was energized and had some ideas of how he could help innovate the experience for their customers.
Jimmy brainstormed and positioned them as problems and solutions.
1. For Employees:
Problem Statement: Employees currently feel overwhelmed and under-informed about the benefits of the scheduling tool, leading to reluctance in its usage and potential underutilization of its features.
Solution Statement: Implement a targeted marketing campaign to enhance employee understanding of the tool's benefits, integrate auto-generated meeting minutes for efficiency, introduce dynamic meeting scheduling to reduce disruptions, and offer a 'do not disturb' feature for focused work times.
2. For Managers:
Problem Statement: Managers lack comprehensive visibility into the true cost and efficiency of meetings, hindering informed decision-making about team productivity and resource allocation.
Solution Statement: Develop enhanced dashboards that visualize the financial impact of meetings, provide analytical insights into employee collaboration patterns, and offer a consolidated view of meeting minutes to enable managers to optimize team schedules and meeting effectiveness.
Armed with these ideas, Jimmy felt it was time to consult with various departments for stakeholder feedback.
Marketing:
They were supportive of updating the copy to reflect employees' experiences.
They mentioned allocating some budget to the initiatives Jimmy discussed, but noted they couldn't fund all of them at once and would need to prioritize.
Legal:
They expressed a need to review the terms and agreements if arbitrary dollar amounts were shown for meetings, emphasizing that these figures are assumptions and the actual monetary impact varies based on the customer's finances.
Lead Developer:
In a one-on-one meeting, Jimmy presented his ideas. The lead developer recalled similar past efforts that didn’t succeed and suggested discussing these in a detailed refinement session. He appeared somewhat skeptical about the effort versus the value of Jimmy's ideas, partly because Jimmy hadn't fully fleshed out the concepts beyond "a few customers said."
Lead UX:
Their discussion extended 45 minutes beyond the scheduled time, leading to 10 new ideas needing consideration for the backlog. These ideas varied in scale and scope.
Some ideas required a technical feasibility review with lead developers. Jimmy attempted to focus on 1-2 primary ideas, but the UX lead expressed interest in exploring a broader range based on the entire discussion, rather than limiting to just one or two concepts immediately.
Jimmy integrated some of the feedback he received into his approach, but his enthusiasm led him to hastily complete his epics and user stories. Everyone should just get it, the customer is saying this therefore we must do it! After outlining high-level epics and crafting some basic user stories for his ideas, Jimmy felt prepared for the refinement session and eager to share the problems he found and his solutions.
He had gathered valuable information and structured it in a format he believed would be effective. During the refinement session, Jimmy immediately dove into detailing the problems customers faced and enthusiastically discussed how his solutions would significantly address these issues.
However, the refinement session initially proceeded quietly, with Jimmy speaking uninterrupted for about 25 minutes. When he finally paused for questions, several issues surfaced:
The Lead Developer and QA pointed out the absence of 'Given/When/Then' scenarios for edge cases and requested that the discussion be postponed until these were included.
A developer inquired about the error messages that needed to be addressed, to which the UX team responded, "Not sure, product never told us."
The UX team expressed confusion, as they had been working on different iterations than what Jimmy presented, ideas that the UX Lead had provided them to work on. They sought clarification on when the epics and user stories for their ongoing projects would be available, which left Jimmy questioning what his own priorities were.
The Analytics team asked about the data that needed tagging. Realizing that the scope of the project was changing, they opted to leave the meeting early to avoid wasting time.
Several team members asked Jimmy to revisit the epic for further clarification on its scope before delving into the user stories.
Of the three epics and 35 user stories Jimmy prepared, the team managed to review only one epic and three user stories before deciding to reschedule the session for a later date.
So, what went wrong?
Jimmy left the refinement session feeling defeated. He had presented great customer feedback in a format he believed would aid the team's understanding, but he failed to connect. He couldn't cover much ground and was unprepared for some questions. When asked, "Why are we doing this?" his response was, "Well, what do you all want to do?" instead of confidently backing his proposal.
Jimmy now faces a deficit in trust from his team and must work diligently to regain it. This situation highlights that his challenges extend beyond confidence to include issues of preparedness.
The reason we are focusing on confidence, is that to be confident in your approach, scope, and presentation of ideas, you have to do the work. Hard work and confidence go hand in hand.
What went wrong?
Jimmy had effectively written a problem statement and solution but missed crucial components, such as observations explaining why it's a problem (including both qualitative and quantitative data to demonstrate its significance and relevance) and the goals, KPIs, and expected outcomes. He could have utilized the pitch deck format from the Product Protégé Guide to narrate a cohesive story.
I understand that every organization has it’s challenges when it comes to tagging digital experiences as well as having a consistent pipeline of valuable customer feedback, but regardless of what is available, Jimmy can show intent of how he intends to impact specific KPIs and what signals he will look for to know if he is successful.
Claiming to 'impact customer happiness' without defining the metric, understanding the current baseline, or analyzing success, turns it into merely an idea lacking substantive reasoning.
Below are some things Jimmy could have done to help get his great ideas across to his co-creators.
Before initiating new work based on feedback, Jimmy should have conducted a roadmap review. He could have themed this work as a "Customer Centric Feedback Roadmap," providing a cohesive context for the discussion. By aligning all ideas and prioritizing them, he could have presented a clear vision of where the team was headed.
This would have empowered Jimmy to confidently discuss why specific features were chosen and their timing. Tying a dollar amount or a KPI to these features would have strengthened his case, illustrating how they align with the team's vision and strategy. Keeping this information on a platform like Confluence would have made it easily accessible to the team.
Jimmy should have adopted formats for epics and user stories that address all potential hurdles faced by his co-creators. Some successful formats and templates are available in the Product Protégé Guide.
He should have acknowledged the team's hard work during the refinement and highlighted the positive aspects of the feedback. Since co-creators often don't hear direct feedback from customers, it's beneficial to start with positives and then highlight opportunities for improvement.
A pre-refinement session with the lead UX and lead developer would have been beneficial once Jimmy's epics and user stories were nearly complete. This would have allowed him to receive early feedback and address any gaps. This is such a crucial step and worth the extra meeting.
If Jimmy had been more engaged with the process and able to step back to identify gaps in his approach, then zoom in to address them, he would have been better prepared to handle the feedback and concerns as well as prepare his material to proactively remove hurdles.
This holistic understanding and confidence in the process are why I wrote the Product Protégé Guide. A product manager who is fully confident in their journey, understands the 'why' behind their actions, documents the 'what' effectively, and consistently communicates this, will be successful. They will earn the trust of their co-creators, who will recognize the effort put in before any collective work begins.
This week’s Situational Product Management scenario illustrates the importance of confidence in product management. It's not just about having great ideas; it's about effectively communicating them, anticipating questions by doing the prep work, and connecting every task to the larger vision and strategy.
I hope this episode helps you see the value in building confidence as a product manager. Remember, the Product Protégé Guide and Weekly Newsletter is here to support you in developing a strong foundation for digital product management.
Enjoy these case studies? Let me know, and I’ll keep them coming!
Until next week, keep building your confidence, and may your product management journey be successful! 🚀
