Product Ops @ SiteMinder

Dominik Katz
6 min readMay 15, 2020

--

Product Operations is a relatively new field, that companies approach vastly differently and are still learning along the way. The consensus however seems to be that Product Operations can be the backbone to achieve product excellence as an organisation is growing.

For more info and perspectives, check out the views of ProductPlan, Mind The Product, the Product-Led Institute, and this role description at Gitlab.

This is a write up of what SiteMinder learned on the Product Operations journey so far.

Photo by Visually Us from Pexels

Why did SiteMinder NEED Product Ops?

The short answer is: We didn’t.

The longer answer is that we conducted internal research across all our product teams — 14 cross-functional teams with Product Manager, Product Owners, Designers, Engineering Managers, Principal Engineers, Tech Leads and people outside the direct realm of product and engineering. Anyone who couldn’t run away fast enough basically. Our key question was this:

Why do we not reach our potential within product, despite trying so hard?

Our goal was to get a sense of all the bottlenecks, perceived and otherwise, between an idea and that idea being in the hands of customers.

What we found was equal parts surprising — in terms of the breadth of topics — and unsurprising — because most companies struggle with similar issues.

We value Autonomy, nearly out of necessity. Our products range from directly hotel guest facing to building API connections to our external partners. A level of autonomy is necessary, and valuable. We found, however, that nearly all teams struggled to consistently answer a bunch of questions essential to every team:

  1. Why are we working on this?
  2. Who are our users, really, and what are their needs?
  3. What is the best way to address those needs?
  4. What is our highest priority — and are we working on it efficiently?
  5. How do we measure success?
  6. How do we best communicate and support change?
  7. Were we successful?
  8. What have we learned?

When we hired for a role to help our product teams address these questions systematically, we called that role Product Operations — just because it felt right.

What does Product Ops look like at SiteMinder?

As we formed a small team around Product Ops and defined our mission, we crafted our value statement:

Our vision is that all SiteMinder product teams are proud of how we work.

We provide a high level framework to bring Transparency, Focus, Capability and Collaboration to our product teams. Our mission is to empower our teams to find their own way to work effectively within this framework.

We achieve the mission not alone, but by partnering with the teams and stakeholders to drive team effectiveness and self-organisation.

The last point is very important. Many people within the organisation were already performing many of the functions that one might have otherwise attributed to Product Operations. Some of our closest allies were

  • Product Specialists — who are closest to our Sales, Marketing, Onboarding teams and customers and bring their feedback efficiently into the right product teams,
  • Product & Customer Marketing — who are true masters in finding the right messages and channels for different customers and help bringing the initiatives to market,
  • Customer Support and Onboarding — who are closest to our customers and are the chaperones for a positive user experience
  • Customer Ops — who master the tools and communication channels with our customers and our teams
  • People & Culture — who care deeply and provide guidance on professional development

Similarly, many initiatives to contribute to these core areas of Transparency, Focus, Capability and Collaboration were driven by team members passionate about the topic. Let’s dive into each of those three:

Transparency — Work in the open

Maintaining transparency in a growing organisation is a challenge. Striking the right balance between scattering information proactively to everyone who might be interested and communicating too little so as not to bother anyone is difficult.

  • Dependencies. Making initiatives and dependencies visible to everyone, first in the office on a wall, then digitally to our global offices
  • Blockers. Actively talking about blockers and bottlenecks as a group to our executives — and transparently tracking progress on those. Raising blockers requires trust, and resolving blockers timely will earn trust.
  • Communication. Regular, asynchronous product updates to help allow people who care to stay in the loop
  • Documentation. Our key focus for documentation is to keep it as lean as possible, but not too lean. Removing duplication, using tools that area already embedded in the teams to help keep the overhead low.Standardising initiative pages to aide understanding of the problems our product teams are solving

Focus — Do what matters

Transparency without focus is counter productive. Making things visible is only valuable if it’s being used to improve decision making and drive out inefficient processes.

  • Priorities. Providing the structure to connect SiteMinder goals to portfolio goals to team goals. Encouraging teams to communicate the key objective for the coming quarters, which initiatives contribute to these objectives and how teams can measure success.
  • Limiting Work in Progress. Saying “no”, or “not now” is a hugely important part for creating focus. Priorities not only play a role at the portfolio level, but at the team level. Running workshops to encourage teams to limit their WIP to help improve their cycle time, both for discovery as well as delivery.

Capability — Enable Autonomy and Mastery

At SiteMinder, we value Autonomy and Mastery. Support is required to guide autonomy and carve out space for mastery.

  • Roles & Responsibilities. We work together as teams. But with new team members and new challenges, questions do arrive about individuals’ and team roles and responsibilities. We enable to teams to work through those with the help of social contracts, workshops, and role definitions.
  • Guilds. Guilds are a primary driver for regular learning. Where possible, we helped facilitate and encouraged learning backlogs. Amongst others, there are guilds to look after Delivery, Java, Quality — and Ways of Working.
  • Inspiration and examples. As part of RuDDEr, we are eager to offer inspiration of how other companies have solved similar issues and, more importantly, how other teams at SiteMinder have solved it.
  • Training & Learning. There are multiple opportunities for learning, most prominently KnowledgeMinder in teams and as a group.

Collaboration — Create together

All the above is important. But it’s not enough to support transparency, focus and capability if we don’t use the insights to help work better together. With our move to platform, we have to radically reimagine how we think about our products and our work. Autonomy for our teams is important, but can only thrive in our environment if we take responsibility of the change we are about to introduce and collaborate with teams and stakeholders around us.

Product Ops helped create forums where collaboration could thrive, such as

  • Portfolio Scrum of Scrums. Our beloved weekly check in went through countless iterations — most recently mostly asynchronously. This is our key forum to raise and track blockers.
  • Big Room Planning. Sharing our priorities, uncover dependencies and potential bottlenecks and planning ahead together.
  • Collaboration @ SiteMinder. Making this part of onboarding sets the baseline for how we collaborate in our teams, from research to evaluate, and across our ceremonies.
  • Facilitation. Facilitation is an art form, and we are passionate about it, bringing people together and making sure all participants get the most out of the time together, whether 15min ceremonies or 3 day Design Sprints.
  • Plays. For our most common workshops and sessions we’ve compiled a list of plays — detailed write ups of the Why, What and How.

What next?

Distributed ownership. So far, Product Ops has put a lot of effort in shaping SiteMinder’s ways of working. That’s great to start, but not sustainable, or even desirable. Now, it’s time for distributed ownership. Passionate people across the business to shape

More from Guilds. Guilds so far have been mainly restricted to roles, with a few exceptions. Our key principles in RuDDEr, shaped by co-leads, will ideally turn into guilds on their own. Guilds around Metrics, Consistent Experience, Continuous Delivery.

Metrics. A large gap is our ability to identify and measure key metrics to define success of an initiative. Over the last year SiteMinder has laid the ground work, implementing GA and Heap, plus make our product metrics more available. Now it’s time to reap those benefits and integrate it into our daily conversation.

Stronger collaboration. We are getting much better at collaborating within Product & Engineering. Our next focus are will be to engage teams outside of that much earlier, frequently and deeply and ensure best outcomes for everyone.

--

--

Dominik Katz

“The more scared we are of a work or calling, the more sure we can be that we have to do it.” Steven Pressfield