How Redgate structures product management
As we expand our product management team, perhaps the top candidate question is “how do you structure the team?”. It makes sense: the role has different meanings at almost every organisation, and correspondingly different ways of working with others.
That structure is also an important part of how we offer people opportunities to learn from each other and grow as product managers, so it’s worth laying out a little more about how we work. Perhaps as interesting as the structure itself, is why? For that, we first need some context:
What does Redgate’s portfolio look like?
Redgate offers end-to-end database DevOps, providing ingeniously simple software to help data professionals get the most value out of any database, anywhere.
We structure the portfolio around four main solution areas:
- Database Monitoring, helping database administrators (DBAs) keep the world’s most complex database environments fast and secure.
- Test Data Management, giving engineering teams reliable access to the high quality test data they need to improve software delivery.
- Database Automation, letting teams bring DevOps development and deployment practices to the database, removing it as a blocker to shipping value faster.
- Database Productivity, reducing engineering teams’ manual work with scalable, standardised development approaches.
In most cases, those solution areas include multiple products. We also have groups spanning these areas, including the Enterprise Portfolio Group which seeks to make the whole company better serve our largest customers, and Foundry which drives our approach to new product innovation.
The overall org structure
Redgate is functionally organised – into Product & Design (under the CPO), Engineering, Commercial (Sales, Customer Success and Support), Marketing, along with Finance, Legal, People, and more.
We aren’t divisionalised by product area, so most people in the Commercial and Marketing teams aren’t attached full-time to a single product, with the exception of our close peers in product marketing. Engineering is largely split by product, though we do have some efforts which span solutions.
Redgate is a product-led company: in Product Management & Design we bridge the other functions, working closely with them but not sitting as a sub-part of Engineering as is the case in some orgs, or of Product Marketing as is found in others.
What are product managers responsible for?
Ultimately, product managers are responsible for the commercial success and customer outcomes of the products they work on. We partner across other functions to make that happen – it’s a deeply collaborative role, mixing strategy with doing, and technical with commercial.
Specifics of what that means varies, because products have different needs. For example, our Database Monitoring solution has been on the market for nearly 16 years, with thousands of happy customers, and still seeing phenomenal growth as we help users with ever-more-difficult problems while expanding into adjacent markets. Meanwhile we’re really excited about the early success of our Test Data Management solution launched in 2023, but the levers we need to pull to land that new opportunity are very different to how we accelerate our existing Database Monitoring business.
It’s product management’s job to deeply understand our situation (including our customers’ needs & our business goals), to work out the best way to get us there faster, and to lead others in making that happen.
So how is product management structured?
Each solution area is led by a Group Product Manager (GPM), reporting to the CPO and responsible along with a team of Product Managers for that solution’s success. We try in each solution area to have product managers at a mix of stages in their careers, giving people the chance to learn from each other – a core part of the GPM role is the growth of the Product Managers on their team. The CPO’s direct team also incorporates other specialists we can learn from, including a pricing expert, and the head of product design – she leads the design team, with each of those designers in turn sitting in the solution areas.
Structure of the product management team
While each solution area has multiple product managers working in it, we define distinct areas of ownership, rather than everyone working fungibly across the solution. That might mean owning a specific product in a multi-product solution, or a particular customer segment, or business problem, or substantial new capabilities. For example, at time of writing in our Database Monitoring business, one product manager is responsible for bringing to market a new security monitoring proposition, involving working with engineering teams on what we build, marketing teams on how we position & promote it, sales teams on landing it with customers, and support & CS teams on ensuring customers achieve the value we promise. In a different solution area, another product manager is responsible for launching a new service which ultimately aims to generate Product-Qualified Leads for our Flyway solution through a service offering visibility into the state of database deployments across projects – again the product manager owns the end-to-end outcomes, working across functions to achieve them.
As well as working alongside people in functions like sales and marketing, product managers each work closely with one or more product teams. That includes being a key member of that team’s Product Leadership Group, where alongside the Tech Lead and Designer, product managers steer the team’s direction, each providing different perspectives on a common opportunity like those described above.
Product management’s role in a product team
As much as we want to carve out distinct areas of responsibility, that isn’t the case with everything: we aim for product managers to feel a deep sense of ownership over our overall performance, for example, and will each additionally pick up things which don’t obviously fall into one person’s remit, where we can see they’re what our solution as a whole needs. That means product managers working as a close-knit group in the interests of the overall solution, as well as towards their own respective goals.
Why does this work for us?
Our product management team is larger than at most similarly-sized organisations (over a dozen, and growing). Perhaps the most important thing that gives us is an environment in which to learn and grow from each other, with our experience being that the most impactful learning tends to happen through doing.
As a product manager, you work directly with a small group of peers aligned around a solution, but are also part of a wider product management community which can mentor each other and share advice, eg through our weekly lightning talks, or at quarterly sessions where all of product management & design take time out together to address shared problems.
Product management and design teams
We think the structure also manages a good balance between people having enough attachment to a specific domain to build deep expertise over the long term, while having plenty of scope to take on new challenges in line with a combination of an individual’s development goals and the needs of the solution area. As a guide we might take on a wholly different responsibility within a solution area approximately annually, but would tend to stay attached to a solution area for multiple years.
For most of our product managers, the blending of time with others across the product management team, leadership of engineering groups, and involvement with customers & go-to-market teams is a big part of what keeps things varied and fresh. That includes contributing to initiatives which aren’t constrained to one solution area – perhaps around improving the way we work with usage telemetry, or around our approach to cross-selling between customers of different solutions.
Of course, none of this is carved in stone, and certainly we don’t claim this structure is perfect. It’s also more subtle than the slightly simplified description provided here – eg in reality we have different numbers of product managers in each solution area, and have other specialist roles not listed. But we strongly prefer to adapt and do what works in each situation over sticking to structure and process for its own sake. For that reason, we absolutely expect this all to continue evolving as we discover more, taking on new ideas as the team learns & grows. Speaking of which..
Psst: one more thing
We’re hiring! If you’re excited to work in a growing, supportive Product Management team that empowers individuals to drive business outcomes, we’d love to hear from you. Take a look at our open opportunities for details.
You may also like
Blog