Can Product Operations learn from the diabolical beetle?
What do diabolical beetles have to do with the evolution of product operations in tech companies today? Good question.
Before I get to answer that, let me offer that it’s not just nature’s creativity, efficiency, and first-principles approach to avoiding an early demise (without procreating) that lends us, mere mortals, ample lessons in our business dealings. If we combine another discipline, human psychology and behavior, into this model for thinking about how to improve our product operations, we better position ourselves, our teams, and our companies for Making A Whole Lotta Awesome happen.
There are going to be a few twists and turns in this post, but I promise it won’t take the same amount of time it took for the diabolical beetle to go from an easily crushed flying beetle to one that can be run over by a car and still walk away to fight (mate?) another day.
For those who like the TL;DR version of things, I don’t have one. So this is where I bid you adieu. For those who appreciate a table of contents, you’ll see that below. Feel free to bop around at will.
I. Setting the Context
II. Peering through the Lens of…
* Ecology and Biology — the OG experimenter
* Materials science — the diabolical beetle
* Systems-Thinking
* Psychology — tricks of the mind
III. Product Operations: Why now?
Setting the Context
The topic of “what is product operations?” has been brewing in my mind for a few years.
As a trained research biologist, I came to software product development with some practices well ingrained in my DNA. Some of the most valuable, when I began working in software product management, was systems-thinking, thesis building, experimentation, data-analysis, and an unquenchable, insatiable curiosity.
Before I could drip all that goodness into product management, and start connecting the dots in this new field called “product operations”, I went back to school for applied industrial and org psychology. This was fun since I still got paid to be super curious, apply rigor and discipline around experimentation and learning, and ultimately, understand better why people did what they did. In that field, I was learning not just about the first principles underlying human decision-making, the biases, and mental models behind why changing behaviors are so hard, but in my first startup, I was bringing it all together, to build and sell new types of software products to help fortune 500 customers solve some thorny problems in new ways.
These two disciplines prepared me well for what I was going to do in product management, but even more so, what started to show up in my work as I grew in the field.
I started seeing the larger, messier, Murphy’s-Law-ecosystem in which product, as a discipline, happened. I started noticing what product managers and even leaders in product management were doing on the job, and it didn’t look like product management. The ecosystem that is The Business, and all the moving parts and levers that exist within it, were where I started taking advantage of my unique sweet-spot combo of skills, and it's where I began seeing the evolution of this relatively new role of product operations.
Curious about how my colleagues and friends over in BizOps, DevOps and Sales/RevenueOps have navigated these waters, I’ve started bugging them in order to learn what insights they could share with me, and how Product might apply some of those learnings for the product function’s benefit. I’m still peering over the sides on that one.
This post is meant to be a place where my thinking on this evolution is more formally drafted. I’ll show how and where I see the influence of other disciplines and mental models that can be used to support this new function’s success. Finally, I outline why I think this evolution is happening now.
I hope that this post also encourages you to share your insights, comments, and feedback. Please don’t hold back!
Peering through the lens of…
Biology — the OG Experimenter.
“The art of biology is to find the simplest model for the phenomena one wants to understand…and to conduct carefully controlled experiments that manipulate one variable at a time.” — Sean B. Carroll, The Serengeti Rules
The collision of scientific methodology, psychology, behavioral economics and product development has been significantly influencing the product management discipline. There is plenty of content to learn more about the not-so-good that has come from this influence (here, and here). But when the good stuff happens, it’s really good; like encouraging people to save more when they are naturally inclined not to (here, here and here) and helping humans develop a more calm mind and body or creating tools to make recruitment of engineers and designers less biased and more user-friendly (especially in remote interviews). There are lots of ways we are doing good.
Borrowing heavily from biology and research here, I’ve often viewed processes, or the Inputs, as products themselves. When applying that outlook to product operations, I’m curious about their relevance and applicability to the roles people occupy NOW, in the real world.
My questions specifically:
1. Using the scientific method as a model for drafting hypothesis and measurements in product ops. For example, where have Product Operations leaders set up hypotheses and success measures/metrics for specific operations and processes? Has it been successful? Do product teams use hypothesis as focused as this: “We expect that <object of change> will change <magnitude of change> by <this time frame> for <# of people> with the installation of (or integration of, or creation of….) <the new change>.”?
Using the scientific method strongly encourages another important by-product; ruthless prioritization. When product teams/leads partner with engineering and design, at customer discovery and development stages especially, using this methodology forces focus and discipline on exactly what the PM thinks the outcome will be, inviting thoughtful debate and dialogue on probabilities, confidence levels, assumptions and second-order effects.
2. Can or do ProdOps leaders build experimentation cultures, even as the ProdOps person is / may be striving for scale and efficiency? This tends to invite and nurture employees with a calculated, but higher risk tolerance, and the ability to recognize and handle failures when they happen. Importantly, the failures are not business-ending ones. Importantly, does Product Ops build and nurture this by creating absolute clarity about expectations for product management: i.e. actively documenting decisions, assumptions, and risks (feasibility, value, viability, and usability), so failures are company-wide learnings and insights that inform new experiments (or kill the original).
3. How and where does the Product Ops leader set a focus and clarity on velocity (vs speed)? And how does that show up and affect the rest of the organization’s processes? Since velocity is the speed in a specific direction, and speed just denotes how fast you are moving (generally with no direction), how do Product Operations leaders set the framework for how product puts this mindset into practice— consistently and cross-functionally — so the impact is felt measurably on all the different customers a company may serve?
There’s a lot more to this line of thinking and line of questioning. I’m interested in learning what the reader has experienced here to learn more about it and how it applies to their Product Operations in their org.
In my experience, the execution of this mindset or outlook has shown up in creating and running product management by thematic or outcome focused roadmaps that links people across functions, onboarding (in the hiring process), distribution channel development and nurturing (where a customer segment was a distribution network), and customer community building, to name a few.
Materials Science
Back to the diabolical beetle.
In the image above, you are peering at a cross-sectional view of the fused wings, or exoskeleton, of this insanely cool beetle. That red arrow is pointing to the suture that is essentially the mid-line where those two ‘wings’ used to separate, but do no longer. If you look closely, you can see the suture resembles a jigsaw puzzle. This is no accident. Trying to pull one piece from inside another — like when a 30,000 lb car rolls over the top of this beetle’s body, or when an unsuspecting insect hobbyist tries to push a pin through the beetle’s exoskeleton and learns a drill is the only such tool for the job — is no easy feat. (Admittedly, these are both human-driven examples, so one has to believe that the diabolical beetle’s real predators must have some serious jaws/claws).
As you can see in this video, the beauty of this design is that it GIVES, or flexes, under that pressure. Like the newer architectural demands on California buildings, that must sway with the violent tantrums of the earth’s innards, the diabolical beetle’s exoskeleton is constructed in such a way to help it resist immediate splintering with great pressure, (aka: death), and instead spread that pressure load out just enough that it gifts the little insect another day.
Product Operations leaders do a huge service to the organization as a whole, but especially to the product management group and its close partners in data, engineering and design, when they create structures and processes that have enough flex and resilience in them that they give under intense pressure, but don’t crack.
Of course, multiple biochemical, physical and evolutionary processes have worked together to make this beetle’s super-powered-exoskeletal strength possible. This ‘cross functionality’ is nature’s own trial-and-error approach to building, testing, and learning its way to building the fittest organism, and product ops can take a lesson from this as well. The velocity that cross-functional teams and/or leaders can enter into, for generating and sustaining such a loop-of-learning, I believe is one leading indicator of success as a team, and an organization.
With that process, there are hundreds of different feedback loops and inputs, with measures built in, that inform the system’s efforts on its level of success. Let’s get to that now.
Systems Thinking
“Just as for the specific rules governing cholesterol and cell growth, there are two good ways to discover the rules that regulate animal populations: find systems where the rules can be broken experimentally and see what happens, or find situations where the system is broken and decipher why.” — Sean B. Carroll
Scientists love to discover the answer to “How” questions, but it is almost worthless to know that part of the riddle without knowing “Why”. It’s also relatively easier to ideate and test for the “How” than the Why. Ideating and solutioning for a specific problem like how to regulate a growing population of bear, sea stars, or under-performing employees, but not identifying the “Why” that problem exists will be like practicing the proverbial throwing money bad. This is where systems-thinking comes into play.
The systems-thinking mindset is another incredibly valuable feature of people who operate in product, in general. When extended to Product Operations, it’s critical.
People’s behaviors and decisions in business are regulated similarly to those in wild ecosystems. And a key feature in those ecosystems (and our businesses) are feedback loops.
“…systems thinking recognizes the complexity of the relationship between structure and behavior, what makes them produce poor results, and aids people in then thinking how to shift them into better behavior patterns” (Donella Meadows, Thinking in Systems).
The feedback loops in a systems-thinking approach are helpful models for locating the structures in systems that unveil where the most impactful levers exist. These loops are either Reinforcing or they are Balancing and they are constantly at play — whether you knowingly or unknowingly are acting on them. These can be subtle like a manager proposing team meetings at a bar that then alienates and misses the input of members who can’t attend due to personal or familial obligations, or they can be clear and pronounced, like incentivization models (quotas for sales professionals). These loops may have relationships with other loops in the system and it’s there where a product operations person with this skill earns her pay.
The example below is a Balancing feedback loop. If, on an unreasonably cold day, you set your house’s thermometer to 65 degrees, and it’s already 50 degrees F in the house, then that gap of 15 degrees is the kick in the pants that gets the loop going. Meaning, your heater kicks on until it reaches the 65 degrees F. Once it does, it kicks off. This same Balancing loop exists in your own body and it’s the reason you are holding steady, most of the time, around 96.5 degrees.
Reinforcing loops are more vicious, if you want to call a loop vicious. They amplify a certain action (positive or negative). Market movement (Wall St) are examples of this kind of loop. When the Tesla share price more than doubled from about $241 in July ’20 to almost $500 in August, the reinforcing loop looked something like this (where “R” = reinforcing):
Everyone’s favorite systems-thinking example is Amazon’s flywheel for growth: a mix of both balancing and reinforcing loops.
Greater and greater selection drives a BETTER customer experience (more optionality), which drives MORE customers to the site, which drives MORE sellers to Amazon, which both RAISES the selection and LOWERS Amazon’s cost structure, which then… and you get the idea. Both reinforcing and balancing loops working at full throttle in the right places.
In John Rossman’s book, Think like Amazon, he walks the reader through 50 1/2 ideas to show, more specifically, how Amazon uses this systems-based thinking in their strategy and execution. In case the reader should miss the not-so-subtle reference to the importance of this strategy and how it shows up in Amazon’s daily operations (and all the chapters), he highlights it with an entire chapter called: Systems thinking in Strategy Development.
Product Operations, by the very word, implies a Systems-thinking approach is at play. In the words of Russell Ackoff:
“Managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other. I call such situations messes… Managers do not solve problems, they manage messes.”
You may not agree with the latter part of this quote, and that's fine. But if you’ve been a manager for any length of time, you’ve experienced this dynamism and seen this on the regular. When it comes to product operations, like nature, there is a non-trivial number of loops, dependencies, assumptions, and nodes in the system that can and do fail, that encourage and/or regulate a certain behavior, and require constant care, monitoring, and rejiggering. These loops cross multiple organizational functions and processes (incentivization models and communications being two of the most critical). Anyone underestimating the magnitude of this person’s responsibility in this regard does so at their company, team, and job’s peril.
One of the trickiest parts of using this approach is understanding how behaviors of the system (and, of course, the humans driving that system’s success) can scale or not. Entropy is around every corner, and nature’s inclination is to take the path to continued entropy (note: entropy can be good too). Since behaviors tend to change as you scale them up or down, it’s crucial that this be actively considered when monitoring, designing, or refactoring, the system’s parts as a company grows. In Product Operations, in health care/tech, this is especially challenging as the layers of customers are complex and all demand close attention in product development; externally (Payers, patients, health care professionals) and internally (clinical operations staff).
Which, segues me into the next piece… psychology and the drivers of human behavior.
Psychology — Mind tricks
Remember the time you listed that piece of furniture on craigslist for $125 bucks? It took you 3 hours to put together, which was about 2 hours longer than you expected (Does IKEA ever give you all the pieces you need for your DIY furniture adventure?). You couldn’t sell it for weeks. People were offering you half of what you wanted, and they clearly did not understand how much work they were NOT going to have to do to set it up in their own home. I mean, sheesh. Nobody understands or appreciate your hard work!
That mind-trick is called the IKEA effect (Yep, IKEA has been gifted the extension of its branding into the world of psychology), and loosely coupled with Loss Aversion, represent two biases where we think our ‘thing’ is more valuable because of all the hard work we put into it, effectively debilitating us from just getting over it already. Moving on. Calling it quits. Throwing in the towel. In essence, these biases govern our behaviors and they happen so deep in our subconscious we barely know they are having an effect. And that is critically important for a product operations leader to be aware of and plan for.(For more on this, read anything by Nobel Laureates Daniel Kahneman and Richard Thaler, or Amos Tversky. Also, Shane Perrish discusses mental models that help us deal around these biases, at FarnamStreet — it’s excellent as well).
The circular diagram above outlines many of the different biases that play a role in our decision-making and behaviors. These have taken more center stage in our awareness over the last decade or more, with some being more familiar than others. Gender, nationality and ethnic biases insert themselves in our recruitment, interviewing and hiring practices. They show up in our facial recognition, criminal “detection”, and recommendation algorithms. Biases like the IKEA effect and loss aversion are the downfall of products and features that deserve to die but continue sucking the financial and cerebral resources out of our companies and people who need to maintain them.
Importantly, because product operations is inherently about “operating”, or how people execute processes, make decisions, drive or resist change, and generally behave, understanding psychology and the mental models therein should be a skill product operations professionals have practiced in both product or product AND other functional areas (change management, organization development, or learning and development cross-over well here).
Product Operations: Why now?
Listening to webinars, reading articles on this, and talking with operators in different functions has formed my opinion on why the product operations role is evolving as it is. A few of my guesses are below:
- Continued growth in software product development is causing a continued need for product managers. Problem: Many people are more project manager than product manager. (Marty Cagan and Des Treynor have written and talked about this extensively, and so I’ll refer to their excellent content here and here to get you started.) The result is a significantly different perspective in how one thinks about product management, and in their execution of product management.
- All partners or stakeholders, who are recipients of the product team’s work, are increasingly uncertain about how they can work more effectively together — for the business. Problem: finance, sales, engineering, customer support, customer success, and marketing — they all need to partner with Product to learn how the function is impacting that area of the business and their planning. One example: The sheer volume of software tools available to product managers, for guiding every facet of the product and its lifecycle, has ballooned over the last decade. There are many hundreds of tools to choose from for roadmapping, prototyping, task management, customer feedback, data/analytics, prioritization, user research and more. They all require not just the product manager’s skill in using and deriving insights from them, but a cross-functional team member’s diligent use and the business’s use for strategic and operational planning. That’s a ton of moving parts for which product management may not be able to handle, effectively derive meaningful insights from, and then share with internal customers for decision-making.
- Where product ops is located in the org chart is influenced based on where any uncertainty or chaos is most deeply affecting the business (customer loss or growth? revenues? operations’ efficiencies?). Problem: Where product operations appears in the org chart seems to be less about what it ‘should be’, and more about whose pain it’s solving at the moment. From an evolutionary standpoint, this is a natural trial-and-error approach, and one I’m a fan of. Getting to the right spot takes lots of learning, and that’s where I believe many operators are acting as pioneers and experimenters. As such, depending on which organization you are talking with, you might find product operations in product org, the operations function, or the project management function. If it’s appeared elsewhere, please comment below and tell me more about this!!
- The function could also be perceived as an enforcing or regulatory body. Problem: This is one I have a philosophical difference with, as I believe it removes the collective agency and accountability for others in the company to autonomously make smarter decisions on behalf of the customer and the business. I think an ambitious and accountable organization of people do and can thrive with clear governing principles, operating behavior expectations, ways of thinking, and appropriately matched incentivization models to that end. (Cue up the obvious: Netflix, Amazon, Tesla, Apple where their cultures have very polarizing feelings in people — a sure sign of governing principles, performance expectations and incentivization models that are crystal clear in their frequent messaging)
Product management is a messy, chaotic, and difficult discipline. Just in tool-use alone, the ease with which teams and individuals can acquire them increases the volume of data that gets siloed to one person or function, disrupting how the company as a whole accurately learns and iterates on product development.
Intensifying this state is the speed at which technology can be created and shipped. In Clay Christenson’s seminal book, The Innovator’s Dilemma, he makes the case throughout the book that “the pace of technological progress in products frequently exceeds the rate of performance improvement that mainstream customers demand or can absorb. As a consequence, products whose features and functionality closely match market needs today often follow a trajectory of improvement by which they overshoot mainstream market needs tomorrow.”
Christensen outlines five principles that he deems as “so strong that managers who ignore or fight them are nearly powerless to pilot their companies through a disruptive technology storm.” I believe these principles are ones that the Product Operations role is ready and distinctly well suited to own and steward. The people in this role are part change agent, part business operations owner, and part product steward.
(The following Principles are directly from The Innovator’s Dilemma and the implications are edited for brevity. *The author discusses at length what managers can do to be successful, even under the constraints of these ‘laws’, in order to create innovative, disruptive solutions)
#1: Managers may think they control the flow of resources, but it’s really customers and investors who dictate how the money will be spent.
Implication: Lower margin opportunities — like ideas that may be generated without customer input — don’t get company resources. By the time customers ask for them, it’s too late.
#2: Small Markets don’t solve the growth needs of large companies.
Implication: Losing market potential in a new category or for a new customer segment that doesn’t meet a company requirement for revenue potential. Ex: A $40 mil company needs to find just $8 mil in revenues to grow at 20%. But a $4 bil company needs to find $800 mil in new sales.
#3: Markets that don’t exist can’t be analyzed.
Implication: “The only thing managers that we know for sure when we read experts’ forecasts about how large emerging market will become is that they are wrong.”
#4: An organization’s capabilities define its disabilities.
Implication: The two most inflexible things to change in a company are its processes and its values. “People are quite flexible, in that they can be trained to succeed at quite different things. But processes and values are not flexible.”
#5: Technology supply may not equal market demand.
Implication: “The pace of technological progress in product frequently exceeds the rate of performance improvement that mainstream customers demand or can absorb.”
Again, I believe, these principles are ones that the Product Operations role is ready and distinctly well suited to own.
I’ve seen more midlevel (Director) and executive-level product operations roles growing up in small or mid-size companies more frequently lately, and I expect this pattern to continue. Given the principles Clay Christensen outlines, this is to be expected in pioneering (and by, default, smaller) organizations. As the role matures, I wonder if it will become more prominent in a larger enterprise where the sustainability of the status quo is the primary value and goal. Curiously, if the mandate of the role is to build and create a function that enables nimble, strategic and innovative product teams, it seems that role may NOT be ideally suited for larger organizations looking to maintain that status quo.
I’m curious to see how the “operations” part of the role will end up playing out, primarily due to the wide variability in where it is sitting now in the org chart now, and the equally wide variability in its responsibilities. If it fulfills all of the hopes and dreams that the pioneers who are putting this new role into their companies now have, I believe the role will be a strategic operator that enables, empowers and improves product management itself, while also demonstrably and happily working with its partners in Engineering, Customer Success and Sales to improve the business’s scalability, health and ability to stay close to its customers.
I would enjoy hearing from your experiences, if you operate in this role, or if you have insights from working alongside others in this role. Please comment below!!
Thank you.
