What kind of job title requires the employee to be a product manager, designer and QA resource?
According to Co-founder and Chief Product Officer Allison Page, an appropriate answer is “jack of all trades.” And she would know, she lived it during the early days of hospitality platform SevenRooms, where she wore many hats to help launch the startup’s one product.
But as the company developed a catalog of seven products, a generalist job description was no longer scalable. As the engineering team grew and divided into squads, Page said they now look for specialists with a particular expertise in product ownership. And while each person’s expertise may be different, they share a passion for the company mission.
“Each of our PMs offers our team something different, but at the end of the day, they’re all excited about solving real-world problems for our hospitality clients,” Page said.
Along with knowing how, knowing when to restructure product teams is critically important for every product leader. As companies add more features and products, what was once praised in the founding days might not work when the company is ready to go public. Below, Built In NYC talked further with Page and four other product leaders about how they structure their product teams, how their teams evolved and what they look for in future additions.
To keep employees on the same page during periods of rapid growth at fintech company Petal, VP of Product Roy Simkhay said product managers must emphasize transparency. Each PM leads a cross-functional squad consisting of engineers, designers and select people from across departments focused on the squad’s goal. Through transparency and collaboration, the product team can innovate quickly, Simkhay said.
How did you decide to structure your product team?
Our product team is organized so that each product manager leads a cross-functional squad that works on a particular part of the product. Each squad includes our engineering and design teams, along with people from across the company who are key to achieving the goal.
For example, our growth squad achieves its goals of fueling our tremendous growth in cardmembers. Leaders from marketing, credit risk, customer operations and others are all included. They’re all working side by side within the squad structure. Cross-functional collaboration is critical to innovating quickly.
Cross-functional collaboration is critical to innovating quickly.’’
How do you envision this structure evolving in the future?
Over the last three months, we’ve almost doubled the size of our product team, which will open up the opportunity for us to evolve the structure of our team in exciting ways.
We’re moving toward organizing our product areas so that each covers a specific user need from end to end. This is tremendously powerful because it allows us to define a North Star goal for that product area and a clear vision for where we want it to go long term. The roadmaps then fall into place from there.
Given how you structure your product organization, what’s the most important consideration for you when adding new members to your team?
We look for high levels of technical fluency, problem-solving aptitude and a desire to learn in all of the PMs we bring onto the team.
Each of our PMs is overseeing a complex product area that brings together many different disciplines across the company, and their product decisions are often balancing those potentially competing needs. It is important that we have high-trust relationships with our stakeholders. At Petal, PMs operate with a high degree of transparency.
Co-founder and CPO Allison Page said she was a “jack of all trades” as hospitality platform SevenRooms’ first product manager (and designer and QA resource). As the company has grown, the engineering team has divided into squads that focus on user types and user solutions. Page said they now look for PMs who are specialists, rather than a little bit of everything.
How did you decide to structure your product team?
Our product and engineering teams are broken out into several “squads,” with each squad having an area of ownership in the platform. Our product managers lead our squads. Each product manager’s area of responsibility is typically driven by the types of users we serve and the problems we are trying to solve for those users.
For example, we have a squad focused on the consumer experience of ordering pickup and delivery, another focused on the experience of restaurant hosts using our front-of-house application, and another focused on the marketers using our marketing automation tool. These are three distinct sets of users, with three distinct sets of challenges, so it makes sense to create a separate focus for each on our team.
How has this structure evolved as your team has grown?
In the early days, I wore many hats as the only product manager, the only designer and the only QA resource. At the time, we only had one product (reservations and table management), so it was possible to run the full spectrum of roles required to iterate and get a new product out the door. As the platform capabilities expanded, we grew the product team by adding generalists and smart people capable of wearing many hats and jumping in on whatever challenges were thrown their way.
As the platform evolved, we’ve also evolved the types of hires we bring on to the team. Instead of hiring generalists who can be the “jack of all trades,” we now look for specialists with particular expertise that can be brought to a specific squad and area of product ownership. Each of our PMs offers our team something different, but at the end of the day, they’re all excited about solving real-world problems for our hospitality clients.
Our most successful product team members have always been obsessed with uncovering the root problem.’’
Given how you structure your product organization, what’s the most important consideration for you when adding new members to your team?
The most important consideration when adding new team members is that they are curious and always ask “why” questions. As a B2B SaaS company, our product must continuously drive value, streamline our customers’ operations and create more profitable restaurant businesses. With a backlog of thousands of product ideas and feature requests from our customer base, our product managers and designers must always dive deeper to understand the “why” beneath these requests. Our most successful product team members have always been obsessed with uncovering the root problem and discovering the customer’s motivations around the request or ask.
At automation platform HyperScience, all problem-solving starts from the ground up, rather than top-down management. VP of Product and Design Francisco Uribe said that looks like tightly aligned squads, grouped in layers to represent the core modules of the user experience such as system integration, platform and AI.
How did you decide to structure your product team?
Conway’s Law said products tend to resemble the organizations that build them. Traditional organizations try to solve this problem with bureaucracy and top-down management, leading to politics and inefficiency. We believe in turning the problem on its head, so we’ve built an organization that mimics our long-term product architecture from the ground up. For that reason, we designed our product, design and engineering organization into loosely coupled and tightly aligned squads, grouped in layers, to represent core modules of our user experience.
With this structure, we have been able to scale gracefully, build user-persona-level specialization and maximize our customer value delivery.
Conway’s Law said products tend to resemble the organizations that build them.’’
How has this structure evolved as your team has grown?
The Hyperscience product, design and engineering organization has evolved as our company ambitions and product offering has evolved. The first version of our product was designed to address the intelligent document processing needs of our customers (Global 2000 companies and government organizations) and was structured around the core functions of data classification and extraction. Our vision has evolved considerably since then. As a company, we believe in the power of automation to transform how businesses operate, serve their customers and manage their human resources.
As we evolve into an input-to-outcome automation solution, our teams now resemble the layers of a full-fledged platform: system integration to aid with the deployment of our solution, platform to provide workflow management, blocks representing our AI functions and verticals focused on providing out-of-the-box solutions for key vertical-use cases (e.g., claims processing, underwriting, loans origination).
Given how you structure your product organization, what’s the most important consideration for you when adding new members to your team?
The requirements vary depending on the layers of our team and range from highly technical in our system integration layer to the most business-oriented roles in our verticals layer. In general, a preferred qualification for senior roles is experience in enterprise software. People in enterprise software tend to show a higher sense of user-empathy than B2C, which is important since we are not the users of the products we are building. These people help hone our user interview, buy-in and technical skills.
Vice President of Product Daniel Pardes said that a “pods” structure of product manager, designer and engineers results in team autonomy and faster feedback loops at community-building platform Meetup. As the company evolves, Pardes said he expects each pod to be aligned to opportunities, rather than projects, to accelerate product development.
How did you decide to structure your product team?
At Meetup, we’ve found that the best way to organize our teams and work is by “pods.” As an atomic product development team, each pod consists of a product manager, designer and three to five engineers. Decision-making is centralized to the “triad” of the product manager, designer and engineering lead who work together and with their team to decide the best path forward.
This team autonomy results in shorter feedback loops. When we discover new information about the customer, uncover shifts in the market or see emerging technology, we can react quickly to that information. It also allows us to align functions like user research and data to support product teams in all stages of their product development process. And the small pod size gives us flexibility in planning and staffing.
Ultimately, this structure is optimized for timeboxed execution to achieve specific outcomes for the company and our customers. We believe that this also helps us leverage individual skills and balance team dynamics to ensure personal and professional growth for each team member.
This team autonomy results in shorter feedback loops.’’
How do you envision this structure evolving in the future?
As we learn more about our users and how best to support them in today’s ever-changing world, our strategy will evolve — and with it, our structure. We expect that our pods will become less project-oriented and instead be more aligned to a problem area or broad opportunity. Our goal is to continue to accelerate our product development while maintaining a balanced team composition and avoiding siloing knowledge and creating disparate team cultures.
Given how you structure your product organization, what’s the most important consideration for you when adding new members to your team?
There are two important qualities that we look for when adding members to the team. The first is a hunger to increase Meetup’s reach and impact in the world. Meetup exists to help people find and create communities that gather around shared interests and identities. This is why we go to work every day. And every PM, designer and user researcher has to bring this hunger and urgency to their team and the work we do.
The second quality we seek is curiosity — a need to ask and understand the “why,” whether it’s a user behavior we’re observing in the data, a design decision that we’re making or technical tradeoffs we’re considering. For us, curiosity translates into having a strong desire and appreciation to understand all angles of a problem, gather information from various sources and evaluate multiple approaches to solving a problem.
