Stories from the Frontlines: We're Losing a Million Dollars!
Here's a story about the importance of determining which use cases you will or will not support after you deliver change to the market, and how to serve someone's growth when they fail.
Audio Version
Here's an audio version of this 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.
Check out the other stories here:

How it Started
When you're new to a job, you could make a lot of mistakes. How you react to those mistakes is part of your growth. Hopefully, the people around you give you grace. Hopefully they let you own the mistakes and learn from them. And yes, sometimes those mistakes can be costly. That's where the real test comes in for a people-first leader. How do they react? What's their mode of operation in high stress? Will they back up what they say about prioritizing your growth? Whatever they do, that's their own journey of growth.
Great people-first leaders and great people-first teammates serve each others' growth. They see mistakes and risk as opportunities to learn. They let people try things for the first time. They let others continuously improve. They let you make wrong judgment calls. Sometimes serving growth can be hard when you feel the need to "just get it done". But your growth relies on your persistence to resist that temptation.
I've learned that it's important to prioritize growth in these bad situations. Everyone else wants it fixed, and they want it now. Don't give into the pressure. Consider what the pressure is doing to the people around you. Appeal to the people who want the solution and appeal to the people who can learn from the mistakes made. It's more important to build up your team and not own their failures. It's important that your team feel the stake in the outcome together. Give them the gift of owning their failures. Even when it's consequential.
I was blessed with a people-first leader when I was coming up in my software career. She didn't take over, and she didn't give me answers. She certainly didn't prevent my failure. And one time, I made a bad mistake. One that costed our customers millions of dollars. I learned so much from her reaction to that situation as well as the situation itself. People-first leaders appeal to the customers and appeal to their team's growth. When they do this, they build other leaders around them.
And now, hear about the time I costed companies "millions of dollars" because of decisions I made. And what my boss did about it as a people-first leader.
How it Proceeded
I was working on a team that had an app out there in the world. It had been on the market for a while, and we amassed a lot of customers. Each one seemed unique: they had different needs and different ways of work. This made it challenging for our team to account for all audiences. Whenever planning features, we'd need to consider conflicting priorities across our user base. Sometimes two types of customers would conflict in what they needed. It forced us to build more flexible software, like providing options to turn off features.
Needless to say, this made our life on product management complex. The system was growing in complexity everyday. We had to be careful about how parts of the system affected other parts. One wrong feature delivery, and someone somewhere would be negatively affected. We worked around this by building more test time into our releases. We'd let users try the new feature for a while before we launched so that we could catch bugs. We did catch a lot of situations where we'd change the logic to account for conflicting needs. It became the norm.
About a year into my role as a business analyst, I was given full ownership of a new feature. It required a lot of different uses and scenarios. Our ten different clients said they needed it ten different ways. I was careful to map all of the use case scenarios that would be changing with this one. Some happened more often, but some did not. Or so I thought.
My manager gave me the ability to decide everything. I would come to her and review items, but she let me decide when to do so or not. I felt completely empowered to take on this work. It was also a scary time: I could make a mistake any moment that could come crashing down. My manager, rather than preventing mistakes, shared her perspective and let me decide.
And I chose the wrong decision.
It was at the moment when I needed to decide which use cases to support in the first release. There were over five use cases of business logic in this feature. Every customer seemed to want a different piece of the feature. A lot of customers had already been using the feature and we needed to make sure nothing broke.
I, of my own judgment, made the decision to de-prioritize a use case of the feature that was already being used. I had heard from some customers that they didn't use it, and assumed (WRONGLY) that it wouldn't be a big deal to remove. So I did.
I documented it, built it with the developers, and carefully planned launch. I worked with customers to give them a heads up. And then the feature launches.
I remember it clearly because it was a Monday morning. I was preparing for the day when our support team member spoke up about tickets.
"Wow, we're getting a lot of support emails from this customer".
I knew it had to do with the release I worked on. I was prepared for this moment. Maybe a little too confident. They said it was about the new feature, and there was something missing. Before I could investigate further another manager comes in. He was on the phone with a customer.
"We're losing a million dollars every hour this thing is not working!"
Something went horribly wrong. It turns out, the use case I decided to remove was heavily in use by a few customers. I did not check with them about removing the feature, and I made an assumption that they could use the change. I was wrong. I made the call to change and not speak with anyone.
And so...the customers were losing a million dollars an hour.
What did my boss do when she heard this? She simply said, "What happened?...Well, what's your plan?"
She could have screamed. She could have forced me to do it her way before it launched. She could have blamed me. But she didn't. She let me feel the full weight of the mistake to learn from it. After all, if she had prevented my failure, I wouldn't have learned the lesson. Sure, customers wouldn't be in pain, but I may have made that mistake again. I wouldn't be able to teach others about the lesson I learned. And she was still accountable for the result. This work represented her leadership, and mine. Even given this, she still prioritized the opportunity for me to grow than a perfect result. She also focused on how to save the relationships with customers so that they didn't feel left out.
I made a plan to fix the software quickly and change how I review changes with customers.
And then all was right with the world. Customers went back to making money and I never made that mistake ever again. A people-first leader, my boss, made another people-first leader that day.
The Moral of the Story
- When in moments of pressure, prioritize the growth of others around you. Give them a voice. Provide room for someone else to own the outcome. Even, especially, when they fail.
- Prioritize your customers' use case scenarios before making change. All of your customers. Use this template to be able to make change quickly while adhering to the important use cases. Use this template to do so.
- Don't just look at how the change affects one type of customer. The others could be "losing a millions of dollars". Look at each type of customer you have and analyze how the use case scenarios of change will affect each one before you make a decision. Make a decision based on all customer segments.