Story from the Frontlines: That's The Solution, What's the Business Need?
Audio Version
Here's an audio version of the article:
What is This?
Stories from the front lines are anecdotes about how to apply ProblemOps in real life scenarios. Hear different examples from different authors sharing how they've lived ProblemOps in the world.
How it Started
Have you ever found yourself trying to describe a problem and actually describing a solution? Building the wrong solution, or picking the wrong problem to focus on, is very easy. Building the right solution to the right problem can be convoluted, because words. Teams need to orchestrate complex work across multiple perspectives. They need to communicate the right information. The less they explore how people solve the problems today, the less they will be able to speak the language of people who rely on the things being built. We have to understand the world before we can develop the language of change. Either that, or we need to commit to the assumptions we think we’re working toward before we evaluate further.
One time, early in my career, end-users made a big assumption about a solution, and it transferred to me. I was making that assumption too. In the pursuit of speed, I didn’t explore the right things. Our team was tasked to re-design a metric tracking feature based on a customer’s request.
How It Proceeded
A feature request came in: “We would like to send data to different webpages in our marketing”. I knew the technical side of this well, and I got to work. I talked to end-users in interviews, and asked them about the request they made. I collected information about a lot of different types of audiences who needed the feature. I collected the different scenarios they needed to support. I made requirements documentation. Then I met with the product owner to show her the requirements I gathered. I was ready for refinement and planning. I was ready to move quickly. We met one day to review the requirements for upcoming sprint planning. As I was going through these requirements, she stopped me.
“What’s the business need?” she asked me abruptly in the middle of my spiel.
“The customer needs page number data added to the URL to pass to other pages. Right now, we only pass “page 2”. We need all other page numbers passed.” I proceeded to show her the task flows, the acceptance criteria, and the research I collected. I described the user stories I made.
She stopped me again. “That’s the solution. What’s the business need?”
I didn’t know what to say. “They need page numbers passed as data across web pages.”
She was very patient with me. “No, that’s the solution. We have to focus on the business needs here. What’s the business need?”
I didn’t realize that there was a difference. The need is the solution, right? They “need” page numbers passed. I was stumped.
Looking back on this, I realize at the time I had no idea what the difference was between a goal, a need, and a problem. I would often describe solutions when trying to describe problems, or needs.
The product owner told me to dig more into current workflows with users. She, like any good coach, did not tell me why she was suggesting this, or teach me, she sent me off to do it on my own. I was frustrated with the request to have to start over. But trusting in the process, I went back out to explore with end-users.
The first time I met with them, I was only asking about the assumed solution. My frame of mind was the specific request they made. I was only trying to understand the “Page numbers being added to the URL query string”. I was not seeking to understand everything about their current process, or why they were doing what they were doing. I was operating off their assumption. They were making a big assumption that what they were doing couldn’t be fixed in our systems.
This time, I started with understanding the entire current state. “I’d like to understand more before we build this feature. I’d like to see how you go about setting these tracking mechanisms up, and discuss the purpose of them”. They brought in the senior developers. It was very complex, and over my head. I had to meet with multiple people and see it multiple times over weeks. Over time, I learned more. I became an expert in their world. I understood their current state workflows. I understood how this work was initiated. learned about the process they and their stakeholders go through. I understood why stakeholders requested this kind of thing in the first place. I understood the ecosystem around it all.
Most of all: I found out why they were doing what they were doing. And I learned about what they expected out of the solution.
“What made you all start passing page numbers into the URL?”
“Well,” they said, “we’re doing it this way today because this other software was set up this way and we’re working around it.”
Ah ha!
“In other software it’s different. Here’s how we do it in other software…”
They showed me how they did metrics tracking in different tools like Hotjar and Google Analytics. It was completely different. In fact, they were using those tools more than they wanted to because of this workaround in our tool. This was a challenge for them. Ideally, they’d have the ability to do this in the same tool they use to send out marketing: our tool.
“What are you trying to achieve by using these other tools?”
The users discussed with me how they receive requests about tracking success metrics of web marketing that they set up. They get a lot of requests that change, and they need control over the setup to successfully deliver the metrics they were collecting. They take a request from a stakeholder (a marketer) on how they want to measure the success of their marketing, and they develop metrics collection based on that. They needed to change the setup for metrics each time, and decide which data to pass.
Eureka! That was it. Control. They needed control over the data! We shouldn’t pre-define the data in the URL at all. Our tool was just doing this because of the way it was made. If we could do it all over again, we should help them meet the expectation of control over the data.
This was the day I learned just what a business need is. A need is an expectation. It’s not the goal, or the solution. A need describes what is expected to be in place in order to achieve a goal, or to solve a problem. The solution describes how to meet the expectation. The problem describes what’s happening that needs to change. It turns out, I was indeed describing the solution. The product owner was right. That day, I started understanding the difference between the solution, the problem, the goal, and the need. Needless to say all of my requirements changed. I rewrote them all. I documented the need, the goals, the problems, and the scope of work that’s required. I skipped describing the solution. I knew that technical experts would develop the best solution based on the need. I knew that I would be best served to describe the expectations and things happening that should change.
I went back to her and said, proudly, “we need to give users control over data passed across marketing pages!” She nodded and smiled. As if she knew it all along. This is when the art of requirements and problem-solving really clicked for me. About a year into the role, when I was faced with my own assumptions about solutions and current state, running with others’ assumptions.
When we built the solution, it was so different from anything we had ever done in our systems. We truly innovated by understanding the heart of the user expectations and their current state workflows.
The Moral of the Story
- The business need is not the solution. The goal is not the solution. The solution is an assumption about how to solve problems. The needs are the expectations that people have. The goal is the outcome to achieve.
- Sometimes, people aren’t able to describe their needs or goals. They speak in solution too. Teammates have to dig beyond what they say.
- Don’t rely on your stakeholders’ or teammates’ words. Vet the words carefully around the language of change. Ensure you and they understand what you are describing before you commit.
- Learn about the current state of the world today without the solution you want. Learn about the workflow, the gaps, the intentions, the opportunities, and the benefits. When you do, you will build a baseline you can use to truly innovate.