It’s a well-known trope in the fantasy genre that any viable party on a journey must consist of a healthy balance of roles. Take the Fellowship of the Ring — Middle Earth’s most famous band of questing legends, comprising swordsmen, an elven archer, an ax-wielding dwarf, a wizard demi-god and a merry group of hobbits. Each has a specialized job to carry out, and the complementary teamwork represents a whole greater than the sum of its parts.
Though Frodo and crew separate long before the epilogue concludes, the construction of their company has become genre-defining influence. Beyond the pages of Tolkien’s masterpiece, from boss raids in role-playing games to the unbound imagination of Dungeons and Dragons tables, specialized roles play an important part of group dynamics.
Though it might seem a more distant concept, a similar process of specialization, delegation and role ownership exists in tech companies. For a product team that must collaborate to roll out important milestones for its business, a fellowship must coexist to realize its goals.
This is the underlying philosophy at Catalyst Software, a customer success platform that integrates existing client-facing tools into a centralized, data-driven view for its users. With software as the sales tech company’s main service, the structure of its product team is all the more important.
Jon White, Catalyst Software’s VP of product, describes a curated process for staffing and distributing its product team that ensures a smooth workflow for both internal development and clients. He scales the product department and its roles based on the dynamic needs of the team and the organization at large.
“It depends on the stage of the company and team,” White said. “Early on, I look for generalists; for more mature orgs, I look for specialists in certain areas.”
Not every product team looks the same, as each occupies a need and functionality unique to its parent organization. For a closer look at how Catalyst Software has fine-tuned the iterative process for crafting its intrepid product party, Built In NYC sat down with White to hear how he finds the right people — tailored to the right roles — for the journey ahead.
Give readers some insight into the current structure of your product team. Why did you decide to structure your team this way?
We start with our product strategy, which I am accountable for. This essentially defines which themes we will and won’t work on. Then Sha, the VP of engineering, and I will assign teams to the themes. Teams are most effective when they have a defined engineering manager, principal designer and product manager, and get to work on a consistent theme over the course of multiple months and quarters. This allows them to get deep expertise in their area which results in high-impact software. PMs report directly to me — no managers yet — in order to keep things fast.
Our company philosophy is built on the idea that the greatest growth level a business has is their existing customers. We take deliberate steps to keep EPD close to customers at various parts of their lifecycle, be it dedicated CS and AEs working with EPD teams to build features, PMs sitting in the monthly at-risk meeting, or customer implementation escalations going to engineers. We want to ensure that our customers are always at the center.
Our company philosophy is built on the idea that the greatest growth level a business has is their existing customers.”
How has this structure evolved as your team has grown?
Product teams go through roughly three different stages. Early on, around Series A, the founders are very likely still involved in PM duties, and you might not even have enough people to build multiple feature teams. Things are very scrappy, and direction changes often as you are learning about product and market fit. At this stage you want things very flat, and you want PMs who are generalists and executors, okay with spreading their time across multiple projects. Once you get to Series B or C, you’ll likely want to create specific teams and have dedicated PMs and PDs on each, but you still want to keep the organization as flat as possible. The final stage is introducing managers and directors. At this point you can start to be more specific about the skill set you hire for.
Given how you structure your product organization, what’s the most important consideration for you when adding new members to your team?
I don’t consider technical experience a must-have for all PM roles, as many of the best ones I have ever worked with don’t have an engineering background. For me, the biggest predictor of PM success is deep curiosity in both customer and product. I look for people who obsess over understanding the why, and who can go really deep into the details. If you were the kind of kid who took your toys apart to see how they work, you’d probably make a good PM. I also look for people who can take multiple ambiguous inputs to a problem, and then come up with structure and framework to make sense of and communicate them — this is a must have skill for product leadership.
