In early-stage technology companies, the CEO/Founder is typically the first Product Manager—and the first everything manager—as they hustle to make their vision a reality. They need to build an MVP, secure the first sales and keep those customers happy, position their product in the market, and find a way to fund the company. Figuring out who to hire, for what functions, and when, is understandably a big challenge. As a recruiting firm that specializes in these type of early-stage, high-growth technology companies, we’ve had a front row seat to some of these discussions and challenges, as we’ve helped our clients build the teams they need to drive revenue.
I recently sat down with Lee Garrison, a professional who’s been working in Product for more than 20 years, to talk through the timing of a critical hire—Product Management.
Lee has a background in Product Marketing and Product Management, and currently consults with early-stage tech companies through MaRS, helping them understand the methodologies, best practices, and benefits of implementing Product Management frameworks. Lee shared his insights into the common challenges that Founders face, the symptoms that indicate it’s time for an organization to bring in Product Management or scale their Product Organization.
Sara Saddington, on behalf of Martyn Bassett Associates: Thanks so much for taking the time to speak with me today! As a starting point, can you tell me a bit about yourself and your professional background? How did you get into Product Management?
Lee Garrison: For myself and for many other Product Managers, it was an accidental profession. I don’t come from an Engineering or Computer Science background, but I had a lot of experience with technology, and started working with Software. I originally started with Product Marketing—working with distribution channels. I got into Product Management a bit later, and I’ve been doing that in one form or another for about 20 years now. I’ve been working in B2B software for pretty much my whole career. I’ve been an executive in a number of different capacities, for different types of companies, so I’ve spent a lot of time working on different aspects of Product Management, and mentoring and building teams to do Product Management as a function.
In the last few years I’ve been working with startups through MaRS. I realized that startups are really struggling with Product, because they don’t have the experience of approaching it in a disciplined way, using methodologies and best practices. Product development becomes haphazard: throw stuff at the wall to see if it sticks, hope for the best. Which of course for startups is a huge source of risk.
One of the things we’re doing at MaRS is helping startups understand the best practices and methodologies of Product Management, and to help them reduce the risk of building products that no one wants to buy. We deliver that content through workshops, as well as one on one advising.
I’m very involved in the Product Management community, as well as the Toronto Product Management Association. I think it’s really important to have a community that advocates for the profession, and also nurtures and builds up the next generation of Product Managers. Back when I started in Product Management, it was not a well-known discipline. You talked to different companies and you’d get different answers about what Product Management is, and that’s improved a lot in 20 years. I must say, there’s a much more consistent understanding of the value of Product Management, and how strategic it is now. And as a result, we’ve seen a huge demand for Product Managers and not nearly enough supply.
Sara: For the early-stage startups that you work with, how do you advise them to think about Product Management, especially in cases where the Founder/CEO has taken on that role by default?
Lee: As a starting point, I’d argue that there are a number of skills that are needed in a Founding team—the ability to acquire a deep understanding of the market segment they’re after, the ability to recognize patterns in groups of potential customers, an experimental approach to testing ideas, understanding how to apply technology to solve problems, the ability to continuously adapt to make sure customers are happy, etc. If those skills don’t exist in the Founding team, then I’d suggest that a Product Manager should be the first hire—because otherwise you’ll end up building things without knowing whether or not they’ll work.
On teams where those skills do exist, the Founder is often the first de facto product manager. It makes sense—they have financial constraints when it comes to hiring, they are spending a lot of time with their user base and are closest to potential customers who have the problem the product is trying to solve, and in a small startup team, they’re the ones working with the development team. The challenge is that they usually don’t have experience working in the Product role, so they’re not aware of methodologies and best practices for managing a product.
That said, it’s pretty common for a Founder with those skills to do a reasonable job of figuring out the problem and the market, to create a strong MVP, and start to find Product-Market Fit (PMF), which is the first goal of a startup. Without establishing that fit, you can easily end up trying to scale a product that no one wants to buy.
Once you have PMF established, and you’re confident that you have a product that solves a real problem for your market, the Founder’s job starts to shift toward scaling the company.
This inflection point—approaching PMF—is an important indicator that it’s probably time to hire a Product Manager. You’ve got to divide and conquer between continuing to improve PMF, but also scaling the business and operations. As the Founder/CEO needs to focus more and more on building the company, they end up getting spread too thin—they’re juggling sales, operations, hiring, go-to-market planning, customer satisfaction and product. As a result, product doesn’t get the attention it needs, and this can derail the company.
I’ve seen a lot of Founders/CEOs get into trouble here. They assume that they know the product best—they’re talking to customers everyday and assume they have the best perspective on what customers need. However, this doesn’t usually involve a very methodical approach to collecting and quantifying data or figuring out the real problem, so all of the product development gets based on anecdotal data. In this kind of scenario, it’s common for the CEO to sort of fly into the product meeting and say “I had this great idea last night! We should build this!” And because it comes from the boss, everyone does a 180 and starts building something new. Meanwhile it’s not based on any data.
Another challenge in this kind of scenario is that as the company grows, the CEO/Founder is often pulled into conversations with big clients, or with the most dissatisfied customers. They get called in to close a deal, or to solve a problem with an unhappy customer. As a result, their discussions are sales oriented, not research oriented. Their perceptions get distorted by the people they’re talking to, and they can lose sight of the fact that they’re not really talking to a representative sample of the market.
Sara: What are the symptoms that an organization may experience that indicate it’s time to bring in Product Management?
Lee: There are a number of signs to watch for, and they are largely related to the CEO spreading themselves too thin, and not being able to do justice to the job that needs to be done. Here are the symptoms that I’ve seen in organizations that typically mean it’s time to hire Product Management.
Symptom 1: The CEO is impacting the team’s velocity. By that I mean the team’s ability to experiment, test, and iterate very quickly. Every time the CEO comes in to meet with the team, they need to spend more and more time getting up to speed on the context of the team’s research and decisions. Meetings become about recapping work that was done when the CEO wasn’t in the room, and it slows down the decision making process.
Symptom 2: Because the CEO isn’t keeping up with the context, they will start making decisions based on their gut and opinion, without relying on good data. The anecdotal data they collect from their client meetings (often helping to close big deals, or solve problems for clients who have issues) informs their decisions—not the methodical research that’s been collected by the product team. The team gets frustrated because they know that the CEO’s decisions are arbitrary, and not necessarily worth the investment.
Symptom 3: The Development team doesn’t know what to build next. This happens when the backlog isn’t trimmed or prioritized. Ideally, the backlog will be maintained in a way that makes priorities clear to the development team—when they finish working on one task, they can just go to the backlog and get started on the next thing. If they don’t know what to build, or they start building stuff that isn’t in the backlog, that’s a big symptom that means it’s time to bring in a Product Manager.
Symptom 4: The CEO keeps getting pulled into urgent product meetings, and they’re not spending time on other things that the company needs. Things like hiring, fundraising, sales, etc. are being neglected, and the CEO is working reactively to whatever feels most urgent in the moment, but isn’t necessarily the most important to the long term growth of the company.
Symptom 5: Your investors are insisting. When you start to get PMF and you get a large Seed round or a Series A, your investors will likely tell you “you have to get a Product Manager, because you need to focus on scaling the company.”
So those are the 5 main symptoms that indicate it’s time to hire Product Managers. Interestingly, some of those symptoms are also signs that a product organization needs to be developed. If you have Product Management in place, but you start to see some of these symptoms, take them as a sign that it’s time to expand the team.
At that point, the question that comes up for organizations is “how are we going to scale this team? Are we going to divide it by product areas, by stages in the product process?” There’s a number of ways to approach it. But that’s the question that comes up—“we see that we’re going to need more people, but how are we going to structure it?”
Sara: What recommendations do you offer to organizations who are trying to answer those questions about how to scale their Product team?
Lee: It’s largely contextual, but there are some fundamental principles. One of those is to think about the business objectives first, because whatever happens with product needs to drive those objectives forward.
A lot of times you’ll see product organizations where it’s really hard for an individual contributor Product Manager to see the outcome of their work. It’s difficult when they are creating certain features, or creating the vision or strategy for a product, but don’t have a way to tie that directly to revenue growth, expanding the user base, improving adoption, reducing churn, etc. I’ve found that people are happier and more effective when they have a clear understanding of the way their work impacts the business.
So my approach is usually to start with the business objectives, then work backwards to figure out what jobs need to be done to drive those business objectives, and then you can start to see where the key responsibilities are. From there, it has a lot to do with what particular skills people have, what experience they have, etc. There’s also a big difference in how you’d design a team between a one product company and a portfolio company. So then it becomes much more contextual. I’d say the fundamental principle is “clearly identify the business objectives and then work backwards from that.”
Sara: Do you have any examples of the consequences of not bringing in Product Management soon enough? And how have you helped organizations handle those challenges?
Lee: One example that springs to mind is a client from a few years ago. They were more or less a startup, still searching for PMF, with about 12 or 15 people in the company. They had a bunch of people paying attention to the product and working with the development team, but they were getting completely overwhelmed. Issues were coming in from their early customers—everything from bugs to special requests—as well as new ideas that the sales team were coming up with.
I worked with them to create a system for prioritizing—almost like an emergency room triage. Ideas and requests were coming in like a firehose, and they needed to be able to quickly decide which items would belong in which bucket, which users were worth investing more time on, that kind of thing. We created a set of criteria for validating ideas: how does this impact the customer(s), and would the solution contribute to business objectives? From there we created a fairly repeatable process they could use to quickly assess the issue and say either “that goes into the parking lot,” or, “we need to investigate further and figure out what the solution might look like.”
One of the additional benefits of this triaging was that we could communicate those criteria to the CEO, sales people, support team, and customers, so they learned that they had no business submitting a bug report or a customer request if they couldn’t satisfy those criteria. That actually reduced the noise a lot.
One of the challenges of not bringing in rigorous Product Management practices early is that you end up getting a lot of ideas, bug reports, suggestions for new features, requests for custom builds for big clients, etc. and the team starts going crazy trying to develop solutions and requirements for everything, as opposed to prioritizing very early on. By triaging their issues and implementing some repeatable processes, we were able to get them back on track. That’s a common challenge for early stage companies.
Another example that comes to mind is not having a well defined product process across a team. I’ve seen portfolio companies where they may have had 3 or 4, or 8 or 10 Product Managers responsible for different product lines, but they were not consistent in following a process for discovery, solutioning, experimenting and testing to define what solutions are going to work to achieve those business objectives, and then working with development.
Usually there’s sort of a mildly controlled chaos, each product manager is doing the best that they can, with their understanding and experience of how the process should work. Where it becomes consistent is when they have to work with the development team. Then often times companies will say “Ok, this is how you write requirements, this is how you communicate to the development team.” But the front end of that process is all over the map. Generating that internal consistency is really important, because it ensures that everyone understands the process, and is working together to drive the business forward.
Lastly, the biggest problem I see all the time is that Product people don’t talk to enough customers. They make assumptions with stuff they hear from sales people, or the CEO, or go by their own thoughts and perspectives.
The Pragmatic Institute has a funny old mantra, called NIHITO: Nothing Important Happens in the Office. I’ve been in the VP role managing teams, and it’s really hard to constantly remind product managers, you’ve gotta get out and talk to customers and work the market. Because if you can’t walk a mile in the customer’s shoes, you don’t understand their problem.
Sara: By way of a wrap up — any other advice that you would offer to Founders/CEO who are starting to feel these symptoms? Folks who maybe don't feel totally ready to hand over the reigns of Product, is there any advice that you would give them?
Lee: I think it’s pretty common for the Founder to be uncomfortable handing Product over, but the key thing to recognize is that you’re not abdicating your involvement in Product, you’re moving to be involved in a longer term direction of the Product vision. So you’re moving away from the tactical, but you’re ensuring that there’s alignment across the teams, and that you’re moving towards the long term vision.
This is a challenge for almost every Founder and Entrepreneur. They have to move into a role that has a longer time horizon—and that’s really hard for most of them. They have to get good people around them, spend their time defining the vision, and then let those people make the individual decisions and run the day to day stuff. So set the business objectives and the vision, and then let the team work at achieving that.
And you see that all the time in a lot of companies of all sizes. That there’s lip service paid to business objectives, but they’re not very clear to most of the rank and file. Creating that clarity should be the focus of the CEO/Founder, but it’s difficult, and people can get tripped up in a number of ways.
* Interview has been edited for length and clarity.
