Season 3 - Episode 3

Aligning Product Management Efforts

Matin Movassate the CEO and Co-founder of Heap, a company that automates customer analytics for some of the largest online businesses in the world. He talks us through his journey of entrepreneurship and product management as well as touching on important points such as skills, growth, and vision.

Watch the episode here: Aligning Product Management Efforts

“Question [00:02:28] Can you tell us a more about yourself and how you got into Product Management?”

Matin [2:33] I’ve been doing product stuff for about 10 years now, before doing product, I was an engineer for a while and after doing engineering work, I wanted to try something a little bit different and I felt like product management was a good intersection with technology. It’s a different type of thing and I didn’t need to wear a suit to interview for those roles.

My first and my only full-time product management job was at Facebook where I was deeply excited about this idea of using data and truth to drive product decision making is actually a pretty new thing. If you think about it, products largely did not exist online in a digital form in a way that was measurable until fairly recently.

I thought that was really interesting from the perspective of making product decisions and figuring out where to drive impact. Then I saw Facebook is very much the Paragon of that ideal. It turns out in practice, analytics is not quite that simple. That led me and my Co-Founder to start Heap and try to make product analytics less of a mess.

“Question [00:0421] What was that moment where you were like: “Okay this is hard enough, this doesn’t work for me. I need to build my own product””

Matin [04:29] When I was at Facebook, I was able to take advantage of their very sophisticated analytics infrastructure to ask questions about the product, understand whether we were building the right things, whether we were moving the needle on the business. But what I found was that it was surprisingly difficult to actually make use of that fancy analytics infrastructure as a mere PM.

Every time I would have a question, even a question, as basic as who are the people that are using this feature? Or how does this feature impact retention? Just answering a question like that required me to go bother a developer to write a tracking code for me. I don’t know if there are any developers in the audience, but I can tell you, they don’t particularly enjoy writing analytics tracking code. That’s not why they got into the job. I have to wait for that engineer to get around to writr that code.

I need to wait for that tracking code to go through a release cycle pain, to wait for data, to come in. Once the data’s in, I need to loop in an analyst and the data scientists, etc… So long story short, by the time I get the answer to my question, literally months would go by and I needed to loop in three different people.

The realization we had is that there’s no way we can evolve the practice of product management if it’s this difficult to get to product insight. We started heap with this idea of trying to automate as much of those annoying parts as possible and bring product insights to more people more effortlessly.

“Question [00:07:44] Why do you think there are so many product managers these days that are considering to become CEOs and build their own products? What are the overlapping skills?”

Miten [00:07:53] I’ll answer your question by actually describing some of the differences. Cause I think that’s important. I’ve always hated the designation, that PM is the CEO of the product. What I learned after being a CEO was that I actually had to unlearn a lot of my skills as a PM within a big company. When becoming a Founder and CEO, it’s actually quite astonishing, the levels of difference between the two roles.

Within a big company, let’s say you have over 200 or 300 people, a lot more of the bottleneck to success, to customer value, to building a good product. The bigger bottleneck is internal alignment, not necessarily finding market demand, whereas, within a small company, it’s all about figuring out that market demand and figuring out that product-market fit. Nobody cares about your ability to outline a bold vision internally, you need to be really good at understanding customer pain.

I would say the PM role is very different between a small company and a big company. I would also say the CEO role also varies a lot when you’re at a small stage, it is closer to a product management role, but as you scale, it’s a completely different becomes a completely different job. One or two of the key differences is one that PM’s, don’t have to think about resourcing.

Whereas that is the primary job that a CEO has building an executive team hires, ensuring a strong culture on ensuring alignment of mission and values that are different than, than shepherding product-market fit. I think one key difference is that PM’s don’t have authority, whereas CEOs do. That is an important distinction because sometimes the CEO does need to push a decision through swiftly in a way that a PM can’t.

However, I do think one big similarity is the leadership qualities of a good PM, I think are shared with the just good leadership qualities of a CEO or really any leader within a company, not leadership quality is aligning people on shared truth. Ideally, as a leader, you’re not getting people to do things because you told them to do so. You’re trying to lay out the problem, the opportunity, give people the context so that they can be empowered to make decisions themselves. That’s exactly the mandate of a PM.

“Question [00:10:46] What are some of these biggest misconceptions with product analytics these days?”

Matin [10:52] I would say the biggest misconception is that analytics is about insights and reporting. Whereas, what we’ve observed with our customers in the broader market is that the hardest part of analytics is the data piece. Not necessarily the analytics that they’re reporting, but the actual mundane tasks of collecting the data, organizing the data, making sure it’s trustworthy, and making sure it’s discoverable for everybody within your organization.

Those are the things that actually we’ve observed. Keep people from being able to get valuable product insights. It’s a big shame because I think analytics, in particular, it’s very easy to see demos that pitch you on fancy visualizations, AI-driven insights, all of these really exciting things that you think you can put into practice, show your boss, show your engineers to make yourself look good as a PM.

However, in practice, what you’re going to end up wasting your time doing is figuring out is why do I have two events, both named signup? What’s the difference between them? Why didn’t we track three of the events within this onboarding flow?

This is where a lot of people get stuck with product analytics. That is one of the things I always encourage people to keep in mind is to make sure you have a solid strategy around the data piece because nothing else matters if you don’t.

“Question [00:12:28] How have you been able to personally learn and grow so you can continue empowering others to do the same?”

Matin [12:39] I think about this a lot. I do know that fundamentally that no individual can grow as quickly as an aggregate team of people, especially as the team gets bigger. That Delta between what you can do as an individual and what the organization can do only increases as that company scales.

The only way I can really keep up is to make sure that the team is doing well in aggregate. So really what I need to be able to be good at as a CEO is to be really good at hiring great talent and to be able to be really good at aligning people on a shared mission, shared purpose and shared values.

I spend a lot of my time understanding what great talent looks like, how they work, how great talent works together. These are the things I try to be really good at, but it’s not necessarily product management skills anymore. It’s not necessarily marketing skills anymore. It’s talent, it’s hiring an alignment.

That’s where I think I can provide the most leverage to Heap based on where we’re at now. At the end of the day, I think that that means I talk less. I listen a lot more. I trust the people around me and I try to assume good intent and capabilities and all of them.

“Question [00:15:06] Do you still voice your opinion as a leader? How do you make sure that the PMs who are shaping that vision feel empowered to make decisions?”

Miten [15:20] That’s a very good question. I don’t know that I’ve figured out the perfect balance, but I’ll tell you what we try to do at Heap. We’re at the scale now where we’re making a few different products at once. So what I try to do is work with our leadership team and be really crisp about how our vision breaks down into concrete outcomes and areas of effort.

The more you can make that really clear, and the more you can align people on your team to those specific submissions or goals, then the less you need to decide things for them. All we really need to do as leaders is just align on the high-level goals and the high-level problems. If we can be really good at what we’re trying to do and why and the context around it, then I shouldn’t be making these decisions, these decisions at the individual product level, nor should any other, anyone else at the leadership level at Heap.

I don’t think necessarily product managers should decide what gets built next. I’ve talked to a number of companies that have different perspectives on this, but I actually have a potentially controversial point of view that I think ultimately engineers should decide what to build next. They end up deciding what gets built next anyways.

Ultimately it is the job of PMs and leaders to be able to give engineers the right context so that we can make sure they’re building the right things that actually move the needle of the business. That to me is a whole other fascinating concept. I think the net of it is that we want to set good high-level goals, good high-level context, and then empower everybody to make decisions within that context.