Episode 4… 9 Quotes from A Day in the Life of a Product Person
Including stories, commentary, and examples.
Welcome to Episode 4 of our "Day in the Life of" series.
This week, we're focusing on "9 Quotes from A Day In the Life of a Product Person."
These are quotes I've said, heard from co-creators, or leadership, which highlight daily experiences in product management. Whether you find these familiar, are here to learn about product management, or are seasoned in the field and might use these quotes yourself, this episode is for you.
Let’s jump in
1 -“We’re not launching tomorrow”
When this is said by a Lead Developer, it brings an immediate sense of reality. It’s a moment where hope meets the hard truth, and despite the team's effort and the anticipation of positive customer feedback, we face a delay. This isn't just a casual comment; it's a culmination of hard decisions and work, deeply cared for by the development and QA team. For you, it means navigating the tricky waters of stakeholder communication, ensuring everyone is informed and understands the reasons behind the delay. This is not fun but uber important. Get your facts and story together before the call is made to delay the release and let them know as soon as you can. See email templates and more in Product Protégé Guide
2 -“Hey – we asked for a feature months ago but I don’t see it listed on the roadmap, please don’t tell me it's on the backlog again”
This phrase often echoes in the tense atmosphere of a roadmap update meeting. Picture this: I'm standing before a diverse group of stakeholders from marketing, merchandising, and other business units. As we progress through the agenda, nods of approval are interspersed with looks of anticipation. Then, the inevitable question comes, pausing the room. “Hey – we asked for a feature months ago but I don’t see it listed on the roadmap, please don’t tell me it's on the backlog again” I took a moment to emphasize the thoughtful evaluation each roadmap item undergoes to ensure alignment with our overarching goals. "The feature remains in our backlog after we scrutinized the feature by building a pitch deck," I explain, "and found that the problem it aims to address is not as much as an issue outside of a few customers A more efficient, less resource-intensive solution can be implemented to satisfy the few affected customers." This approach underscores the principle that while feedback is invaluable, it must be weighed against data and strategic objectives. By involving stakeholders in the investigative process—utilizing pitch decks, probing questions, and collaborative analysis—we not only validate the significance of their input but also engage them in understanding the rationale behind prioritization decisions. This collaborative vetting process not only ensures that our efforts are strategically aligned but also cultivates a deeper investment from our partners in the product's success. Remember feedback is a gift!
3 - “Don't absorb other's emotions.”
When I was working under one of my mentors, they offered a pivotal piece of advice: “Don't absorb others' emotions.” This wisdom came after a challenging meeting where I was presenting a plan to implement a recommendation engine on our product list pages for search and category landings. The goal was to enhance our add-to-cart rates by leveraging AI to better understand customer intent, search history, and previous purchases. Despite the clear benefits, opposition arose, particularly from the merchandising team, concerned about the potential impact on product sell-through for high-stock items.
A couple of slides into my presentation, a pointed question from a leader shifted the momentum to the skeptics. Frustrated, I defended the proposal, noting that the algorithm accounted for margin and stock rate, but also aimed to personalize product recommendations. The tension escalated as I, visibly upset, argued against the short-term focus on stock clearance, advocating instead for a strategy that aligns with customer preferences.
The meeting concluded with my boss suggesting a smaller session to iron out the details, emphasizing the need for a pilot to assess the recommendation engine's impact. Pulling me aside, they reiterated, “Next time, don't absorb others' emotions.” They suggested that I could have deferred the contentious point to a later slide, thus maintaining control of the narrative. My attachment to the proposal and the emotional intensity of my defense, they pointed out, may have overshadowed the rationale behind it. Holding strong beliefs loosely, they advised, would allow for a more balanced discussion and potentially avoid prolonging the decision-making process. This lesson in emotional intelligence—a reminder to focus on the facts and strategy without getting swayed by the room's emotions—has been invaluable in navigating the complex dynamics of product management.
4 - “Scope, Quality, and Time – you only get 2”
This principle reminds us of the inherent trade-offs in product management. Various project management books echo this sentiment, but it's always beneficial to remind everyone involved of the inherent trade-offs between scope, quality, and time. This principle helps product people and their co-creators recognize the constraints they're working within and the importance of not chasing perfection. For instance, when a request comes in to "add xyz to this capability," it's a sign of potential scope creep. While accommodating such additions is sometimes possible, it usually means the project will take longer or the quality of the product might suffer. The takeaway is clear: if we're not willing to compromise on quality, we need more time. If additional time isn't available, then we must be prepared to reduce the scope in other areas or accept a few more imperfections than usual (at this point, considering a pilot could be a wise move).
5 - “Product is the Why and the What; Our Developers, Designers, and QA Teams are the How”
To be good product manager, you must understand the worlds of your co-creators to interact with them successfully. To be an excellent product manager knows the extent of their knowledge and when to defer to the experts. It's crucial to inquire about the "how" in a manner that doesn't seem like you're trying to dictate the process. For example, as a more experienced product manager, I might recognize a similarity between a feature in development and an existing capability during a meeting. I might suggest, "I think we do something similar on another page that's currently live; let's use the same backend." However, this well-intentioned suggestion could inadvertently limit the team if the existing backend isn't scalable for future needs, even though a developer might have a more suitable, albeit different, approach in mind. The key is to propose ideas without imposing them, perhaps by saying, "Do we have any similar functionalities on our site, and what can we learn from them before developing this new feature?" This way you can ensure that question is answered before a final and not box in the team before an approach is concluded. Remember, your role is to define the 'why' and the 'what'—the purpose behind the project and what needs to be accomplished, outlined through vision, strategy, roadmap, epics, and user stories.
The division of responsibilities between product and UX further illustrates this point:
Product Ownership:
The "Why": Clarify and communicate the business or user need driving the project.
The "What": Specify the deliverables that will fulfill this need.
Requirement Articulation: Ensure that requirements adhere to a standardized user story format.
Decision-Making: Hold the authority to decide when a design meets the necessary requirements to move forward into development.
UX Ownership:
Design Structure: Determine the placement of elements on the page.
Aesthetics: Select visual elements such as colors and typography to enhance the design.
Design Consistency: Maintain a unified design language across all products and pages.
Implementation: Develop designs based on the provided requirements, ensuring alignment with the intended user story.
Ideation: While proposing new concepts or additions is encouraged, these should be presented separately from the original request to maintain efficiency in the process. We may put your idea in a future phase, but the current phase can continue on.
6 - “I'll take the meeting notes”
Eventually, AI may take over note-taking for most organizations, but until then, you have the opportunity to volunteer for this task. It doesn't matter if you're the most senior person in the call; by taking notes, you gain the chance to shape the meeting's narrative. This allows you to highlight the most critical points and bring together information in a way that clarifies outcomes for the team. Along the way, you can subtly weave in your perspectives as you recount the story.
Imagine how awesome it would be to get our weekly newsletter every Monday in your inbox! We promise to be super tactical!
Subscribed
7 - “I’m doing too much”
Whether it's defining an MVP, crafting overly detailed user stories, or creating a 24-month roadmap with unrealistic precision, it can be an indication of doing too much. The KISS principle ("Keep It Simple, Stupid") is crucial here. Striving for simplicity is key. I appreciate when my product managers adopt a scrappy approach to gather the necessary insights to justify the investment in a feature – doing just enough to get the job done. Similarly, having user stories that are consistent in their structure and information content makes creating the user stories and collaboration with co-creators smoother and more systematic. It's important to recognize when something is "good enough" and not let the pursuit of perfection get in the way of meaninful progress.
8 - “I'm 90% confident I know what will launch in the next month, 75% confident in the next 2 months, and 50% confident on scope and timing for any feature rollouts beyond that.”
Numerous factors can lead to changes. Team members might leave, significant bugs could emerge, or a third-party vendor might release an update requiring immediate attention. Leadership might also shift priorities, either halting a current project or initiating a new one. Feedback from MVPs or changes in investment focus can further influence our plans. Given these variables, it becomes challenging to commit to exact dates for feature releases beyond a month. While I may provide a specific date under pressure, especially from higher-level executives, it's with the understanding that other ongoing projects might need to be deprioritized to meet that deadline. Providing a date as a product manager should only come after consulting with the co-creators that will build the capability. You’ll want their buy in and sense any risks associated with delivery before giving a date to anyone.
9 - “Let me give you an analogy.”
I frequently use analogies to clarify complex concepts. The book "Shortcut" by John Pollack highlights the significant role analogies play in problem-solving and innovation, especially in digital product management. Pollack demonstrates how drawing parallels between distinct ideas can generate insights for product design and user experience. The emphasis on analogical thinking as a tool for effectively communicating intricate ideas underscores its value for product managers. By employing analogies, we can spark creativity, clarity, and enhance team collaboration.
"Is the build out for this feature like pouring concrete for a house, or is it like adding a piece of art to the wall?"
Pouring concrete is foundational. It's about setting the structure and framework upon which everything else will be built. In software terms, this could relate to core functionalities or essential infrastructure changes that are critical for the application to function. These are the features that need to be carefully planned and executed early in the development process because changing them later would be as difficult and disruptive as altering the foundation of a house after it's been built.
On the other hand, adding a piece of art to the wall is more about enhancement and personalization. These features might include user interface improvements, additional functionalities that increase user satisfaction, or elements that make the product more enjoyable or easier to use. Unlike foundational features, these can often be added, changed, or removed with much less impact on the overall structure. They offer a way to differentiate the product and enhance the user experience without altering the core functionality.
—
These quotes are more than just words; they're reflections of the challenges, strategies, and insights that come with the territory in product management. Writing this was a joyful experience as I was able to reflect on areas in my career where these things came up, and how I’ve changed over time (or haven’t changed at all!) If you find resonance with these ideas or have your own quotes to share, I'd love to hear from you.
Until next week!
