Before I Worked in Product
The Customer Education I Didn’t Know I Was Getting
Occasionally I still find myself dreaming about working in retail. Not bad dreams, really, just occasional replays. Resetting demo devices, snippets of conversation, listening to a customer’s story before I could help them. Sometimes I get it right in the replay. Sometimes it ends differently.
I spent a few years on the floor of big box electronics stores as a Google Specialist, and then as a Samsung Experience Consultant. Stereos being thoroughly tested on one side of my section, promotional reels playing full blast on the other. It was loud, busy, and rarely boring. What grew out of that experience wasn’t a profound love of consumer electronics (surprising, I know!), it was something more useful: a real understanding of what it means to educate yourself about a customer before you attempt to help them.
The shop floor taught me a few things that have never left me. Active listening. Capturing pain points. Not jumping to conclusions. Meeting the customer where they were at in their process. There are so many ways to say the same thing, and so many ways to interpret one thing said. I learned that patience and genuine curiosity weren’t just good manners, they were the actual job.
I’m not in retail anymore. But I think about it in the context of where I’m at so far in my professional journey. Even after I moved out of retail and into project administration, then customer success, and on to product management, I never lost sight that to understand the customer was to understand how best we could serve the customer.
Directly before I was a Product Manager I was an Account Manager. I lived on the relationship side of the business; the side where customers said yes, where their account needs were discussed and anticipated, where everything looked healthy on paper (or in the CRM, as it were). As AMs, we were deliberately kept at arm’s length from things like support issues. We’d gather the bare essentials before handing off to the support department. That made operational sense, and the process worked the way it was designed to.
What I didn’t fully see from that position was the other side of the customer experience. So when the opportunity came to move into Product, I asked if I could also take on Support. In many ways I had already been thinking like a product manager before the title arrived, consistently looking for ways to improve the customer experience, flagging opportunities to streamline processes, and bringing constructive feedback about what could be better. I like to think that is what opened the door. Support was also a natural fit for what was needed at the time, and I was grateful for the trust placed in me.
The transition was handled carefully. My accounts were handed off with intention, I had time to find my footing in the PM role before the full weight of both responsibilities landed, and I had leadership that was genuinely brilliant and supportive. I had good foundations and even better people around me.
I asked for Support Operations specifically because it felt like a sister department to Product rather than a separate function. Product asks: what are we building, and does it serve our customers? Support asks: where is it falling short, and what does that feel like for the people experiencing it? You can’t answer the first question well if you’re not accounting for the second. Together, they give you a fuller customer education than either one can offer alone.
We were in building a new platform for our product at the time. If you’re rebuilding from the ground up, one of the most important questions you can ask is: what are we not carrying forward? Not just the technical debt, but the friction. The small persistent issues that clients had learned to work around. The things that never quite rose to the top of the priority list, for reasons that made sense at the time. Those things live deep in the support queue. They don’t always find their way into the broader product conversation. In any product, small friction points have a way of adding up quietly over time. That is just the nature of building things for people. I wanted to understand where those moments lived.
And there was a second question: if the new platform actually solved some of those old problems, how would we communicate that to the clients who had experienced them? How do you speak to it with any depth if you didn’t fully understand it in the first place?
This is precisely why a Product Manager benefits from understanding the support side of the business. Not to carry the weight of every unresolved issue, but to be informed enough to speak to the customer experience with depth and credibility. To be the voice in the room that can say, with confidence, that a particular frustration existed, that it mattered, and that it has been addressed.
That’s what drove me. Not a grand strategy. Just the very practical realization that you cannot build something better for your customers if you only know the version of them that shows up in the customer success side of the relationship. You need to know the support side, too.
So, you may be thinking, “That’s great, but I’m not both the PM and Support Ops manager, so where does that leave me?” I assure you, you don’t need to be thrown in at the deep end in the form of a lean, agile-influenced development environment. There are ways to better educate yourself on the customer experience without wearing multiple hats every day. You just need to be genuinely curious, and develop trust and communication with other departments.
Listening to support calls is one method that’s chronically underused by product teams. Many organizations already record these calls, with the customer’s knowledge, making it straightforward to build into a regular habit without disrupting the support team or the customer. The actual call is where the nuance lives. The detail of how the product fits into their particular workflow, the things that came up conversationally but never made it into a ticket, the context that can change everything. I made it a point to stay informed by Support specifically so I wouldn’t lose access to that unfiltered picture.
Sitting with your Account Managers and Customer Success teams regularly, not to debrief after the fact, but to actually be present, is another piece. The AMs know things that never make it into a CRM.
Then there are the methods that feel rigorous but can mislead: NPS scores, CSAT surveys, feature request logs. These are useful for identifying trends. They’re nearly useless for understanding why. A rating tells you something happened. It doesn’t tell you what, or what to do about it. While it is possible to synthesize potential meaning from patterns in these types of data, I would treat them as a starting point.
A low score or critical feedback is an opportunity to learn more. To learn why. To learn what is actually needed. Pick a critical customer and reach out to them. You can’t make promises that you’ll remedy what they’ve requested right away, but you can promise that they’ve been heard, that you’ve made the effort to understand what they actually want or need from the product, and that you’ll take it back and make sure it’s reviewed seriously. People want to be heard. People want to be understood. People want their troubles to be taken seriously.
Those three points are not things I learned in a product meeting or from a methodology handbook. They are things I learned on a shop floor in a big box electronics store, standing next to people trying to make decisions that mattered to them. That is where it started for me. Your starting point may look completely different, and that is fine. What matters is that somewhere along the way, you find your way to the same understanding. Curiosity is its own reward.