This week we continue our series of interviews with product managers, trying to get at what draws people to the profession and how to excel in it.
Q: How did you become a Product Manager?
A: I started my career as a software engineer and in my last role, I took a five-week break to backpack in central America. While traveling, I had a lot of time to think and came to the conclusion that although I was a good software engineer, I would probably be a better product manager.
This may sound like a very pretentious statement, but looking at our product managers and knowing my skill set, I felt like it was something I could pursue.
Coming back to the office, I discussed the idea with my managers, who were quite surprised, as they didn’t envision this career path for me. It took about a year of nudging with a bit of luck to finally make it happen.
Q: What does product management mean to you?
A: The very first perception I had was that a product manager needed to be the voice of the customer. As I grew in the role, though, I learned that I needed to embrace some other functions as well.
First, that a product manager also has to be the centerpiece of a wheel, where all the spokes connect (I heard that once from a PM at Google).
I really see product management as the powerhouse behind moving every product forward. You need to be a problem solver, even if the problem is outside of your domain expertise.
The most important skills for a product manager to focus on are: Listening, learning, communicating, and executing.
Q: What are the most important things to include in a spec?
A: The most important things to cover are:
- Description of the flow: How is the feature going to be used by users? What are the use cases? What are the extreme use cases? Over the years, I’ve learned that not describing the end-to-end flow is error prone.
- Testable requirements: Adjectives like “large,” “small” and “slow” are subjective, but the code isn’t.
- Functional requirements: This is where you get into the nitty-gritty questions like, “What should the maximum response time be?” “How many transactions per second?” and “What minimal image resolution should we support?” Some PMs might find this boring, but experience has taught me that there are so many pitfalls if you don’t do a thorough job answering these questions.
Your functional spec might describe an amazing product, but if it takes 10 minutes to load then who cares.
Q: What are the most important things to think about when working with engineering?
A: First and foremost, a product manager and their engineering team are all in the same boat. When I took a Scrum course, the trainer’s first lesson mentioned a business fable of “the chicken and the pig.”
It illustrates that a strong, committed team is needed for success, and although the course was a few years ago, the fable still resonates with me.
Additionally, you should share business updates with the engineering team.
Stories of wins and losses, and more importantly, how features developed have helped company business growth are one of the best ways to motivate engineers.
Lastly, because I have a history in engineering, as a product manager, I know how valuable engineers’ feedback can be.
Make sure to tap into their advice to help foster a higher level of commitment from them.
You can reach out and connect with Sagiv on LinkedIn.