Introducing ProblemOps: A System for Making Change in the Age of AI
TL;DR: Building a shared language around problem-solving across business functions and helping people make it happen is the future of UX, product management, and operations work.
Audio Version
Here's an audio version of this article:
The Modern Era of Work
The world is changing fast. Businesses move at the speed of convenience and return on investment. People trying to make it into the work world, or move up in the work world, are at the mercy of business thinking. We navigate it. We define our work within it. Underneath it lies the engine of making change in the world. Everything we produce, everything we launch, changes something for people. The change could benefit some and harm others.
When we do the work, though, we may not talk about this. We may strive for convenience when we describe the work. Convenience has become a focus in our lives. Whatever it is, it must “save time” or “be so easy”. In pursuit of this, people in the world remove nuance and reduce concepts. Businesses prioritize ease and speed. Humans want to cut down complexity. We make up terms to convey the meaning of complex concepts. Names and terms change their meaning over time. We misunderstand each other all the time. We assume conclusions, and bias our thinking towards our own experiences. After all, we’re only human. It’s our nature.
User experience or product management people face “the problems versus the solution” dilemma. It’s more convenient to talk about solutions. The “solution” is often more prioritized than discussing the “problems”. On one side, the people who focus on “the solution” pride themselves on speed and ease. On the other side, the people who focus on “the problems” pride themselves on understanding and evidence. Both sides are often at odds, or so it seems. Many teams have struggled between which one should take precedence. Is it the “solution” people who get the say, or is it the “problem” people?
They are actually talking the same language, and saying the same things. The problems equate to solutions. The solution has many problems it is solving for, whether we talk about them or not. There’s a direct relationship between the problem and the solution, and they are the same essence. This is the language of change. The reader may not understand that language yet, but you will. This is here to teach you how to speak it and how to build alignment with it. The language of change starts with a shared understanding. It's all about what’s happening right now, the expectations, the outcomes, and the consequences. Our job as change makers is to make the problem-solving process easy and accessible.
Sometimes people think the clarity building won’t be easy. Maybe you've heard this from others: “We don’t have time to talk to people, let’s just launch the product and see”. UX people (current company included) fight it. We resent it. We get virtuous or argumentative. But we forget that the people who think this way are thinking about the same things we are. Both sides are trying to make change. They may not say it, and they may have started from a different perspective, but they have outcomes they want to achieve. They have changes they want to make. It’s our job not to force our way of life, but to understand each other.
This is not a UX system. The world doesn’t need another “UX” system, or another “Product management” system. We’ve got a lot out there. Sometimes UX and product management are seen as barriers to speed and convenience.
We need a language system. We need a people system. Working with teams across different functions is more important than ever. Businesses that “ready, fire, aim” make change, but they may talk about the change in different ways. They may focus on the “How”, and not the “what” or “why”. They are all different parts of the same language. You will learn how to translate the how into the what and the why through the language of change.
The Author’s Experience
I’ve navigated the convenience factor in my professional life for 20+ years. I had a winding journey of different careers. It led me to where I am today, leading teams and making change in this world. I started in sales and transitioned into the information technology world. On the way I discovered user experience design. I fell into agile software development on the job. I fully believed in the power of human-centered design. I believed in informing our decisions with research and evidence.
In the business world I saw different mindsets between business people and UX people. The people in my first software job were smart and focused on execution. They were inspiring because they got things done. They had their own way of looking at how their decisions of change affected those who use the products. Sometimes they didn’t see what the UX people saw. “Users are smart, we will train them. But we have to make a decision.” When solutions failed in the world because they didn't inform their decisions, they treated that as a normal thing. A status quo. The work got done, onto the next version. Measures of success were low, and it was all about the journey to the next round of work.
At first, early in my career, I prioritized making sure others understood me. This often led to a lot of frustration. I thought there was a correct way to build products and services. Involving humans before deciding was the right way. I made pitch decks about human-centered design work and shared them out. I preached what I learned in academia. I spoke loudly about doing research when it wasn’t happening. I dismissed a lot of people instead of building trust. I thought UX was “right”. Why don’t people listen to what I say? Why don’t they believe in human-centered design practices? Why is UX so hard to achieve? I degraded relationships with clients because I didn't feel heard or understood. I judged their decisions to launch without research. I felt misunderstood.
I didn't stop to think that I was not understanding others. At some point I started seeing the pattern. A lot of people with different perspectives misunderstand each other. It’s “their way” versus “everyone else’s ways”. This is the perspective that creates dissonance in teamwork, and breaks shared understanding. It prevents us all from understanding each other and how we’re all really speaking the same language. So, I worked to understand others first. What do they mean when they say “research”? What do they mean when they say “feature”? I stopped assuming what they meant and started building a shared language. I started leading teams by involving them in the shared language. I started teaching them how to navigate teamwork outside of our orbit. The language of business and the language of human-centered design is different. We needed to translate what we say to the business and describe what they related to.
When we speak words, we risk being misunderstood. When we show results and allow others to participate in our practices, we show them our world. We build a common understanding. This was one of the most powerful lessons I ever learned in my professional life. I still practice this with others to this day. Show, don’t tell. Involve others in your work and the decisions. Build allyship and common cause. Show people that it’s “us versus the problem”. It’s not about being understood, it’s about sharing understanding with people. This is how change happens in the world that actually makes a difference. The discipline of ProblemOps embodies these approaches.
Defining ProblemOps
ProblemOps is a new term for a new era of work. It’s centered around people on teams and people out in the world. Like every great operational structure, this one is determined by the people who operate. You choose how you want to apply this to the context of your teams. Many other frameworks have come before. But the words have lost their meaning, and it’s time for a new definition.
ProblemOps stands for Problem-Solving Operations.
Problem-solving means “Making change in the world”
Operations means “The practice of carrying out work”
Combined, you get “The practice of carrying out the change you make.”
It is completely new:
- Multidisciplinary
- People-first
- Flexible
ProblemOps teaches people how to:
- Build a shared understanding
- Unite with everyone involved
- Incrementally deliver value
- Measure progress
Goodbye Jargon
Words. Words words words. Words are confusing. Words are interpretive. Words matter. Words are what got us here in the first place. We won’t get anywhere in this world if we can’t communicate the essence of what we mean and align around it. And make it as easy as possible for anyone to do so together (“convenience factor”). Jargon is easy to say but hard to clarify. In pursuit of a common understanding, ProblemOps will not use words like “UX” or “Agile” or “Design” or “Product” (except right now, in the introduction). It will describe the essence of this work: team-based problem-solving.
“Team-based”: doing work within teams.
“Problem-Solving”: making change in the world.
We can make change in the world with teams. As you read this over time, you may see familiar tools and methods. Those who come from the UX world or the product management world can relate to the content of this system. This is on purpose. The words have lost their meaning, and it’s time to redefine it all. UX and product management professionals are all doing the same things. We call them different things, but the essence is the same. The methods and tools taught in UX and Product Management come together to build the language of change. It doesn’t matter what we call it. It matters how we do it. Over time we’ll call ourselves something different: ProblemOps specialists.
Building Something Out of Something Else
There are over 50 years of problem-solving academia to explore. HCI, UX, Information Science, Team Science, Systems Engineering, Philosophy, Business, Operations. So much more. Scholars and industry experts have countless methods, perspectives, and philosophies on it. There are no common terms across them, but their essence is the same. They all drive change. They all enable problem-solving. The labels are where people get confused. Many companies label different jobs. There are different requirements for the same job. Some companies make up their own definitions based on their current needs. If you ask ten professionals what “UX” is, you will likely receive different answers.
Why does this happen? When we apply things to the context of the real-world, the theory bends and breaks. The words take on new meaning because we humans shift the meaning. This is the root of Linguistics (reference). The real definition of things is based on what happens, and what we agree to. It’s not based on what should be. Putting a label on something, like a job title or a discipline, is risky to shared understanding. To move forward together, we must agree on the same terms and meanings of the terms.
And Then There Was ProblemOps
This new discipline will look familiar. It blends disciplines together. Language is the universal way to change the world, and ProblemOps is a language framework first.
ProblemOps drives four key components with a shared language:
- What’s happening right now that should change?
- What are our shared outcomes?
- How will we know we’ve met expectations?
- What do we want to commit to now and later?
This is called the “Language of Change”.
How teams carry it out is up to them. The methods or disciplines or workshops or deliverables they choose can change. The ProblemOps discipline is a Linguistics discipline. It helps you, the reader, create a universal meaning across teams.
In practice, ProblemOps combines the following disciplines:
- User Experience
- Service Design
- Product Management
- Systems Engineering
- Operations
- Agile
Remember, be careful of the terms. The meaning of these terms differ. You may take away different things when you read these terms. This is precisely why we need language building tools over anything else. Rather than define the terms, this will show you how they are used together to form a new discipline. It purposefully doesn’t use the terms that came before. It encourages people to show results and align in language. Use this for context before you move forward.
"People-First" in the Age of AI
Technology will continue to evolve. Businesses will continue to prioritize speed and convenience through technology. As our reliance on AI grows, so should our reliance on humans. People will continue to be at the center of the work. Language will continue to be the essence of understanding. Humans will work with machines. Our teamwork together must become a central focus. "People-first" doesn't only imply a focus on people who use our products. "People-first" also implies focus on teammates; colleagues; bosses; interns. Teammates could be other AI models too. In pursuit of change, we must understand each other to work together. Everyone has to understand each other and the changes they’re moving towards. Everyone has to belong in working together. The language of change relies on us to build relationships with humans and machines.
Who Should Benefit from ProblemOps?
UX Designers, UX Researchers, and Customer Experience Strategists
Somewhere in the history of the work world, “UX” has lost its original meaning of “problem solving”. Its meaning changes based on lived experiences or opinions. Ask founders, hiring managers, and UX people and they will describe different things. But when it comes down to it, the essence is problem-solving. It always was, from early day library science to modern day “product design”. Whatever we call ourselves, we are problem-solvers at heart. We get back to our essence with ProblemOps. It helps UX people operate around alignment throughout the entire business. Whatever we call it we will build a shared understanding of what we’re changing and how we’ll get there.
Product Managers and Product Owners
Product people (whatever you call them) help all teams make change. The approaches they use and the work they perform are problem-solving. Underneath the “solution” lies a whole lot of scenarios that audiences face. Those scenarios will change how people live. Product people juggle needs from the business, technical possibilities, and other humans. ProblemOps helps product people speak the language of change.
Business Leaders
As businesses grow, operations become more challenging as many teams work together. Teams can easily fall out of line with vision and priorities. ProblemOps helps leaders unite around change. It creates a common language for business leaders. They can communicate the same thing to all team functions across all departments, and move towards the same outcomes.