Defining Product Operations: Lessons from Maslow
9 min read
Long time, no blog but I couldn’t resist. The buzz around Product Ops is undeniable, particularly with the forward-looking insights from Marty’s 2024 Predictions and the comprehensive views in Melissa & Denise’s book ‘Product Operations.’
Melissa & Denise encapsulate Product Ops as
“the art of removing obstacles from evidence-based decision making,”
A goal that requires a structured approach to achieve — and one that resonated with Marty. Unrelated, in a recent podcast recording with Ariana Cofone [Secret Ops coming 2024!], I delved into my personal ethos and its significance in navigating challenges. I find that when things aren’t aligning for me, it’s often a reflection of my values being directly challenged. This has served me greatly in the diagnosis of a problem and its corresponding solution options.
In an attempt to blend two concepts to create something actionable, I’ve developed an analogy:
To highlight that Product Ops isn’t as rigidly defined as Marty, Melissa, Denise and others are attempting to suggest, even when there’s agreement on the ultimate goal.
To offer a perspective for others to examine their organizations, identifying where needs are being challenged and contemplating solutions.
This analogy leverages Maslow’s hierarchy of needs. While it may initially seem that an organization can only exist within one layer of the pyramid at a time, it’s more realistic to view these layers as concurrent. It’s a bit of a stretch applying Maslow’s model to Product Ops, but I believe it provides a unique lens through which we can understand and address the complexities of this field.
Understanding the Operations of a Product, Engineering and Design Teams [R&D] through Maslow’s Hierarchy
Bottom of Pyramid, Physiological Needs
Ops Translation: Basic Infrastructure
The foundation encompasses the essential infrastructure necessary for product development. This involves observing (not yet addressing) challenges like: how do we articulate value for our customers and partners? Where are we prevented from feeling safe while trying to take a product-led approach? How do we define success criteria for products? Comprehending the operating model? As in Maslow’s hierarchy, where physiological needs are vital for survival, this layer is indispensable for effectively deciding how to get to the top of the pyramid.
Safety Needs
Ops Translation: Stewardship and Systematic Frameworks
This layer in Product Ops focuses on stewardship and systematic frameworks. This is not “Governance and Process” although I have used those words before. The main challenge is moving beyond mere control to a commitment to guiding towards strategic outcomes. Adopting structured, scientific-method-like approaches, operations too can be experimental: methodical and pivot-based, focusing on what drives outcomes. The team can see value and want to take it and run. This stage starts to set the ground work in establishing stability and consistency in operations, similar to how safety needs provide a secure and stable environment in Maslow’s hierarchy.
Love and Belonging
Ops Translation: Team Alignment and Collaboration
Corresponding to Maslow’s need for love and belonging, this stage is about fostering team alignment and collaboration. Value is still a main driver but now we are safe to let go of practices that no longer serve their goals now that we have means to serve those goals that fit our team needs. This layer is crucial for creating a collaborative environment where team members feel connected and committed to the product’s success. We are getting good.
Esteem Needs
Ops Translation: Measurable Success and Recognition
Reflecting Maslow’s esteem needs, this layer focuses on measuring success and acknowledging achievements. It’s about setting clear expectations and celebrating the team’s efforts in meeting these targets. The R&D team faces the challenge of effectively managing expectations and holding each accountable, while fostering an environment where recognition and respect are integral. We are good, together.
Top of Pyramid, Self-Actualization
Ops Translation: Enlightened Decision Making
At the pinnacle, similar to Maslow’s self-actualization, is the goal of Ops to master “the art of removing obstacles from evidence-based decision making.” This stage represents the convergence of all previous layers, empowering data-driven decision-making free from operational and ‘ego driven’ barriers. The organization to make well-informed, effective decisions that drive product success. We are great.
To be fair, I have become somewhat of a specialist at starting at the lowest layer to get to our desired end state. I have been building product ops at companies that maybe would be interpreted as “early” given many of the examples across Melissa’s book. Perhaps it’s an antipattern, and I’d be happy to have that discussion, but I do think there is value in thinking about ‘what the team needs to reach self actualization’ over ‘what product ops is and isn’t’.
Examining Your Organization through the Maslow Analogy
Now for part 2, a way to examine your organizations. Think concurrent, not one step at a time. While I would like to be more insightful with examples, I am afraid I would be calling things out too specifically where folks could infer things from my experience, so I will avoid putting folks on blast.
Bottom of Pyramid, Physiological Needs
Ops Translation: Basic Infrastructure
This foundational layer is about building the necessary infrastructure for product development. Let’s explore the challenges and potential actions at this base level.
Things you may observe when this need is challenged:
Go-To-Market (GTM) partners or critical teams like Marketing have divergent views on the product direction.
A noticeable disconnect in understanding the customer among the product team members.
Confusion or lack of consensus on defining product success criteria.
Difficulty in comprehending or agreeing on the operating model, leading to inconsistent approaches in product development.
Potential Actions to Consider:
Document the operating model as it stands today and identify key ares that could use some support.
Ask “what is our product strategy” across a sample size of the company and note the discrepancies to review with the R&D leadership team. (this is pulled from Melissa Perri’s Escape the Build Trap”
Avoid: making assumptions to quickly, over indexing on leaderships perspectives
Safety Needs
Ops Translation: Stewardship and Systematic Frameworks
Moving up, we focus on establishing stewardship and systematic frameworks. This is crucial for creating a stable and secure operating environment.
Things you may observe when this need is challenged:
Overlapping or redundant communication channels leading to information silos or missing critical stakeholders.
Lack of ownership or clear responsibility, with teams expecting others to undertake key activities like discovery, market research, or customer interviews.
Challenges in adopting a structured approach, leading to ad-hoc and reactive operations rather than strategic, outcome-driven processes. Ex. Inconsistent terminology being used across teams to describe ‘release’ or ‘launch’ phases causing confusion with key partners.
Potential Actions to Consider:
Work with leadership and peers to tease out the target operating model to reach “self actualization”. Defining how roles show up in the ideal state, the desired engagement, then evangelize the ideal state with key stakeholders.
Zoom in to where the are gaps between current operating model and the target to prioritize efforts.
Avoid: slapping a framework that you read works, reusing an approach from as previous company, diving into to processes and setting RACIs
Love and Belonging
Ops Translation: Team Alignment and Collaboration
Corresponding to the human need for connection, this stage emphasizes aligning the team and enhancing collaboration.
Things you may observe when this need is challenged:
Teams operating in silos, with little to no cross-functional collaboration. Decisions made in 1:1s. All decisions escalated to the executive team.
Resistance to change or letting go of outdated practices, even when they no longer serve the team’s goals.
Low morale or lack of motivation among team members, reflecting a disconnect with the product’s vision or objectives. Apathetic behaviors.
Communication breakdowns or misunderstandings, hindering effective teamwork and collaboration.
Potential Actions to Consider:
Prioritize small team building activities that allow folks to understand their colleagues as people. Even if you don’t believe in personality tests, they are effective for this purpose.
Observe and address change management challenges with grace and patience.
Remove communication barriers and redundancies by slow rolling out an operating cadence as guided by your operations model.
Encourage open communication and provide platforms for team members to voice concerns and suggestions.
Avoid: getting too personal in public forums for the sake of our introverts, controlling all communication taking away from team autonomy, stretching yourself too thin by thinking your value is only driven by morale of others
Esteem Needs
Measurable Success and Recognition
Here, the focus shifts to measuring success and recognizing achievements, fostering a culture of respect and motivation.
Things you may observe when this need is challenged:
Difficulty in setting or agreeing upon realistic and clear expectations for success.
Lack of recognition or appreciation for team efforts, leading to decreased motivation and engagement.
Challenges in effectively measuring success, resulting in ambiguity about progress and achievements.
Accountability issues, with team members not holding each other responsible for their contributions.
Potential Actions to Consider:
Recognize and celebrate team achievements, both big and small, to boost morale and motivation in public forums.
Coach toward effective KPIs and metrics to measure success, ensuring these are aligned with overall business objectives.
Establish a culture of accountability, where team members feel responsible for and proud of their contributions (easier said than done, there is alot here)
Act as a partner to your peers especially if on the leadership team, your understanding of the broader organization can allow them to elevate themselves to ‘empowers’ over ‘controllers’
Avoid: being ruinously empathetic and afraid to call anyone out for detracting from the target operating model and broader vision, not reflecting on changes you’ve made — operations is always never ending and if things no longer serve the outcome, set an example by burning it to the ground
Top of Pyramid, Self-Actualization
Ops Translation: Enlightened Decision Making
At the pinnacle, we aim for enlightened decision-making, embodying the convergence of all previous layers.
Things you may observe when this need is challenged:
Decision-making processes that are not data-driven, leading to suboptimal choices.
Persistence of operational and ego-driven barriers, impeding the flow of unbiased information and insights.
Teams struggling to converge on decisions, indicating a lack of empowerment or insufficient knowledge.
A noticeable gap between the potential and actual performance hindering the organization’s ability to make effective, informed decisions.
Potential Actions to Consider:
Cultivate a data-driven culture, providing training and resources to ensure decisions are based on solid data and analysis.
Identify and address operational and personal barriers through open discussions, feedback, and leadership support.
Empower teams by delegating decision-making authority (and encouraging leaders too) while providing the necessary transparency for all to trust in the autonomy.
Avoid: forgetting you serve people, not just the business. So much pride and ego that you fear starting all over again.
From building a robust foundation to reaching the heights of enlightened decision-making, each layer presents unique challenges and opportunities for growth. Addressing each need requires specific actions and a keen understanding of the dynamics within a product team.
Reflect on your own experiences: Where does your team currently stand within this hierarchy? What steps can you take to address the challenges at your current level and ascend to the next? By continually assessing and adapting, you can guide your team towards greater effectiveness and success in the ever-evolving world of Product Ops.
As an aside, in his article, Marty makes an interesting observation:
“While the art of removing obstacles from evidence-based decision-making is not novel (product teams have been supported by user research and data analyst teams in qualitative and quantitative decision-making for over two decades), consolidating these capabilities under a unified ‘product ops’ leader can enhance the visibility of this crucial function.”
I concur with this perspective, yet my experience with some Product Growth teams, structured similarly, leads me to ponder an integrated future or a decline in one or the other. The said, who really cares if the value is present in the organization?
There are, undoubtedly, cultural motivations — or at least there should be — behind the structural strategies that companies adopt, nuances that might elude external understanding. Debating it without context is fruitless. Make decisions with intention, not just because someone said something was right. I think Marty would agree there.
Perhaps I am the very person to be skeptical of, but until I witness a concerted effort to elevate the entire R&D organization, as laid out by my analogy with the hierarchy of needs, I will continue to uphold the significance of our value, independent of the specific terminology employed.
Side Note: Marty will have a book release in March ‘TRANSFORMED: Moving To The Product Operating Model’ as I look to see how far or similar our perspectives are. I have spoken and written about Operating Models after conducting my research and application over the last few years and I strongly belief intentions (principles) drive product outcomes, not processes. My post on Crafting a Target Operating Model, video on What is a Target Operating Model? (more tactical than I will ever be again as it’s doesn’t consider enough nuance for me now).