Products don’t always start as magnificent technical spectacles.
In fact, most often they begin as a small solution for a minute group of people, simply striving to make a process easier. But within those initial achievements and solutions lies something even greater: possibility. That’s when product teams can start to get creative and ambitious while brainstorming their future goals.
However, what may have worked for a dozen people won’t always work for hundreds — or thousands — as a company’s customer base expands. That’s why in order to achieve continued success, it’s crucial that internal teams strategically scale alongside a product.
Take a look at connectRN, for example. What began as a community-based platform for connecting nurses and nursing aides to opportunities and support systems has created a product demand that necessitates significant expansion. Now, leadership is expecting to double their staff by the end of the year.
“In just a few months, we’ve quickly transitioned from a team of one to now four product managers,” said Director of Product Development Margery Fiori. “And with rapid growth comes the need to reexamine existing structures and processes.”
For leaders at cloud security platform Datadog, continued product success also breaks down to staying true to the company’s original mission statement while building a culture that encourages continuous learning. “We invest in the team at every opportunity, from onboarding and learning programs to ensuring that everyone has the opportunity to grow,” Senior Product Manager Nick Davis said.
Built In Boston caught up with Fiori, Davis and two other product experts to discuss the details about how each of their company’s evolving products have shifted internal structures, why they’re continuously transforming and the exciting future possibilities on the horizon as they grow.
How big is your product management team, and how is it structured?
Today, Datadog’s product management team is 80 people strong and growing. As you might imagine, we structure the team based on the products that are managed. We have product managers focused on everything from APM insights and agent integrations, to platform authentication and authorization, and everything in between.
To help us scale such a large team and platform, the team is organized under a few core groups. The first PM group handles our infrastructure monitoring product, core platform components, and new ITSM products such as incident management. The next group focuses on APM, logs and digital experience monitoring. This includes real user monitoring (RUM), database monitoring, profiling and more. Finally, the third group focuses on Datadog’s security products like the newly launched AppSec, as well as cloud SIEM, CSPM and cloud workload security.
How has that structure changed during the life of the company, or if more applicable, during your time there?
Our first structural change led the PM team to focus on more external product feedback so that engineering could focus more on development. In the beginning, we could rely on our engineers dogfooding Datadog and providing rapid feedback. As Datadog grew, we had to rely less on our internal teams’ feedback because they were starting to have different needs than our external customers.
Next, we changed to handle the Datadog platform. As we grew, so did the products we offered to our customers. We added new products like APM and Log Management. Beyond products, the platform itself evolved to include features like dashboards and monitors. At this stage, we asked ourselves: How do we make sure the next new product has every platform capability out of the box? So the product organization evolved to manage the platform as a product of its own.
Finally, the platform expanded to address new personas. Dev and ops teams have used Datadog from the beginning, but now with the addition of RUM, cloud cost management and security, there are new users like product, security and finance teams. Our current structure enables us to address these new personas.
The same culture that allows new product managers to make critical business decisions will allow us to identify the next level of scale and adapt accordingly.”
Looking forward, at what point does the current structure break down at scale? And what comes next?
Throughout the evolution of Datadog, some core things have remained the same. Product managers at Datadog are ultimately responsible for making their product successful. Autonomy and responsibility at all levels are core to our culture. Product management keeps us moving in the right direction, solving customer problems, and when we ultimately make mistakes, we learn from them and ensure they never happen twice.
Making 80-plus product managers successful also requires a deep learning culture. We invest in the team at every opportunity, from onboarding and learning programs to ensuring that everyone has the opportunity to grow at Datadog.
John Allen Paulos said, “Uncertainty is the only certainty there is.” I don’t know when the current structure will break down. What I do know, however, is that we evolve based on the challenges of the day. Product at Datadog is flexible. We empower individuals to define and solve problems, and to identify new and emerging pain points. The same culture that allows new product managers to make critical business decisions will allow us to identify the next level of scale and adapt accordingly. Personally, I cannot wait to see what happens next.
How big is your product management team, and how is it structured?
connectRN is a tech-enabled platform that connects nurses and nursing aides — the backbone of our healthcare system — with access to community, opportunity and support. With big ambitions to continue to improve the lives of America’s nursing community, the connectRN product team is rapidly growing.
In just a few months, we’ve quickly transitioned from a team of one to now four product managers (PM). We also work very closely with our fellow engineering and UX connectors to plan our scrum teams and overall resourcing plans. As for structure, the plan is for each product owner to be tied to one scrum team and initiative area.
How has that structure changed during the life of the company, or if more applicable, during your time there?
We built the connectRN platform to connect nurses with work opportunities whenever, wherever and however they choose. Nurses and aides are not only in demand, but they’re seeking a better path for their careers, as evidenced by our remarkable business growth. And with rapid growth comes the need to reexamine existing structures and processes.
We’re currently in the midst of refining our onboarding process so that new PMs can quickly get up to speed on our business and goals. Additionally, we’ve taken time to collaboratively work on product planning. Doing so sets the stage for what we plan to deliver as an organization, the outcomes we plan to target, and the necessary resources we will need.
With that work, it has become very clear that our organization will continue to grow and likely double by the end of this year.
Our team is getting the chance to design and build the future of nursing.”
Looking forward, at what point does the current structure break down at scale? And what comes next?
Like everything else we do at connectRN, we learn, grow and adjust. I’m less concerned about the point in time when a structure may break down. Instead, I’m thinking about key questions to help determine what changes, if any, are warranted. These questions focus around fit and scope of work for the team, as well as interest in people management.
With fit, do we have the right product owners for the right type of work? With scope, are any product managers ready for a larger initiative to manage, or the opportunity to demonstrate greater influencing skills? With management, is there anyone on the team who is ready to grow as a mentor or people manager?
Depending on the answers to these questions, we’ll iterate so that the team best meets the business needs, as well as the product manager’s goals and personal development.
It’s truly an exciting time for our business, tech and team. Not everyone is lucky enough to help America’s nurses pave a better path, and empower them to take control of their careers and futures. Our team is getting the chance to design and build the future of nursing. It’s a big responsibility and an even greater honor.
How big is your product management team, and how is it structured?
The ezCater product team is 11 people right now, and growing to 20 this year. We’re structured in five director-led groups, with three on the demand side of the marketplace and two on the supply side.
Prior to ezCater, I led and grew the consumer product teams at Wayfair and CarGurus. Both were structured to start as very flat organizations with a single team lead and a team of talented individual contributors.
How has that structure changed during the life of the company, or if more applicable, during your time there?
Originally, the product organization at ezCater was led by Briscoe, one of our co-founders who is brilliant and incredibly forward-looking. It was organized to take on the lowest hanging fruit opportunities to drive the growth of the business.
As ezCater grew and began to multi-thread its product investments, the initial model wasn’t going to scale. So the organization was broken out into more discrete groups with clear strategic focus areas — growth, core funnel, international and so on — with each group consisting of a more senior leader tasked with building and leading teams against those investments.
We believe our team structure combined with our emphasis on continuous feedback and people development will set up the ability to scale in the future.”
Looking forward, at what point does the current structure break down at scale? And what comes next?
In my experience, there are two main things about team structure that break as a product organization scales. First, while centralization of the team in early days can result in senior leaders with more context helping the team move very quickly, team leadership, ideation, decision making and execution needs to be distributed to less centralized teams to not bottleneck growth as the company scales. This has a number of important implications on decision making and communication between the leaders and teams.
Second, can the people who are on the team scale up and make the transition from individual contributor to strategically-focused people managers leading the more distributed teams? And have they been given the chance to develop those skills early enough, particularly in a hypergrowth environment when you don’t always have the benefit of time?
At ezCater, we’ve just recently established our current structure and we’re being intentional with it. As we look forward, we believe our team structure combined with our emphasis on continuous feedback and people development will set up for both near-term success as well as the ability to scale in the future.
How big is your product management team, and how is it structured?
The product and engineering teams work closely together in product development, and we call those functions the product lab. In the lab, we think in “superpods.” We have a growth superpod which is responsible for all of our product experiences, and a platform superpod which is responsible for delivering the cross-product and platform level capabilities.
We have all four of the growth product managers report to the director of product, growth, and all five of our platform product managers report to the director of product, platform. In a mirror image, all of the growth tech leads report to the director of engineering, growth and respectively on the platform side.
How has that structure changed during the life of the company, or if more applicable, during your time there?
The need for a growth and platform superpod became apparent as we started tightly managing dependencies between platform capabilities as table-stake features and the growth features. So, the structure and clear ownership on each side made sense in order to manage dependencies and be able to build and deploy separately.
The need for a growth and platform superpod became apparent as we started tightly managing dependencies between platform capabilities.”
Looking forward, at what point does the current structure break down at scale? And what comes next?
We’ve grown and are starting to think about how we bridge the gap so that we’re looking at the entire user experience, from first becoming aware of the brand all the way through becoming and remaining a subscriber. Now, we’re starting to think about how our experience design leaders and other leaders in the company, like marketing, create that experience end to end for the user.
