Building teams, part four: expanding to product orgs and choosing between domain experts or skilled PMs.
Getting contribution and collaboration from unexpected places.
Building product organizations with domain experts and skilled product managers.
This article is the fourth in a series about hiring and building product teams.
The first article is about building well-rounded teams, avoiding super chickens, and what I consider the most important interview question: “Tell me one thing you are really good at but hate doing and would be a happier person if you never had to do that thing again.”
In the second article, I introduced the product manager programming test, an excellent tool for learning about a candidate’s mindset and observing how they collaborate while using product management skills.
The third part of the series concentrated on building diverse teams and how they make your product organization more successful and your company more profitable.
Now, we focus on building product organizations, making impactful product management hires, and whether to focus on PMs with excellent product management skills or specific domain expertise.
Your product team is actually the foundation of a broader product organization.
Product management is a strategic function for successful companies. The scope is broader than before, especially considering how different teams contribute to the product's lifecycle. Expand the definition of the product team and instead call it a product organization. The product management team–product managers/owners, TPMs, UX designers, user experience, and tech writers–forms the foundation of that product organization.
I advocate for this expanded definition because no single group delivers everything you’ll need for the product’s entire lifecycle. Break down that full lifecycle into phases and map functional groups into those phases based on what you need them to deliver. Phases vary by product but generally include product design and development, software delivery, go-to-market, and post-sales.
The product design and development phase is when the product organization must identify the ideal customer profile, execute user experience and product design, gather requirements, define backlogs, analyze early prototypes, conduct voice-of-the-customer interviews, do product enablement and train internal teams, and build the product’s information architecture and flesh out the technical documentation. The functions contributing to these outcomes include strategic product management, technical product management, UX designers, the office of the CTO, presales engineers, and customer success.
The software delivery phase is when you develop and ship software. Your engineering team is writing and delivering code, TPMs are running the agile process, project and program management–especially in larger organizations–and product operations keep alignment across groups.
During the go-to-market phase, the product org delivers pricing and packaging, defines paths to the market, performs customer enablement, markets the product, shepherds customers through the sales and onboarding process, and supports implementation teams taking customers to production. Today, most companies spread these outcomes across product, engineering, sales, marketing, customer success, and professional services. Grouping these teams into a product org better aligns the contributors to achieve those outcomes.
I call out post-sales as a distinct phase. It is an encompassing term for customer adoption, expansion, and renewal. Everyone in the company is involved, but there is a heavy emphasis on customer support and customer success. These teams contribute to the product lifecycle by pushing feedback to the product and engineering teams. The goal is to continuously improve the product that delivers value to customers.
Reorganizing the broader set of teams under a product leader makes a more efficient product organization for your company. Align these functions so they understand the role each plays in the product’s lifecycle.
I can’t resist a quick aside about growth product management. Whenever I see a description of growth product management, I say, “Wow, that sounds like what good old-fashioned product managers do.” The difference is growth product managers are sometimes measured and compensated on revenue. This is a huge mistake. This model forces growth PMs to operate tactically. They become customer-driven rather than market-driven, hindering your ability to find product-market fit early on and forcing you outside your ideal customer profile as you scale. Product managers need a strategic focus, so we compensate them using long-term incentives. Remember, people do exactly and only what you pay them to do. Your product’s vision, strategy, and roadmap contain objectives spanning five years or more. PMs with a quarter-by-quarter, revenue-driven operating mindset will struggle to keep those strategic objectives in mind.
What do you have time to teach?
The first question to ask yourself is, “What do I have time to teach?”
Product managers are the foundation of your product organization. When hiring a product manager, your first decision is whether your product org benefits more from domain expertise or product management skills. Choosing one over the other may depend on whether you are building the team from scratch or adding to an existing team. It will also depend on the kind of product you are building.
Your market category or product requirements often determine when you need deep domain expertise. When I was building the team for a cloud data encryption product, I knew we would be spending a lot of time in front of highly regulated customers with specialized teams of deeply technical security practitioners who knew encryption really well.
My primary PM needed credibility and the ability to hold their own during conversations with cryptographers working for multinational banks, healthcare providers and payers, big pharma, and government agencies. I didn’t need them to be the smartest person in the room or the undisputed cryptography expert. Still, they had to clearly understand the problem, be able to respond to feedback and know what was important when those sophisticated customers asked for features. The PM needed to know that certain requests could send the product in an entirely orthogonal direction.
Cryptography and data encryption are expensive to teach; product management skills are less so. I picked a candidate who was strong in the basics of encryption and had a background in security. I spent a lot of time teaching product management: how to source and validate requirements, create and manage a backlog, and prioritize features. We talked a lot about product management’s emphasis on the what and why of software development and how to handle the tendency to dive into the how with developers.
Your product organization will determine when to hire a PM with solid and diverse product management skills. When building a product organization from scratch, your first hire is the foundation of the product organization. In early-stage companies, the product manager wears hats you’ll distribute to other team members later. Hire a PM with solid product management skills, maybe even someone who could take your job as the product leader. The more they know about running an agile software development org, how to deliver value to customers, choose tools and create processes, collect and analyze data, and even build the team, the better. Deep insights about the market and technology can wait.
Eventually, you’ll need both. Teach your domain experts the necessary product management skills and blend them with experienced senior product managers to round out the product team’s skills and build a strong foundation for your product organization.
Remember the takeaway from part one of the series. You aren't trying to find perfectly well-rounded individuals. You are building a well-rounded product team. It's tempting to go for a super chicken at this stage. Don't.
Customer focus and time to value.
Your product organization’s most important measure is the time it takes to deliver value to customers. Everything follows from that: software design, software delivery, customer acquisition, conversion, use and expansion, retention, and, of course, revenue. Whether you are looking for candidates with product management skills or domain expertise, filter for customer focus as the most essential attribute. How do you figure out whether your candidate has that focus?
Hiring a great team relies on finding people who match basic characteristics important to your product org and company. I start with making sure the candidate matches our core values. Does this person value openness, honesty, transparency, accountability, and integrity (my five core values)? Core values make “culture” tangible, and knowing someone’s core values mesh with yours will give strong signals about how they’ll fit in the org.
Test for strong communication skills. The product team is the glue that holds together a product org, keeps everyone aligned across the product lifecycle phases, and ultimately makes or breaks a product. Ask candidates to tell you the story of your product. I use a specific framework for product storytelling–the ladder of abstraction and story spine. A good storyteller may use different tools but will know how to tell a compelling story about Why, What, Who, and How, even if they aren’t deep on your product.
I use the product manager programming test to get quality data about their thought processes and what to expect when working together day-to-day. The test shows you how well your candidate collaborates before you hire them.
Finally, hire a diverse team. Nothing improves your outcomes more than a breadth of backgrounds and experiences. Diverse teams collaborate better, communicate freely, and make better decisions.
The product organization experiment
Experiment with the more broadly defined product organization. Changing reporting structures isn’t necessary, and frameworks like DACI (Driver, Approver, Contributor, Informed) build alignment around your product objectives.
Look for ways to make teams product contributors rather than merely consumers. Imagine the improved productivity you’ll get from a presales team engaged with a product early in the lifecycle and has an opportunity to give input and exercise influence when it matters, i.e., before the product ships. Relieve pressure on your product team by enlisting the customer success team to help tell the product’s story using the customer’s words and language and gather important product insights through their unique, day-to-day interactions with customers.
Tailor the product organization’s structure, participants, and operational models to the specific needs of your product and company. What works for a product with a sales-led model may not work in a product-led model. But it might.