Earlier this year I switched my career path from Customer Success to Product. Working as a Customer Success Manager had been a natural fit—I've always loved working with people, and enjoyed the challenge of fully understanding a customer's needs, then finding a creative solution for them.
I find that so much of the work a CSM does with customers is on the periphery of the product, rather than in the product directly. Coaching on best practices has just as much to do with the team and their processes as it does with teaching product knowledge. I spent a lot of my time trying to understand a customer's goals and developing a plan to get them there. I would capture these needs, collect feedback, and act as the customer's advocate within ZenHub.
More and more, however, I found myself getting curious about the product itself. I started to wonder if there was a way to solve these problems before they even got to the customer. Instead of me anticipating the needs of the customer and providing them support resources, how could the product anticipate their needs?
Armed with this curiosity (and a few other factors) I decided to make the leap into a Product Owner role. There's been a steep learning curve, as expected, and I still have a long way to go. However, I truly believe that my background in CS has given me a unique perspective and valuable set of skills that have helped me in this transition.
mile Sprint in their shoes
Most obvious is the user perspective; as anyone in product already knows, looking at the product from the user's point of view is absolutely vital. But sometimes you end up too close to the product, and too far from the user.
Recently I was working on a project around onboarding new users into ZenHub, and I found myself stuck. Then I thought to myself, how did I used to explain this to customers? What features did I start with? When you’re talking to a customer, you get instant feedback: “I don’t get it” or “that’s really cool! I can see how that will save me time”. I used this experience to guide the project and ensure I'm starting from the most logical point.
Sometimes solutions are the problem
Talking with customers every day is a good reminder that usually they know a lot more than you! Our users are subject matter experts, and many have spent their entire careers working in this field. Our users provide excellent feedback, and it's important to listen to what they're saying. What's equally important though, is identifying the underlying problem, not just the symptoms.
Due to the nature of ZenHub, our user base is made up of people who love to build things. This resourcefulness is what makes them so wonderful to work with, but also means they often provide feedback in the form of solutions—a skill that is incredibly useful in every other application, except for product feedback! I learned in CS to dig into this feedback, to prod and poke until I understood the real challenge.
In fact, understanding the true pain point is how ZenHub was created. Several years ago, a Project Manager in our parent company, Axiom Zen, introduced a new project management tool. The engineering team was initially resistant, and the PM had a difficult time getting the team to keep their project status up-to-date (a challenge I'm sure many of you can relate to). Instead of making assumptions about why this process wasn't being followed, the team dug deeper into the issue. They were able to uncover the real pain point: context switching between GitHub and the other tool slowed the engineers down and interrupted their flow of work. The team came up with the idea to build project management directly in GitHub, and thus ZenHub was born.
You can't always get what you want
The hardest lesson I learned in CS is that if you try to please everyone, you risk pleasing no one. Being clear about the value of the product and demonstrating how it's meant to be used, is a key part of ensuring success for your users. But it's also important to be upfront about what the product is not designed to do.
I've seen customers adapt ZenHub for use cases we never could have imagined. It's incredible to see how innovative our users are, and it's wonderful when these creative solutions are able to address an ongoing pain point. However, no tool does it all, and your users will appreciate your directness. Communicate the rationale behind product decisions and the best practices that the tool is designed for. This will build credibility with the users and help them implement better practices for their teams.
So, what’s the takeaway?
If I could share one piece of advice, it’s to get in front of your users as much as possible. I credit some of my most valuable attributes as a Product Owner—empathy, curiosity, and communication skills—to the time I spent working one-on-one with users. Oh, and become best friends with your local CSM. They’re full of amazing insight and usually ahead of the curve in customers trends. Plus, their middle names are literally ‘Success’. What more could you ask for in a friend?