For this iteration of Under the Arc, our co-founder and Managing Director, Daniel Eisen, sat down with Marco Matos, currently a Product Leader at Pinterest. Marco’s had a successful career as a product leader, with key roles at Microsoft, Google and a start-up that was eventually sold to Walmart Labs. He posesses particular expertise building products that turn massive amounts of user behaviour data into meaningful business outcomes for customers.
Our discussion with Marco was wide-ranging, touching on the basic principles of the product management role, and how to conceptualize data as an asset for a business and team building.
The Product Manager role is well understood in large tech companies. Many businesses of the scale that we engage with at Arcadea don’t have the role today and may not even be familiar with what the role entails. How do you define what a PM is?
There’s a story from Microsoft, I don’t know how true it is, but the concept was, Product Managers were invented to help engineers keep their hands on the keyboard. Engineers wrote code; it wasn’t their job to figure out how the code came together to produce a solution for a discrete customer problem. That was essentially the birth of the PM role. I’m not dogmatic about the specifics of a PM role; ultimately the job is to think about who the customer is and what is the problem they are hiring you to solve, and to make sure your product is solving that problem.
Based on that definition, many small software companies have the PM function filled by the CEO or someone from the Engineering team who is thinking about product on a part-time basis, off the side of their desk. What can change in an organization once you have someone dedicated to that role on a full-time basis?
The two areas I would call out are focus and consistency. If someone is only thinking about product on a part-time basis, you can end up changing course constantly and lose sight of what you are trying to build over the long-term. You can become very reactive to customer feedback, just hearing the loudest voice and responding to those needs. Someone who’s dedicated to the role can think about solving problems for key customers and asking how we ensure our product fits their needs over the next six and twelve, months as well as the next five to ten years. Making sure you are constantly thinking about product-market fit and staying focused on solving problems for your core market as you scale. My favourite analogy for this concept is, if Henry Ford asked people what he should build they would have told him ‘a faster horse’. The job of a PM is not to build a faster horse, but to build a car.
The concept of focus is so important to scaling a business. Going from the proverbial ‘zero to one’ in tight vertical markets by solving a core problem in niche vertical markets can get a business up to say three or four million in revenue, but going from that point to a ten million dollar business that is going to dominate a market segment is where you need much more focus to ensure you are solving your customer problems in a very organized and value-added manner, versus doing it piecemeal.
As your product grows in complexity and there are tons of components that need to fit together, you need to ensure that you’re not shipping a bunch of code to a customer, you are actually shipping an end to end solution. Somebody has to care about the customer experience from a to z, and you need a dedicated person that is accountable for that concept.
Your focus as a product leader has been around user behaviour, engaging large and active audiences, and using data to drive revenue. Vertical SaaS businesses by their nature have smaller user bases, but functionality of the products can produce quite a lot of data. We hear often from CEO’s about the vast potential to generate value from all that data, but at times it can seem like there is a variable missing in the ‘Data + X = Profit’ equation. How do you look at data and identify whether there is something to be done that can produce a meaningful business outcome?
There’s been quite a lot of that with the data gold rush that we’ve seen over the last five to ten years. It’s all about the collection of data, but I think some companies get lost on how to actually apply it. They just make the assumption that it’s valuable, but actually monetizing it is a different story. If you take a step back, you have to always consider what’s the value you are generating for your customer – what is the problem your customer is hiring you to solve. From that perspective, you see that your data is an asset and not an actual solution. You have to apply that asset in a differentiated way to then build a solution – either allowing your customer to generate more value in their business or solve one of their business problems. I tend to never lead with data. It’s too easy to just say, hey let’s just collect all this stuff and then we’ll have a great business. That’s not actually true. You need to have a hypothesis about what data can do, then start to collect the data to power that hypothesis, then push out to customers to get some insights into whether they actually need that data. The assumption here is that the value exchange between you and the customer enables you to return incremental value to them based on that data.
Moving over to the topic of team building. You’ve worked with large teams through you career, including being the starting point for what subsequently become a large team. What are the key things you consider as you start to build out a team?
A really important principle when you start a team, and using product teams as an example, is being clear on what do I have as an organization and where do I want to go. In a large company you can be really specific with very focused roles versus on a team where in a smaller company you need people who can be way more of a generalist but have the ability to dive deeply at certain points. In a product team, I think about the first couple of hires as being the base line of a product organization and building diversity from around competencies like customer centricity and technical expertise. You also need to keep in mind that in large companies it’s very difficult for individuals to fail and it’s very difficult for smaller companies to get big. So you need the right personality and mindset when you are hiring in a smaller organization, people who are willing to roll up their sleeves with low ego and can wear a lot of hats. Those are the types of folks you want in the early days of building a team.
Once you’ve got the team in place, how do you think about talent development, retention and growth opportunities?
My management and hiring philosophy is to hire smart people and get out of the way to let them be smart. Those sorts of people want to learn and see growth. Your job as a functional leader is to figure out where the gaps are in a team that is impeding efficiency and make sure the process is there to allow people to execute quickly and efficiency which leads to wins, learnings and growth. With larger companies you might be shipping product once every six months, but with smaller companies you get a lot of quick twitch movement where you can see the growth and iteration which can present a lot of learning opportunities. For product managers, getting exposure to customer research, sales and marketing, engineering and so on, the diversity of experience, which yield really interest growth opportunity for smart people.
A business that has found that product-market fit and achieved sufficient scale to operate profitably, growing at 20%+ a year will eventually need to expand their teams beyond a founding group or a group of long-term employees. Do you have any best or worst practices for organizations that are ready to grow from the first 20 or 30 people towards the next 20 or 30?
A key at that scale is to be really clear on what business needs you have that are driving that growth and be focused on hiring to fill exactly that need. For example, is the growth going to come from increasing output from our dev organization to provide more product functionality or adding more customers that needs to come from a bigger sales team. At that scale, when you are thinking about leadership positions, every person you add to a team needs to level up the business. These aren’t incremental hires, so be clear about what you need to see out of a person that really going to excel the business.
Do you think a company can scale indefinitely with generalists or people wearing multiple hats? We hear a lot from folks who are having a hard time finding someone to fill say a support seat because they also have to do implementations and some account management. So, they are always looking for the perfect person. You may be able to find one or two in that mold but finding they next four can be hard.
I am a bit biased because PM’s are not born experts, you don’t go to school to learn how to be a PM, you learn by getting into the trade and then you figure it out along the way. So from a PM perspective, the generalist concept can work as long as you have the basic ingredients of being able to learn and being able to get things done. The actual tools aren’t difficult, anybody can learn them. So I push back on the idea of needing the constant stream of experts. I think you need to have some experts in the building to train other folks on what excellence looks like. But you can surround those folks with good people with general curiosity and I think a lot of what is required can be learned now along the way.
What will happen is that individuals will gravitate to what they like to go do, some might decide to specialize after a year or they might decide to stay in a more generalist role. If you hire somebody at day zero, their job and function may look a lot different along the way. Sometimes it’s better to keep them in one place and sometimes it’s better to have them learn another part of the business so you don’t have a single point of failure. Cross sharing and cross learning across the organization can be how it becomes self sustaining and more of a living organism as it grows.
Most of your professional experience has been in businesses that are already at scale, but you’ve personally had success generating pretty material incremental commercial outcomes in that context. Do you have any best practices or mental models that you bring to a new opportunity where it can otherwise seem like all the hard problems are already solved or the only contributions aren’t going to be meaningful to the larger organization?
I feel like I’ve bene doing that for sixteen years, and I think that one, I’m just a generally curious person. I would also push back on the premise that big companies have no more problems to solve. Every company wants to become a generational company. I went from Microsoft to Google to Facebook, then a start-up, and every company wanted to be the next biggest company. So Google trying to become Microsoft and Facebook trying to become google in terms of scale of their businesses. In these large companies there are just different problems and opportunities. It’s all about bringing a new lens to the problems at hand. Take your lessons learned elsewhere an apply that to your current situation and think about how you can add to the playbook.
One of the biggest mistakes I always hear from hires in big tech is to say ‘here’s what we did at Amazon, here’s what we did at Google, here’s what we did at Facebook’. That’s all irrelevant because you’re not at that company any longer and you don’t have the same resources or product or balance sheet. Bring your experiences, which are valuable, but apply them with a curious mindset to what’s new and different. I will promise you no matter how similar the companies look on the outside, when you get in they are vastly different. There are lots of things successful companies do well but there are always lots of things to go figure out and that’s what gets me up in the morning.
That’s such a great perspective and refreshing for folks to hear that a billion-dollar revenue business wants to become the ten billion revenue business, as so on. Translating that back to a typical Arcadea business, where the TAM isn’t a trillion dollars, you may have a seven-million-dollar business today serving as a core system of record in a tight market but that doesn’t mean that you’ve come anywhere close to solving all the other hard problems in your space. It’s interesting to hear that folks coming from big tech leaders aren’t always able to channel their direct learnings to new organizations, but are there any key principles from those massively successful organizations that you think can translate elsewhere?
I think there are some principles and lessons to be learned around the product development process. Number one is being very mission focused. When you go to Facebook or Pinterest or Google, everybody knows the mission. I find that to be immensely powerful because it helps different organizations and individuals stay very much on task about what they want to be and not trying to be a thousand different things. It’s really helpful so that whenever you do something you know why you are doing it, it’s how you break ties when you have disagreements. It’s also important for growing organizations so that as you add new people you have this commonality of language and of thought and principles that keeps everyone on the same page.
The other piece is to be judicious with how you’re approaching whatever it is you’re approaching. Small companies always feel in a huge rush to get ‘there’ yesterday, wherever ‘there’ is. You have to be methodical in what you’re doing because everything can be a distraction. If you remind yourself that when you’re building a small company it can be pretty bumpy along the way. Comparing a big company to small company is a lot like a jumbo jet to a small plane. Jets fly super high and they can easily get through turbulence but if you’re in a small plane you feel all the bumps along the way and it’s going to take you longer to get to where you are going. As long as you have the right team and the right focus you can get to where you’re going. Every big company today was once a small company.