From Customer Success Management to Product Management
Segment's Adam Dadson walks through the process he took to become a product manager, complete with tips and tricks for PM hopefuls!
Segment's Adam Dadson walks through the process he took to become a product manager, complete with tips and tricks for PM hopefuls!
If you’ve been following the Segment blog, the topic of shifting into Product Management is a popular one. I’m here today to share another example, the shift into Product from Customer Success Management.
While I can’t promise there’s a magic formula to guarantee such a career pivot, I’d love to highlight a few of the lessons I learned and provide you with an opportunity to steal them for yourself.
Throughout my career, from fashion to media to technology, the most energizing and euphoric moments were when I could solve problems, and reduce mountains to molehills. It didn’t matter what problem I was solving, I relished the feeling of seeing ideas and discussions come to life with tangible results. That feeling has never diminished in any role.
As a Customer Success Manager at Segment, you are in pole position to interact with customers and understand how they use, quantify the value, and prioritize the needs they have with our product. You have the opportunity to nurture and sustain the individual trees within the forest of Segment to build a partnership.
My calling to shift into Product Management was to see the forest more clearly, as well as a personal “North Star” sentiment to solve as many problems as possible for our customers (internal and external). When a feature I worked on with Product to prioritize and scope was shipped, I knew a relevant customer would be thrilled, but I also knew I would also be making a difference for customers other than my own.
My final realization was that the most impactful conversations I had with customers were deeply technical in nature, and the satisfaction that provided me was incalculable.
As a CSM, you’re blessed with the opportunity to build bridges with PMs, engineers, researchers, designers, operations managers, and so many others. Seize that opportunity, because these individuals are not only the folks who validate your skills; they’re also your future partners.
Introduce yourself, build bonds, learn about their day-to-day roles. These teammates can shed light on their experiences with the nature of their role, and it is crucial for a potential PM to listen. It will also illustrate both the highlights and the lowlights of the world you’re about to step into. You can become a trusted resource if you give generous, thoughtful feedback about what they’re working on (hint: this is product feedback, and it means the world to any PM). Thoughtfully volunteering the right customers for the right projects builds trust, and ensures alignment on communications.
Early on at Segment, I found myself interacting with my Research and Development colleagues on a frequent cadence. I began to learn about the different team cultures and the assortment of PM mentalities that exist. For example, some PMs are deeply motivated by writing and vision generation, while others are driven by product infrastructure.
My CSM work required me to intersect with Segment’s R&D leaders on relationship management and challenging projects for singular customers that we knew would require significant cross-functional effort to accomplish. These moments were key opportunities to put my product-minded hat on and show I was interested in partnering with their teams to solve problems.
Leaders in our C-Suite, the VP of Engineering, and a Director of Product consistently mentored me and pushed me to explore Product once I volunteered my interest in the position. These individuals can’t control whether you get hired or not unless they’re part of your interview loop, but they are regularly thinking about key OKRs (at Twilio, we call them BPMs) like hiring.
They can introduce you to other individuals to speak to, or share when roles open up that you could be considered for. When the time came, multiple PM leaders whom I greatly respect and looked up to asked me to apply.
Once you’ve built rapport with your future teammates, the next step is to take on projects. A product leader once said to me: “A project illustrates two points: aptitude and interest.” It illustrates your ability to step into a problem-solving role and the opportunity for you to personally assess your interest in moving into a Product Manager role.
Do you enjoy design thinking, defining problems, and the requirements to solve them? What about stepping back from customers in your project? These are important questions to consider as you tackle your first project.
I stepped into a project that involved shipping a new-and-improved S3 integration that was accompanied by Segment-wide impact (S3 storage is one of our most popular integrations). It touched every customer and required me to aggressively explore business writing (which was in keeping with Twilio’s principle of “Write It Down”) and collaborate with numerous teams to begin building the product.
The decision-making process was deeply illuminating, as it required defining the requirements in a way that would aid every customer using S3 for their storage.
An initial mock I utilized to highlight the improvement with the new S3 integration
These projects will be in addition to your day-to-day work, making them a time investment. However, by leveraging deep knowledge of customers and their use cases, you’ll understand them in a different light. A benefit I never realized before I began my project: you’ll likely find yourself to be a more empathic CSM; one attuned to problem-solving. One of the most challenging mindset shifts from being a CSM to a PM is that PMs do not think about the solution. PMs think about the problems to solve and the jobs to be done (read more on this topic, it’ll be worth your time). Your goal as a PM is to learn why this is a problem and what the customer would require to solve it. You then pair with a designer to translate these problems and requirements into a mock prototype. This is followed by engineering, where you take your design and requirements and turn it into a technical concept to be built.
For instance: let’s say you’re trying to solve a customer problem of building the best device to hold a quantity of water. Your goal as a PM is to understand this problem (your customer is thirsty!), and what they require (portability and a watertight seal!). You then bring these requirements to your designer who creates a visual representation, and then an engineer who will tell you what’s required to create the world’s best eco-friendly bottle.
When it comes time to interview for a product role, you’ll want to deeply understand what the role and the interview are asking of you. Like all careers, there are multiple types of Product Management, and your projects and interests must align to the role you’re looking to move into. “Interview” your manager just like they’ll interview you. This is a person you need to be in lockstep with and who will teach you the most fundamental PM skills.
Your current manager should always be aware of this change if you’re moving internally. Work with them to put together a plan for you to transition roles in advance, and to focus on telling your best story. My CSM manager was my biggest advocate and not only supported me but championed me to my would-be manager.
Ask yourself as you receive your presentation prompt (there’s always a prompt): what type of problem are you solving? You’ll need to be able to crisply answer this, as you begin to think through how to highlight all of these longstanding CSM and newfound PM skills (from that handy project that allows you to conceptualize the problem-solving process!).
Oftentimes, you’ll need to package these findings in a presentation format, so weave in those storytelling skills that you used for customer QBRs.
In my interview, I found a pressing business problem that deeply interested me. While it is not yet public-facing, the steps I took to present it are evergreen. I felt strongly motivated to research the topic, find data points, create a strong, visual-heavy deck (with good GIFs), and present the topic. In retrospect, it’s by far the best deck I’ve ever made.
Take advantage of your fine writing skills, too. For those executive prep docs you write from time to time, leverage that muscle to succinctly convince your audience. Finally, remember these two points:
Data will always underpin the most ironclad thesis.
A picture is worth a thousand words.
Congratulations! Now the hard work begins. You’re going to need to start learning how to be a PM. Here is a rough list of skills and traits that you’re going to want to be sure are part of your onboarding plan (if you don’t already have them):
Problem-oriented thinking: You now need to learn to not think in terms of a solution to be built, but a problem to be solved. Let your designer and your engineers design the solution. Your goal is to guide the team to the best solution that can serve as an MLP (minimum lovable product).
Feedback absorption: It’s never personal.
Writing: You will write a lot. Succinct business writing is going to be your friend and will help you get things shipped… use it to your advantage.
OKR creation: OKRs (or BPMs) are the lifeblood of your success as a PM and holding yourself accountable. There are plenty of great resources to learn about these, and
wrote a book on it.
Strong prioritization: You’ll need to learn to define the requirements that matter and what can be cut or de-prioritized for later. Sprint planning will require you to choose which projects and bugs to focus on, requiring you to give good news to some users and customers, and bad news to others. This should come from your CSM experience when you often find yourself deftly navigating a world of escalations.
Data analysis: Learn where your data comes from and how to access it. As of writing this, I’m learning SQL(again) because it’s that impactful and there’s nothing better than being the sovereign of your own data destiny. Good data will make any PRD, vision doc, or research plan that much better.
Building relationships: You now have a new family consisting of an Engineering Manager (EM), engineers, a designer, and others. These folks will rely on you and you will rely on them. Get to know them and build genuine, meaningful relationships. Not only will you be a more effective Product Manager, but you will enjoy your job that much more.
For context, here are the biggest gaps I personally faced in my first few months onboarding to my PM role:
Communication: Learning to artfully support your engineering team and keep them focused on what they do best; orienting them when priorities shift, and keeping outside team members and customers in the loop and satisfied is tough work! Set fair expectations, but do not sandbag.
Planning: Planning for product management is one of the most satisfying parts of the job, but it’s a team effort. Whether it’s sprint planning, quarterly planning, or annual planning, this will take a supportive team, manager, and even PM colleagues to help you get the hang of these processes.
Finding data: Learning where to access, synthesize, and socialize data is not easy - ask many questions and orient yourself to the resources at your disposal. I relied on my product-minded Data Analyst to orient me to how we store data at Segment.
Technical things like infrastructure: this is not easy when you don’t have a computer science/engineering background, but you can learn! Request to see diagrams and ask your EM and engineers what systems do. I’ve asked many, many questions on these products we’ve built.
Remember that this is a journey! It’s not going to be easy, but if you’re passionate about solving problems in your day job, Product might be just the fit you’re looking for career-wise. Moving into product can take time, and it often requires multiple attempts and many interviews to make it happen. Do not be discouraged if you find this to be the case, as you want to be landing in the right role where you’re set up for success. I personally know the feeling of being willing to settle, but don’t do yourself a disservice!
In a nutshell, here is a summary of where to focus your time:
Build relationships
Practice your PM skills on a project (and learn if you truly like it and can see yourself doing this role)
Find a good problem to solve
Hypothesize that problem and the requirements to solve it
Sell it in your interview
Begin your new role and find your own personal learning opportunities for the skills you need to develop
Good luck to you!
Please feel free to reach out to me on LinkedIn or Twitter with any questions or feedback. I’d love to hear from you!
And take a look at the Twilio career page - we’re always hiring, and we can’t wait to see what you build.
Our annual look at how attitudes, preferences, and experiences with personalization have evolved over the past year.