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: What did you do before becoming a Product Manager?
A: I started my career as a software engineer in a small startup and after a couple of years advanced to a team lead role. As the technology evolved, I helped the PM team write specs for cross-system features.
After a few years, I joined another small startup, and since there were only five of us, I went back to programming. Each of us was taking on additional responsibilities as well, related to his or her skills because there was no one else to do the job.
I defined external APIs, designed graphical user interfaces, set up physical systems for delivery, managed customer projects, created the system’s first technical manual and even delivered an internal recruitment workshop when we started expanding.
Q: How did you become a Product Manager?
A: Whatever it was that I did, I was always looking for the broader system view and for the customer’s view. It was only a few years ago when I joined a larger company that I learned the true discipline of product management.
Q: What does product management mean to you and what are the most important things to do?
A: When I was a child, someone once told me that the greatest inventions are driven by real problems. Product management to me is about identifying problems / needs and then solving them!
It’s also a way to influence–how customers use Outbrain’s service and the way our product is perceived and accepted. Driving people across the globe to use Outbrain’s service is a lot of responsibility!
Product management is a complex discipline that requires knowledge of the market, vision, management and execution skills.
I often think back to a slide template that a colleague shared with me when I was first getting into product management. I use it whenever I’m considering a new feature since it forces me to justify the feature and clearly describe the problem that I’m trying to solve.
If I can’t justify the feature, then it probably isn’t worth the investment.
Q: What do you like most about your job?
A: What I like most about my job is its diversity. Market research, competitive analysis, customer meetings, visioning, user experience, designing and developing, project planning, marketing, and sales.
It puts me in contact with customers, as well as stakeholders inside the company and external providers.
There’s never a dull moment.
I also like that I’m serving two types of users: Outbrain’s customers on one hand, and internal users on the other, including departments in our own organization such as finance, support, account strategists and content reviewers.
Therefore, when introducing a new feature, many times the challenge is twofold–you need to think about how the customer will use the feature, but also how internal teams will be impacted.
Q: What are the most important things to include in a spec?
A: Writing a good spec is almost a work of art. It has to be short and it has to be clear! It needs to satisfy both business stakeholders and technical stakeholders that review and approve it.
Whereas the functional requirements are the main dish of the meal, there are other plates I would never omit:
Background: where you describe the current situation and problem, as well as set the scene and provide context. It will help your readers,
especially the development team, understand the rationale behind your requirements.
User stories and business flows: user stories describe the problem and solution from the customer’s point of view. They clearly define the user
(who), the capability (what), and the reason (why). Business flows describe operations related to the new feature.
KPIs: this is how you’re going to measure the success or failure of the feature.
There’s one more important point to mention about specs…
I’ve seen product managers fail to separate assumptions from requirements regarding the solution. They fail to see the customer’s need because their thoughts are limited by the solutions design and technical constraints.
It’s important to differentiate between requirements and solutions by asking two questions:
What does the customer need? — These are requirements.
How will I meet the customer need? — This is the solution or design.
For example, specifying that a service will be blocked if the customer doesn’t pay is a requirement. Whereas specifying that the billing system will trigger the API to disable the service is a design decision.
That, you’d better leave to the engineering team since they might think that running a batch process every half hour to disable the service for non-paying customers is simpler.
You can reach out and connect to Osnat on LinkedIn.
If you have questions you’d like me to ask in an upcoming interview, please leave them in the comments.