I once worked on a Marketing team where I constantly resolved disagreements with Sales. Each week, I helped decide which sales channels would get promotional discounts. I negotiated against one team that mostly wanted one thing: discounts. The work was one-dimensional.

I’ve since changed careers to product management. It requires collaborating across multiple teams to build software products. The work is high-dimensional. 

Previously, I’ve written about the product management process as an individual contributor, but this post reflects my experience when products get more complex and start pushing up against an organization's constraints.. 

I find it helps to view each team as a tree within the broader forest of product management. Teams need to cooperate on what to build (product vision), what to measure, and how to build.   

Product Vision 

Ask ten employees for their objectives and you'll likely get ten different answers. Aligning vision can be challenging.

Companies are always trying to improve cross-division alignment. In the 1930s, Proctor and Gamble (P&G) invented brand management, where each product team (soap, foods, etc.) had their own team to build and market the brands. 

The issue with this structure was there were redundant roles across each product line. In response, companies adopted a matrix structure where functional groups (Sales, Finance, R&D, etc.) supported multiple products at once. 

However, teams still clashed because functional teams optimize on how they’re measured. Finance has cost targets. Salespeople have sales targets. Manufacturing has quality targets. 

Product teams focus on the bigger picture. Where is the market going? What are customers struggling with? Then, they build the business case, the story, and work with functional teams to get feedback and buy-in. 

Product Measurement

Product metrics are business health indicators. They're a snapshot of what to optimize so that eventually revenue increases or costs decrease. It requires acknowledging a functional team's metrics (objectives), while still measuring the broader customer lifecycle.

Use more than one metric

Total count metrics are easier to start with since that type of data is readily available. Metrics like active users or page views signal a product’s usage, but don’t capture everything. 

Optimizing only one metric may lead to a short-term improvement but could negatively impact others. For example, increasing user notifications to log in might increase user engagement. Then, it normalizes as users turn them off because they’re not relevant, opt-out of emails, or stop using the product entirely.

That’s why a collection of metrics - session length, customer support volume, churn, or NPS - provide a more holistic view of the customer. 

Metrics must be within a team’s influence

Teams must believe that they have the levers to impact the metric to feel ownership. That means having the tools, resources, and management support. 

They’re also hesitant to commit to a metric if they’re dependent on other divisions. Building cross-division collaboration begins with open conversations in balancing both group’s priorities. Regular check-ins between teams strengthens trust and the ability to work towards shared metrics.

Adapt metrics as required 

The environment is always changing: re-organizations, new priorities, new competitors, or new datasets become available. It’s always better to start somewhere. 

Over time, metrics can be refined to measure what you’re trying to optimize. Introducing data distribution (max/min, median, percentiles) or time intervals (7, 30 days, etc.) can provide a broader view of customer behaviour. 

Product Execution

Effective execution involves integrating teams, company processes, and technologies, to create a successful product. 

Team Dynamics

Team dynamics evolve through four stages: Forming - initial team interactions, Storming - testing boundaries, Norming - establishing culture, and Performing -  high functionality.

It’s important to note that teams can get stuck or fall back to earlier stages. 

Product leaders can guide teams through each stage by publicly praising positive behaviours and privately discouraging negative ones. Teams are high-performing once members understand expectations of their role and work towards meeting those high standards. 

Company Processes

Processes within a company vary widely, from heavily structured to non-existent. 

Heavily structured environments are where each step is strictly followed, which slows down execution. Product managers can support by providing the customer context to these teams, and explaining why certain steps don’t apply. Removing steps keeps execution moving.

In environments where the process is non-existing, tasks are new and undefined. The best approach is to focus on quickly completing the next known step. There’s little benefit in planning too far ahead since all future steps are unknown.

Technology Choices

Selecting the right technology is not always about picking the market leader. It’s important to weigh the benefits of a technology against internal factors such as the team's skills, company processes, existing technology stack, time constraints, and maintainability.

Ultimately, a guiding principle in product management is to always be shipping. Ship a feature, interact with your users, get feedback, and then ship again. Select technologies that enable shipping. 

Summary

Product management is like navigating a dynamic forest, requiring an understanding of both functional teams and customers. This holistic view, combined with organizational vision, metric-driven management, and understanding team dynamics, reflects the art of product management.