In early-stage technology companies, the CEO/Founder is typically the first Product Manager—the first everything manager really—as they hustle to make their vision a reality. But as the company grows, the product evolves and challenges scaling the business inevitably arise, product management and hiring the right product people becomes a cornerstone to success.  

Martyn Bassett Associates recently sat down with Lee Garrison to get insights into the common challenges early-stage startups face and the signs that indicate it’s time for the organization to bring in product management to scale their product team. 

Martyn Bassett Associates: Let’s start with a brief introduction of your background and how you got started in product. 

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 in Product Marketing, working with distribution channels. I got into Product Management a bit later, and I’ve been doing product in one form or another for about 20 years. 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 while also 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, and 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. If you talked to different companies you would get different answers about what Product Management is. That has 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. 

Martyn Bassett Associates: For the early-stage startups you've worked with, how did you advise them to think about product management, especially in cases where the Founder/CEO took 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, otherwise, they could 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 as 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 PMF is established, and there’s confidence that the product solves a real problem for a specific 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. The founding team has to divide and conquer between continuing to improve PMF, while 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 since they’re talking to customers every day 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 that 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. 

 
‍Martyn Bassett Associates: What are the signs in an organization 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 five most common signs 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 dev 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 at the moment but isn’t necessarily the most important to the long-term growth of the company. 

Symptom 5: Investors are insisting. Once PMF is established and there’s a Seed round or a Series A, investors will likely tell a CEO to get a Product Manager, because they need to focus on scaling the company. 

So those are the 5 main signs that indicate a startup is ready to hire Product Managers. Interestingly, some of those symptoms are also signs that a product organization needs to be developed. If Product Management is in place, but these symptoms are still present, 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 are 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?”

 
‍Martyn Bassett Associates: 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. The first step is to think about the business objectives first, because whatever happens with the product, it 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 for a company with one product vs a company with a suite of products. 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.”

 
‍Martyn Bassett Associates: 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 was 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, salespeople, 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 reduced the noise a lot. 

One of the challenges of not bringing in rigorous product management practices early is that a startup can 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 oftentimes companies will say “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 salespeople, 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.

Martyn Bassett Associates: Thank you Lee for your valuable insights. The jump from a Founder-led MVP to an organization with dedicated product hires and solid product management best practices can be a rocky one, but for those willing to take on the task, the rewards and learnings will be invaluable.