Date: 10/6/2022

From Service to Scrum

Software/product development roles require a very different mindset from a role in the service industry.

My first job was in service/retail. I was a courtesy clerk (bag boy) at Safeway. When I started, Safeway anchored their mission and how employee training was structured on superior customer service. It was boiled all the way down to clearly outlined quotes to use when you encounter a customer in the stores: “Hi, how can I help you today?”, “Are you finding everything okay?”. And then when a customer needed help finding something, there were rules for how to describe where it was: don’t point to the area of the store where the item is, take them to the product if you can, etc. They would have secret shoppers come in and grade the customer service they received from employees in the store, which would be sent to the store and district manager as a report.

My point is that all clerks prioritized how to make the customer happy in each discrete, separate customer interaction. And to be good at your job, you obsess with making each customer happy. This is how I learned to approach customers when I’m at work.

Now that I’m in a product role, managing the development of a couple pieces of software, this approach has become quite a burden in some cases. My job as a product manager is to make decisions to improve the overall adoption of the product, increase its market share, find the best product-market fit, and clearly communicate its value. But I’m still working directly with customers in many cases: sales and support calls, customer interviews, interacting with internal users.

At its core, the “market” is not one person. It’s a large group of people–potential customers–for whose problems you are trying to mitigate in order to drive adoption of your product. No longer does thinking about each customer as a single entity work. We can’t optimize for making each and every person individually happy.

It becomes a numbers game. The “market” is a group of people, who have wide varieties of problems, constraints, experiences, and because of that, thinking about the perfect solution for each individual person is not going to work. Instead, it’s the balance of solutions that can solve a problem from multiple angles in order to make the highest percentage of the market happy.

A couple of specifics here:

• When talking to a customer, a specific feature, button addition, change in data visualization, etc. cannot be automatically added to the task board no matter how perfect of a solution it is to that one customer. Instead, it needs to be thrown into the machine and added/compared to other various forms of feedback to figure out which feature is going to solve the most customer issues.
• If there is a non-breaking bug or a design that is getting in the way of a specific customer’s ability to use the product but for very few additional customers, as much as the solution is crystal clear, sometimes it is not a change that makes the most sense for the builders to implement.

The hardest part for me has been the latter–hearing an issue during a customer interview that makes sense and is clearly fixable, but knowing that I can’t implement it because there are higher priority tasks/projects. The service side of me feels it the most, but that’s the theme here; I’ve had to actively detach from the way I first learned to interact with customers by solving their problem individually.