Product Management Frameworks 3P: The Art & Science of ‘Product’

This post is part 3 of my 3P: Product Management Framework series. You can find the first post on People here and the post on Process here. This final post is about the Art & Science of the final P, ‘Product’. I’ve captured some of the important aspects of Product here and mainly through the lens of what I’d have appreciated knowing when I started my journey in product back in 2016. There are probably several other ways to slice and dice this subject and go deeper, I’ve picked my homebrewed 3W1H method, to unpack the 3rd P: Product — the What, Why, Who and How.

What are we doing? Why does it matter?

I’ve picked key ‘What’ concepts to highlight here and clarified a few areas that tend to throw teams off.

Vision: ‘Imagine a world where…’ — That’s your vision statement. Your vivid description of a long-term, future state where your product is wildly successful for the users you were targeting in a market or portion of the market that you’ve clearly captured and why it matters. It’s the glorious end state, the big win! Here’s one of my favorite notes, Lyft’s vision over the next 10 years. Although not all the predictions in this fairly long note came true or are likely to come true by 2025, I do love the depth, the data, the ambitious vision and the emotional appeal of the article!

Strategy: ‘That’s great, I love this world. How do I get there?’ What resources should I allocate and when? What should I not allocate resources to?

What is the journey to that vision I aspire to?

How are we leveraging the product’s unique value prop for the identified target users, given the competitive landscape of the product? The answers to these questions come together in the product strategy. This is where we make the hard decisions of what we will do and, more importantly, won’t do.

I’ll take an example I’m familiar with to describe some of the nuances of product strategy. In 2019, I was in charge of incorporating sentiment in ranking to make Facebook News Feed more personal. There are several ways you can go about this. You can gather people’s sentiment in research sessions to understand and improve how people feel about News Feed, you can use human raters to rate content and use that as a basis to improve sentiment, you can try to understand brand sentiment and improve it, you can leverage external panels of experts to understand and improve sentiment, you can use existing engagement ranking signals and figure out which ones are good proxies for sentiment, you can use surveys and ask people questions to understand sentiment and then improve it, the list goes on!

In this scenario, there are so many one-off decisions to make, unless we have a cohesive product strategy for the problem area, we would be shooting in the dark. Based on deep UXR to define various sentiment constructs and data from the initial surveys we ran, we developed a long-term vision and strategy for how we think about sentiment when it comes to ranking. Based on the strategy, we were able to align on a first set of hypotheses and experiments to begin testing our strategy. We narrowed down our experiment to focus on link content on Facebook, targeting users who regularly consume link content on the platform and we decided to run surveys to understand whether people think the link content they see is worth their time. We then incorporated the survey data to predict whether our users would think a particular piece of content was worth their time and thoughtfully scaled the approach. Each decision was backed by clear data or reasoning and hypotheses so we learn irrespective of whether the test moved the metric or not. Note that this was not just one experiment that launched surveys and trained a model but a thoughtful strategy to figure out how we might incorporate sentiment to personalize News Feed better and ways to learn from the initial approach and scale. Having a holistic strategy here helps us understand the various paths and tradeoffs to the long-term vision and we can then pick a path and start learning!

User problems: Whether your company prefers to call these pain points, user journey to identify problems or JTBD, the core idea is the same.

Have you identified an unmet need or problem that a user has and why that’s meaningful to solve? That’s a user problem.

If you are developing a product with the main goal of helping the company make more money, for example, that’s a <company> problem (e.g. Facebook/Meta problem vs User problem). If you have a <company> problem, you can then break it down to uncover user problems that help you solve the <company> problem. The key idea here is to be very clear-eyed about what problem you are solving.

Problem space and Solution space: I’ve sometimes seen teams spin a bit while brainstorming or discussing a user problem because of confusion between the problem space and solution space. There’s a time for each. Problems arise when we think we are brainstorming a problem space to play in and drawing the boundaries, and in the midst of it, start digressing into the solution space and constraints. So, the structured approach here should be:

• Be clear about whether the group is discussing the problem space and define the boundaries of the problem space
• First, go broad and lay out the overall problem space and the specific user problems, then switch to the solution space and draw the boundaries around the solution space, and finally, go deeper into specific solutions.

Who is doing what?

It actually doesn’t matter who is doing what as long as everyone is aligned on the who and the what 🙃. See the sidenote below where I call out how different parts of the product vision and strategy could be developed by different functions; it doesn’t have to be a maverick PM who develops a grand, bold vision generated in her head! What’s important is that the final product vision and plan are developed thoughtfully, and leadership and the team are aligned on the plan. I think of the PM function as the glue that holds the team together and accountable for chugging relentlessly toward the goal. What matters is that you make progress together, not who does what.

✍🏼 A side note on the importance of clear documentation: A canonical document that lays out the vision, strategy, problem space, solution levers, and execution details is pretty important to ensure everyone is rowing in the same direction.

• The product roadmap usually reflects most of these pieces (vision, strategy, etc.)
• Sometimes, a function (like design) may be in charge of laying out a vision for a major product redesign that might then be used as an instrument to align and inspire people toward that vision.
• Sometimes, UX Research might conduct foundational research that clarifies the problem space and where we should play and capture that in a document.
• I’ve seen several ways to effectively craft and leverage these documents. The important principle here is to get these written down in a canonical document that people can access and ensure the team is aligned with the vision and plan.

The How

I’ve covered a good chunk of the How, especially org-specific dynamics, in this post on Process. What I call out below are a set of product-specific suspects that tend to derail the team if not handled thoughtfully.

I. Being in the Weeds

The leaders in the org set the tone for the culture of the org. I’ve worked in organizations where the leaders operate at a much higher level and did not have the bandwidth or preferred not to be in the weeds. I’ve often been the pillar lead ‘in the details’. Caring about the details is important, no matter where you sit in the org. Sometimes, this gets conflated with micro-management or ‘being in the weeds’. Learning the fine balancing art of caring about the details and nuances, while not frustrating your team is something every leader should learn to navigate their own way, through trial and error. Sometimes, the product is of an extremely sensitive nature where the weeds are literally the sauce (definitely need a better metaphor here but you get my point!) and sometimes, the team is kicking ass as they are and we need to gracefully step out of the kitchen until it’s time to check back in again! 👩🏼‍🍳🥘🍳

II. Try and then try again after a while to (maybe) succeed

Over my time at Meta, I often used to hear people push back on a product idea because ‘We tried that and it didn’t work because…’ I’ve sometimes been the wise old product person explaining to someone new why we should steer clear of a particular product idea because it’s been tried before. I then witnessed idea after idea being tried out again by newer folks who didn’t have the history, didn’t know about previous failures, and went on to launch successful products based on the very same idea! Timing matters a lot in product. The takeaway here is to seek out and keep oneself informed of the history and learnings from the past but to not let it constrain you from trying it out again, with the benefit of the learnings from before! While several examples come to mind, a notable product launch that was debated, canned, and then considered and launched successfully at Meta was The Most Recent feed.

III. The one with too many cooks and spoilt broth

The ‘too many cooks’ problem usually manifests when it is not abundantly clear who owns what part of the process and who owns the final decision and the steps leading up to it. A typical example is when teams spin on a complicated product decision unable to align while not recognizing that the ultimate decision maker is the VP of the org. All the team is responsible for is to deeply investigate the problem, come up with options for solutions, lay out pros and cons for each option and present the recommended option to leadership for the final decision. Clarifying who the decision maker is and what the team’s role is earlier on in the process keeps egos at bay and keeps the discussion productive and forward-moving. For extremely complex projects, a more formal process such as a RACI matrix or a People & Process approach may be needed.

Reopening a can of worms and when it’s worth it

A complicated facet of product is figuring out when it makes sense to go back and reopen a can of worms! A typical pattern I’ve observed is when the definition of a ‘thing’ is not clear or not aligned upon explicitly, but the team has already begun to execute on a solution. For example, consider a really complex problem area such as figuring out how to rank political content on the Facebook platform. If the definition of what political content is is not clear or the team and leadership is not aligned on the definition, there will be a lot of lower-level ‘execution issues’ with the product. A PM’s instinct might be to plow through and push on the execution to move fast but sometimes, it might save us a lot of time and effort if we take a step back, reopen the scary can of worms and ask how we are defining aspects of the problem. The flip side to this argument is sometimes, to avoid continuously spinning on a problem, a PM needs to be firm and clarify that the phase where we question definitions and clarify the problem space has already been completed and it’s now time to disagree and commit. So, when do you reopen the mucky can of worms and when do you firmly keep it closed? That’s equal parts art and science!

What is not measured cannot be improved. Sometimes what is measured cannot be improved

Silicon Valley big tech is famous for its metric-focused culture. Often, being able to measure something or even proxies to the actual metric is hugely beneficial to track progress and establish a culture where data helps inform product decisions rather than subjective opinions and based on the HiPPO effect. Being data-driven is a great best practice. However, if this approach is taken to too much of an extreme, it has the unintentional consequence of thwarting innovative product ideas. In my experience, I’ve seen the data-driven approach be super effective when you are making incremental improvements to product and when there are established, time-tested metrics to measure progress.

When dealing with new products, expecting to see the same set of movements in already established metrics can be detrimental. For new product innovations (say when the Facebook app launched Marketplace tab or when Dating was introduced), expecting to see the same app top line metrics move at the same rate is not realistic and we may end up killing an otherwise valuable product. One way to preserve innovation could be to negotiate a longer runway to show topline metric impact for the new product area or to show proxy metrics that indicate the product is moving metrics in the right direction and eventually the magnitude will follow.

The Goldilocks principle of looping in XFN

Diverse teams where the opinions and expertise of subject matter experts and cross-functional partners (UXR, DS, Content, Design, Legal, Policy, Privacy, PMM…) is included always lead to better products for users.

There is a right way to loop in cross-functional (XFN) partners in the process. I’ve seen this fail in two common ways. One is when everyone is in the room all the time, weighing in with opinions and the product seems to move at a weighted, slow pace. This happens when the PM is not doing a great job of looping in the right partners at the right time. Looping in your half a dozen IC designers to weigh in on detailed product UX mocks when the basic idea is not validated or has directional approval from leadership is an example of ‘too early’. Looping in your XFN partners after the product feature has been halfway defined (with just the PM and the engineer in the room) and then asking XFN partners to fill in the details is an example of looping in your XFN partners ‘too late’. Another example of ‘too late’ is asking your legal team for last-minute risks and mitigations for a product that has been completely defined and engineering is halfway through execution!

As with all the other product issues I discuss in this note, a thoughtful PM who has established a solid rapport with her team and XFN partners will intuitively know the Goldilocks rule of looping in XFN. As with all other things in product, it might seem natural and easy but has been carefully learned and crafted over years of trial and error and hard work!

This concludes my 3 posts on the 3Ps of Product Management: People, Process & Product. I hope you enjoyed it and let me know if you have other ideas to add to the mix!