Starting the Product Manager Journey: Where to begin?

Recently, I found myself pondering, "If I were to embark on the journey of building products from scratch, which concept should I prioritize learning first?" After careful consideration, I've pinpointed the 4-step process of Discovery, Design, Development, Launch & Learning. I firmly believe that this framework serves as the foundation of a Product Manager's craft, and it's crucial for non-product leaders to grasp its significance. While it may seem straightforward, I've witnessed both myself and other teams underestimate its simplicity time and time again, often resulting in costly consequences. Let me illustrate three manifestations of this problem, ranging from less matured teams to more matured ones:

Level 1 - Overemphasis on one pillar: "How many features did we build last year? What features are we building this year?" This is the typical focus of discussion in execution-centric teams, often humorously referred to as "feature factories." Superior teams integrate discovery, design, execution, and learning to deliver impactful solutions while eliminating those that don't.

Level 2 - Lack of depth in any one or more of these areas: "AI is a great solution; we interviewed 20 customers, and they all said yes, let's do this." Chasing solutions without clearly defined problems is a recipe for disaster. And interviews represent just one of many sources for customer discovery. Effective teams combine multiple sources of discovery and employ various validation techniques, especially when the potential impact is substantial. Moreover, they sometimes bypass customer discovery when the circumstances warrant it (stay with me here).?

Level 3 - Equal focus on all: "Have we checked all the boxes?" In reality, it's a strategic misstep to allocate equal attention to all four pillars. This is because every feature, product, or business goes through a cycle of learning, growth, expansion, and stability. Exceptional teams strategically employ these levers to propel the product into the next stage of its lifecycle.?

So, what are some of the nuances of this 5-step process?

Discovery

Discovery entails a two-step process: building hypotheses and validating them.

When formulating hypotheses, we seek to answer key questions:

• How will the product/feature benefit my organization?
• How will it benefit my customers? (considering user demographics, the problems they face, problem intensity, current alternatives, and their goals)
• How will it benefit my business?

Validation involves examining both user and business value.

• User Value: Techniques like customer interviews delve deeper than what's visible on the surface. There are intricacies in audience selection (identifying the right audience, sourcing, improving response rates, and screening), structuring interviews (introduction, avoiding leading responses, and knowing when to deviate from the script), and analyzing them (individually and collectively).
• Business Value: At this stage, estimates are inherently imperfect, but that's acceptable. Selecting the right set of metrics takes precedence. One approach to validating business value is to begin with the customer journey and benchmark it using the best available techniques (market data, performance of other products within your company, logical analysis).?

The discovery phase typically concludes with Communication #1 to secure buy-in from senior stakeholders.?

Design

I view design through the lens of divergence and convergence.

Counterintuitively, the divergence process is best initiated by first defining constraints (Product vision from the annual strategy exercise + Solution boundaries derived from the discovery exercise). Subsequently, we can employ various design techniques to generate as many ideas as possible and structure/nest them if necessary. Design sprints provide an excellent platform for involving peer groups, encouraging individual thinking, and making the process enjoyable.

In contrast, the convergence process demands scientific rigor. It involves answering two key questions:?

• How do we prioritize solutions (utilizing frameworks such as RICE, Desirability/Usability/Feasibility/Viability, Moscow, etc.)?
• How do we conduct Prototype Testing? Prototype testing may require several iterations but essentially involves exploration (selecting the right testers, determining fidelity levels, moderating, and synthesizing findings) and validation (aiming to reduce design and usability risks by identifying and addressing issues early).

Design inherently contains subjective elements. While we strive to minimize subjectivity through prioritization frameworks, principles of user psychology, and testing methodologies, subjectivity cannot be completely eliminated. Acknowledging this fact significantly aids communication with design teams. Ultimately, the design phase concludes with Communication #2, aimed at gaining stakeholder buy-in for both design and development.

Development

Development, from a Product Manager's perspective, extends beyond drafting PRDs and managing stakeholders. Teams that offload requirements and accountability onto the tech team at this stage risk losing the support of a critical stakeholder. It's vital to exercise caution in four key areas: Pre-work, Resource mapping, Execution management, and Risk management.

• Pre-work involves defining milestones (design, user, business), finalizing tech specifications, and estimating effort requirements.?
• Resource mapping entails identifying necessary resources (note: not hiring) - a task often trickier than anticipated. Identifying dependencies, especially in projects requiring new technology or skills, is a common stumbling block. Ideally, hiring should have been approved in principle during discovery and confirmed during the design phase.
• Execution management encompasses the sprint cycle, stakeholder management, and bottleneck resolution. While building remains the domain of engineers, managing sprints and related cadences should not fall solely to the engineering team. Building strong relationships with engineering is crucial, and good Product teams excel in sprint management. Great Product teams go further, taking initiative to address obstacles faced by engineers and tech leads.
• Risk management involves identifying execution risks (such as scope changes, stakeholder misalignment, and timeline issues) as early as possible and formulating strategies for mitigation. Tactical options for risk management may include adjusting scope, reallocating resources, or extending timelines.

This stage involves Communication #3, intended to align with both primary and secondary stakeholders.

Launch & Learn

Launching is often reduced to a mere checklist, but it deserves a deeper perspective. Launching comprises launch planning, performance monitoring, and post-launch activities.

• Launch planning involves sequencing the launch and maintaining a dynamic list of launch activities. Tech product launches are rarely big bang events, especially when dealing with high uncertainty and significant scope. The sequence of launch (alpha, beta, partial release, full release) should ideally consider variables like uncertainty and impact. Essential launch checklists include technical logs, marketing initiatives, sales enablement, customer support, and more. The key is to maintain a dynamic list updated not only for a specific project but as a repository for all launches, allowing for cumulative learning.
• Performance monitoring is a crucial aspect. Most launches essentially serve as validation exercises, offering opportunities to learn and unlearn. Restricting monitoring to the core KPIs agreed upon during the discovery phase means missing out on opportunities. It's advisable to measure user value (adoption, retention, user satisfaction) and business value (based on defined KPIs). During the initial stages of the launch, adoption holds paramount importance, warranting a broader perspective (awareness of the feature among customers, discoverability, friction points, and the accuracy of the value proposition). Importantly, adoption significantly impacts retention, user satisfaction, and core KPIs.
• Post-launch activities should include Communication #4 (for closing the loop), maintaining ongoing communication with secondary stakeholders, and periodic reviews with primary stakeholders (e.g., retrospectives). Discussion points should focus on the feature's performance and the next steps.

Breaking the Rules

Organizations and teams often deviate from these rules, whether due to constraints, conscious decisions, or business intuition. When rules are bent without adequate communication, friction and frustrations arise. It's important to understand that breaking rules isn't inherently wrong; in fact, it can be powerful and cost-effective under certain circumstances. Common reasons for rule-breaking include:

• Operating under constraints (investment cycles, regulations): When organizations are mandated by regulations to launch a product by a specific date, adherence to these rules becomes imperative. Such constraints can make adhering to conventional product development rules challenging, particularly in heavily regulated industries.
• Learning from competition or when learning is less critical: Not every release requires extensive customer discovery (e.g., conducting one customer interview per day may not always be necessary). Discovery is about comprehending and validating the problem space to improve the odds of success by eliminating bias. If there's already a robust understanding (e.g., a competitor's successful approach, robust data signals, or user logs), or if the product addresses a minor issue, conducting an extensive discovery can be wasteful.
• Top-down organizational demands: This topic deserves a separate discussion. The key is to differentiate between impactful top-down requests and other requests. Top-down requests can be potent, contrary to what is sometimes circulated in the media. Achieving the right balance often involves a combination of soft skills (empathy) and hard skills (product strategy exercises).
• Teams/organizations lacking essential infrastructure (analytics or discovery): While this isn't a valid reason to shortcut the process, many organizations/teams are realizing the value of data (both qualitative and quantitative). Even when tools are suboptimal, entrepreneurial Product Managers often find ways to deliver satisfactory results.
• Product life cycle: We addressed this concept at the beginning of our discussion.

Last but not the least, wish you all the best in your journey :)

Please feel free to share and if you wish, subscribe to:

https://open.substack.com/pub/amartyabiswas/p/starting-the-product-manager-journey?r=4eqm6&utm_campaign=post&utm_medium=web

#ProductManagement

?