Want to build a great product team? There's no one formula.
It's been a long time since I've written about hiring on this blog. So when someone asked the question about growing and building a great product team, I thought it was time to tackle it. When it comes to building a great product team, the first thing I'd tell you is that everything depends. There's no single formula. And the reason for that is simple.
Everything depends on where you're at in the lifecycle of your business.
If you're just getting started, you're likely the “CEO” of your product. Hiring a product manager is going to be frustrating for both you and them.
If you're trying to find product-market fit, you likely need someone who is great talking to prospects, partners, and people who are cancelling.
If you're in the scaling phase, you may need someone with proven ideas around promotion.
That's why giving opinions on how to structure and build a great product team is something I only do after asking a lot of questions. At that point, I feel like I know enough to make some suggestions.
But I should highlight one other dynamic before we get into any frameworks or suggestions. It's simply and yet we all forget it way too quickly and too often.
Our product team is filled with people. Not roles or job descriptions.
Even when I've hired two product managers with the same title, I've never hired two identical people who approach the work identically. And that can sometimes be shocking to them or the people around them.
But I hire people. I hire their experience. And sure I hire their skill. But I also hire their personalities because I know that will drive them in certain directions that others, with different personalities, may not go.
Roles I need in my product team
I'm not going to tell you how you should structure your team. Instead, I'm going to let you in on how I think about building my (software) product team. Sound good? Let's get into it.
- A numbers person
- An operations person
- A partnerships person
- An experiments person
- A builder
- A domain expert / storyteller*
I'm not going to tell you the order you need to hire these folks. In the different startups I've run, it's not always been the exact same order. But in my opinion, they're all essential when building a great product team.
A Numbers Person
Whether you're in the early parts of your product business or not, you're going to need to know what it costs to produce and release your product. That's your Cost of Goods Sold (COGS). That's going to calculations. And it likely changes as things in your business change.
Also, you're going to create models of where you think you're going to be in 6 months, or 12 months. Someone has to be good in Excel to create models (especially if you're going to create different scenarios). That's a numbers person.
You're likely going to need to capture how things are going against plan. That's a regular collection of data from other tools or other parts of your organization (depending on your size). More numbers.
In the end, if you're not great with numbers, make sure you hire a numbers person. I've hired this person with an “analyst” title, and other times with a “product manager” title. By now you'll have figured out I care a lot less about titles and a lot more about the team I'm assembling.
Now, to be clear, there are some numbers people that I would characterize as flexible. They're able to think about the numbers as part of a narrative, and can go looking for additional data to help us tell the story we're trying to share. Other numbers people are more rigid. They can't tell me a story because that's not what they're about. The numbers say one and only one thing.
I hire the first kind of numbers person. That's just me.
An Operations Person
Another way to describe this person is my “glue” person. They can work under a lot of titles (“product operations, product manager, etc.”). But what they do is connect the dots between all the different parts of your organization.
I don't believe in the “the product manager is the CEO of your product.” I've heard it a million times but rarely seen it work. Unless we're talking about a really weak CEO, or a really weak organization.
What that means is that your product team will exist at the intersection of engineering/development, infrastructure/hosting, support & customer service, sales, and marketing.
If you don't have a person who is comfortable talking to each of these groups and helping everyone get on the same page, your product team will struggle.
Another angle on this role is that, for me, they often have to bring a healthy amount of negotiating experience to the role. Their world will be filled with trade-off decisions across teams. It's a natural part of the work.
When I hired Jessica Frick as a product manager, I was hiring for this spot. Like I said the other day.
A Partnerships Person
Some people will call this a “community” role, or an “evangelist” role if they're partnering with the development community. Others will define the role as a marketing or sales-like role within the product team, who is focused on creating mutually beneficial partnerships between others who can distribute your product.
Whatever you call it, this is often one of the first roles I hire. Even if I'm good at this. Even if I have a lot of relationships. Why? Because this takes time and effort. It's not something you squeeze in, as an afterthought.
When I first joined Liquid Web, one of my first hires was Lindsey Miller to be my partnerships person in the WordPress community. I needed someone focused on connecting with people, agencies, product companies, and more – even if I was busy in meetings.
Lindsey knew the WordPress ecosystem. That's for sure. But she also had been a professional fundraiser in state politics. She knows how to network. That's what this role is all about.
An Experiments Person
I find this is the role that most people don't get. I don't know if I can effectively explain this if you've never experienced what this person can do for your product team.
There are people out there that are very good at telling you what is possible and what is not. I see these people get hired all the time. They get hired because they're clearly skilled and have a long track record of making things happen.
But sometimes what they're really good at is doing the same thing, year after year. Sure they learn a bit here and there. I'm not saying they don't learn. I'm not trying to say anything about them that's negative.
I'm simply highlighting that when you're building a great product team, you need more than the people who are able to tell you why something can't be done. You need the people who say things like, “let me go see if I can make that work.”
Want to know if you can connect one system to another (even though no one has done it before)? This is the person on the product team that is going to go figure it out.
Want to know if you can create a different kind of affiliate program onboarding than what the company offers as the default? This is the person on the product team that is going to figure it out.
They don't mind risk. They don't mind failure. They don't mind “wasting” time. Because they see the work thru a different lens.
And for me, it's a key role in building a great product team.
In a lot of the companies that I help, advice or coach, the founder is a builder. So they do the builder work. Forever. Often past when it makes sense.
What do I mean by that?
If the founder or leader of a product is focused on all the builder activities, they'll likely struggle to focus on the work they need to do to be successful. And contrary to popular belief, a great product isn't the only thing you need to be successful.
[Tweet “Contrary to popular belief, a great product isn't the only thing you need to be successful.”]
If you want to build a great product team, you're likely going to need to add a builder so that you can start articulating your decisions, share your thinking, and explain your logic out loud. It does wonders to help everyone see where there are refactoring opportunities.
And it gives you free time to work on those other tasks you'll need.
A Domain Expert / Storyteller*
If you don't know me, I'm super opinionated. That means you may or may not agree with my take, and I'm totally ok with that. The reason I have that asterisk (*) next to this role is because I never hire for this role. It's my seat at the table.
I sit in that role because I believe that domain expertise is more critical than any other role. It's where vision comes from. And I didn't suggest you needed a visionary, because I only want vision on a product team from domain experts, not purely “big picture” people.
I also firmly believe that the best products embed the pain/gain parts of the customer story into the product. So again, I want a domain expert to also be a storyteller.
Again, you may disagree. But I'm not a fan of building a product before I develop domain expertise. I find that the cost of finding product-market fit without domain expertise is too costly for my taste. But that's just me.
What about Pre-Sales & Support?
When it comes to how to structure and build a great product team, I build these organizations last. Why? Because at the start, and until we really hit the growth stage, I want every one of the people I've already hired to sit in those roles.
Everyone is in pre-sales. Everyone is in support.
Because whether we're good at it or not, it's where you get the feedback that helps your product team really understand what the market is saying about you.