“Seeing the reactions from the product’s users is worth the hard work.”

Click Here For More 20MinuteLeaders

Omer, tell me about yourself.

I've been doing product management for over 10 years now. I began as a software engineer and team lead. I pivoted to product in 2010 when I was an entrepreneur in a company. One of my partners took the role of the CTO, so I had to move to the business side. I had to become a product manager very quickly, very aggressively.

What was that change in mindset like?

Instead of thinking of how we are going to solve the problem, I had to change my perspective to: Are we solving the right problem? Actually defining the pain of the customer.

What have you learned about identifying the pains of customers?

My entire career, I was working in B2B companies. When I'm talking about customer pain, it's usually a business partner’s pain. I learned that it's difficult to imagine the exact problem of your customer without feeling it yourself. It's very difficult to sit and build a solution in your labs without being outside in the field.

Omer Efrat, VP of product at Torq. Photo: Torq

What’s an example of being out there with a company and identifying the pain point that then translated into a good product?

At AppsFlyer, we were trying to build something quite different. The goal was to understand exactly how the media buyer or the user acquisition managers are facing the challenge of managing their campaigns. We really needed to reach out to very specific personas in our customers’ organizations and look very deeply to understand what the process looks like.

Do you do that simply through talking to them?

One of the ways I personally experienced those pains for this example was when I actually had to sit in the seat of the user acquisition manager for some of those same clients. I actually experienced it myself. So later, when I sat again with them, I could ask those questions from a very knowledgeable position. They could actually open up very quickly and share very deep insights about their pains.

How do you then structure your organization so that you can develop the right product?

You got the problem right: this is like the first stage. Now, the question is how you build a vision around it. Before you put together the team, you need to have a vision that relates to a strategy. You see many product managers struggling to find a vision around that problem. The problem can be solved in some kind of a hack, or you can solve it with a more holistic and exhaustive solution.

This, in my three last roles, was the main challenge. We need to put together a vision that will solve it altogether, which sometimes organizational-wise can be challenging. Not everyone in the organization is happy to put huge amounts of budgets on setting up new visions.

You basically have to sell everybody on the conviction that you've had by understanding the pain point. Right?

Yes. You need to show the size of the problem, which means the size of the opportunity. This is a very common mistake: that people find a very good problem, but it's not big enough. It's not good if you want to build a huge product or a huge company around it. If you're looking to get past unicorn stage, you need to solve really big problems. If you prove that it's very big and it's very clear, convincing everyone within the company is much easier.

Once you've done that, what’s next?

Now we need to get the organization or the product org that is connected to an engineering org. The question is, how many product managers do you need for a certain project, product, or company?

In my experience from Israeli companies the past 15 years, it was very common to think of how many product managers you need per how many engineers. You used to say, "You need a PM for every six or eight engineers." But today we see a completely different trend. The amount of PM is derived from the size of the problem you need to solve.

One problem has many different subproblems. Each one of the subproblems requires someone to really look deep and research and investigate and think exactly how you cut it narrow enough to give it a great execution. The number of PMs today is equivalent to the numbers of issues I'm trying to solve. Even if you have a team of 20 engineers, sometimes we still need seven or eight PMs.

Once the engineering teams are working on the product, what do the PMs do?

I'll answer it from another perspective of the different types of PMs that used to be common. They used to have technical PMs, inbound PMs that mostly worked with the engineering team. The outbound PMs would be more outfacing, talking more to customers, and doing more support and whatever with the market.

Today there is a trend that I really believe in of using "full stack product managers," which means that a PM needs to be inbound and outbound. They need to have the expertise of going down technically with the engineering team when needed but also join a sales call and steal the show when needed. I expect the same person to do both things at a very high rate.

Now, because we did it vertically, I can break down the product to many features that each have their own market research, execution, and plan. That subproduct is being managed by a single person. That is the owner of that capability. It's full stack in a limited scope.

We have a product. What's happening now from the lenses of the PM?

Let's try to break down the day of PM at Torq. We have two resolutions of planning. First, we have the quarterly plan that we do at the strategic level. We have the business goals of the quarter. We break down the features or important capabilities that we think we need in order to reach those goals three months from now.

Once we define what we're going to work on, then we break it down with the engineer. Now we have a product manager that is leading this. We need to align client views. We need to add some marketing around it. All of those capabilities—from talking to engineers and getting a very good design to how are we going to build it, to training the business side to sell that feature and to make sure users are using that feature—is on that product manager that is now leading that product capability.

Every day, that product manager is thinking, "How am I pushing this product capability? Where does it stand now? What are the blockers?" That's the day-to-day work of the PMs. The sprint is something that the engineers are doing in order to manage their work efficiently. We are helping them, but we are not owning the sprint.

What is it about product management that you really love?

I love solving problems. Solving problems was the reason I became an engineer. Eventually, when you want to find bigger problems and lead the solution on a larger scale, that product manager role gives you something completely bigger. Seeing the reactions from the users when you’re delivering a product is worth all of the hard work.

If you choose a few words to describe yourself, what words come to mind?

One thing that I can compliment myself about is that in many cases, I came with product visions that people did not believe were possible. And delivered, eventually.

Michael Matias. Photo: Courtesy