Product innovation describes an approach to work characterized by certain mindsets and behaviors that has a goal of creating or modifying digital products that better serve people. When teams embrace these mindsets and behaviors, they can consistently innovate––that is, they can consistently create new sources of value for their organizations.
It’s a compelling promise. When we work with client teams, we find that designers and delivery leads tend to see the value product innovation has to offer their work right away. Engineers on client teams tend to have more reservations. In many cases, they recognize it as an ideal way they’d like to work, but feel they’ve been cut off from it or punished from trying it in the past or that they were “veering out of their lane.”
Those reactions are understandable. Part of our job is to create an environment where we can get past reservations and reluctance to a place where everyone in an organization can experience the benefits of product innovation.
To that end: In this piece, we’ll take a look at what lies at the intersection of product innovation and DevOps, and how operating more intentionally in these intersections can lead to more human businesses that work better for everyone.
Intersection 1: Effective storytelling
Storytelling is a powerful tool.
Why? In part because humans make decisions with the emotional part of our brains rather than the logical part. While we may justify decisions with data after the fact, the big decision-making function is one of emotions.
When developing new products using a product innovation approach, storytelling is most visible during the “pitch and commit” phase, in which advocates for a feature or product get buy-in by sharing data and stories in ways that evoke emotional responses.
But infrastructure teams aren’t in the business of developing new products. Their job is to keep systems running correctly. At first glance, it might seem like they have no need for storytelling. But look closer, and you’ll see that storytelling can have a profound impact on infrastructure teams.
For example: Imagine an end-of-week standup that starts with these questions:
What was the best thing that happened to you this week? Why?
What was the biggest pain point? Why?
This approach is anathema to most infrastructure teams, which tend to focus on quantifiable outputs: uptime, deployment frequency, error rates, and so on, that measure the work product but not the people doing that work.
In other words, typical metrics completely remove the human element. That’s a mistake. It’s impossible to separate the work humans do from the humans themselves. And it’s impossible to separate humans from our emotional experiences.
Engaging with narratives about our work forces us to grapple with its human, emotional aspects. And that opens the door to improvements that aren’t otherwise possible. To understand why, let’s look at another way product innovation and DevOps intersect.
Intersection 2: Building empathy
Building empathy is a core concept in product innovation and working differently. It’s one of the behaviors essential for developing products that earn widespread adoption. In product innovation, empathy building often manifests as user research and in the principle called “see and experience.”
As it happens, storytelling is an excellent way to build empathy.
For the infrastructure team, let’s go back to that end-of-week meeting. Instead of the best / worst questions, let’s consider a meeting that focuses on whether or not the team met its goals.
That’s a binary way of engaging with work: yes, it got done or no, it did not. This approach doesn’t leave room for how or why it did or didn’t get done, which means it doesn’t leave room for the people who got it done.
Now consider the meeting we mentioned above: best part of the week, worst part of the week, and why.
Suddenly, you’re framing the work not in terms of whether it led to certain outputs in a non-living entity like software but in terms of how it impacted the people doing it. Maybe all the work got done, but it required half the team to pull all-nighters––a situation which is both unpleasant for the people who had to do it and unsustainable for the business as a whole.
A binary analysis wouldn’t reveal that underlying problem, to the company’s detriment: while the company steadily meets its goals, its employees are looking for other work with less unpleasant conditions, which will cause expensive and time-consuming turnover, which could lead to system downtime, which could affect all downstream users, which could lead to nasty calls to the service center, and so on.
If we’re working in the “normal” way, where the bottom line is the bottom line, so to speak, the all-nighters are an unpleasant but necessary part of doing business. The “working differently” / product innovation mindset pushes us to ask whether they have to be. Which brings us to the next point.
Intersection 3: Taking ideas off a pedestal
One of the behaviors that helps propel the work of product innovation is to “question and reframe.” In practice, this means taking ideas off a pedestal. Any time you find yourself saying something like “That’s just how it’s done in DevOps,” or “We’ve done it this way for years” or something similar, there's an opportunity to question and reframe to get to better outcomes for everyone involved.
For example: the reason the infrastructure team had to pull all-nighters is likely that the company they work for requires constant uptime for its software––a standard requirement for most SaaS products.
One question a product innovation approach to DevOps might push you to ask is why: why do we assume software must be online 24 / 7? And similarly: is there a better way?
We’ve actually started asking some of our clients this question, and in some cases the answer is yes. In some cases, we discover that it’s okay to have software be offline between, say, midnight and eight a.m. Structuring a product in that way might even lead to cost savings––and, even more importantly, a better experience for the people who maintain the product.
What people-first innovation looks like
A common misconception about innovation is that it means doing something entirely new, something that’s never been seen before. This mindset can prevent organizations from even considering approaching problems with a product innovation mindset. “Innovation” seems like something too big to tackle and too hard to scale.
In reality, what counts as “new” or as an “innovation” can be small. It can be new for that organization or new for a team. It can be as simple as running end-of-week meetings differently. The impacts of even small changes can be significant for the people involved.
Take that end-of-week meeting, for example: prioritizing people’s experience of doing the work will inevitably lead to changes that improve that experience, which means they’ll be happier at work and more likely to stay. That change alone can yield major rewards: engaged employees who feel a true sense of progress tend to contribute differently, more positively, more freely.
But chances are, there will be a ripple effect. When you start approaching problems through the lens of what makes for a quality experience for the people involved, you start working in a whole new way and opening up a whole new world of possibilities.
Outside of the infrastructure context, one of the most visible manifestations of approaching work people-first happens on engineering teams: give developers a target user experience rather than a set of requirements, and you’ll find that what they build requires less rework. The people-first approach empowers developers to think critically and use their experience to find the best way forward.
Humanity is a feature, not a bug
The accepted (but often unstated) assumption in much of the business world is that our human nature holds us back from achieving as much as we can or should. Just think about all the productivity advice out there that focuses on “hacking” our bodies and minds to eke out the maximum number of work units every day.
Product innovation helps us work differently, in infrastructure and throughout an organization. It does that in part by pushing us to question underlying assumptions we don’t realize we have and that are hurting our ability to make meaningful progress. And it helps us operate and innovate by putting people first, which can lead to dramatic change.
We have a lot more to explore at the intersection of product innovation and DevOps. If this piece caught your interest, we’d like to invite you to read more about our product innovation approach and connect with Antonio García, our head of design, at antonio [at] txidigital [dot] com.
