My name is Kevin Sakamoto, and I'm currently the Director of Product Management and Product Operations at Dollar Shave Club, where I've been running product operations for a little more than a year now.

When I first started, product ops was a new function and it's still being fulfilled by just me. But in this short period of time, there's been an explosion of content around it, from conferences and panels to dedicated podcasts, articles, and more.

In this article, I hope to add to this growing body of work and knowledge by sharing some insights into the behaviors I see as necessary for success in this role. I'll begin by taking the practitioner’s point of view and then shifting to the leadership perspective.

First, let’s look at what product operations looks like at Dollar Shave Club.

Product ops at Dollar Shave Club

Broadly speaking, product ops at a Dollar Shave Club (DSC) can be grouped into a few key categories. I'll be covering these and more:

Cross-functional orchestration

I wanted to first go into cross-functional orchestration. You probably know, or you might’ve heard that product ops is being fulfilled by a single employee, and it's oftentimes a catch-all position where anything that isn't specifically engineering, or product management, just falls to the product ops role.

That's true here at DSC as well, but this still falls into cross-functional orchestration, because so far, a lot of the sort of catch-all work did span across multiple roles, but rest assured, it exists at Dollar Shave as well.

So let’s take a look at how product operations has made a difference so far at DSC...

Strategic support

This is touching on those broad strategic initiatives that cut across multiple stakeholders and divisions. Previously, product operations had periodic involvement in engineering and product management, and this entire process was a little opaque. Today engineering and product leaders have a seat at the table.

There's broad visibility and the trade-off discussions can be had a lot sooner in the process. So there are no surprises as we get into planning, and there's compatibility with the roadmap. This really does help the overall planning process and reduces a lot of friction.

Roadmap planning

We all know how much we don't like surprises in the development side of the house as it relates to roadmap planning. Previously planning processes were a little unscheduled and there were unplanned spikes and discovery spikes, as a result of that. With product operations today, there are clear dates for when we have planning sessions for the rest of 2021 and into 2022.

The product teams can have these scheduled predictable spikes for discovery, and the entire process is visible, it's available for everyone to see. And the outcome of that is, there are clearer and clearer rhythms for everyone to plan around. Discovery cycles are planned around them and even stakeholders plan certain events and activities around the planning rhythms that the engineering and product team has.

But a lot of this did not come easy. You're seeing a very simplified view, and it required a lot of iteration. In fact, not too long ago, I applied a new set of changes to our planning process, and iteration continues to this day.

Iteration in product ops

Iteration is, of course, nothing new to product managers. It's basically second nature for us - we prototype, run AB tests, measure results, prioritize. Then we monitor what we push to production, and rinse and repeat all over again.

All of this activity is recorded in your analytics or testing tool of choice. So product managers can easily go back and see the results or see the prior performance. But for product operations practitioners, we don't have that tool yet. We can’t just go back and see what the results were rolling out this planning template, or this document, etc.

This leads me to my first bit of insight for practitioners, and it's to record your iterations. There are important things that can happen as a result of this. One is it shows you how far you've taken the organization when it comes to, for example, planning. And it also shows how far you’ve come yourself.

Applying iteration to roadmap planning

Let's apply the above a little bit to the roadmap planning process at DSC. I keep a separate log, for just roadmap planning, and it's currently more than nine pages long. Everything is recorded in there when it comes to the rhythms, the content, and the copy necessary to facilitate planning.

So for example, in the comms copy, there are various invites to go out, and I always iterate on that particular invite. I do this to make sure the content is clear, it's concise, and there are clear outcomes and output, the what the desired output of those meetings are is also visible.

There are, of course, multiple iterations of that and I keep snippets of it and continue to iterate on that particular copy. So all of this is looking to improve that planning process to iterate upon what has already started.

Site analytics

However, knowing what to iterate on requires a lot of manual work. We don't have some of the tools that can quickly identify what is and isn't working within product operations. So it's incumbent on us to actively solicit feedback from our customers and stakeholders.

I'd like to take a moment here to define what a customer is, as it relates to product operations.

Anabela Cesário, Director of Product Ops at Outsystems, has previously spoken about how she defines product managers as her customer. She says that if she does a good job, then the PMs can do a good job in working with the customer and bringing the voice of the customer to the team.

I've since brought this internally as well, and what this really says is that feedback is critical in product management. The same holds true for product operations…

Feedback allies

This leads me to my next bit of insight, in that it’s important to identify your feedback allies. Some of the feedback will be harsh but it's necessary for you to stay on target.

I mentioned earlier how product operations is a catch-all role, and given everything that product operations practitioners are asked to do, it's easy to be consumed by the work and lose track of the way forward.

Finding these allies will serve you in two key ways.

  • It will keep you on track.
  • It will also be a source for you to improve your particular product and iterate your products.

What to look out for in feedback allies?

You want to make sure that they have some level of equity within the company. That they made a difference already in their own respective space. Make sure they have tenure and remember tenure is different from seniority. It’s making sure they have a history with the company that can provide you with historical context and sub-context along the way.

Ensure they’re transparent, as you need that brutally honest feedback. The journey of product ops is long, and it's uncharted. There's a lot that's being asked of you. So it's important to have these allies along the way.

I mentioned that I keep track of the feedback for roadmap planning and that I always iterate things. I certainly keep track of the feedback from my allies. So what's consistent between the two is just keeping track and keeping a record of those things.

Consistency in product ops


When I think about consistency, I always think about traffic reports, right?

They're relentlessly consistent and available in multiple formats...

Whether or not the traffic report applies to you, on any given day, it doesn't matter. They're there if you want them. And the same is true for your daily practice and external communications for product operations.

Each of you will have different communication artifacts and rhythms, but it's important to be consistent, as it will be your conduit to stakeholders.

What does that mean really? Well, there's already a lot of ambiguity about what you do, and you may think that your comms go unnoticed. But trust me, they don’t. The stakeholders do notice and consume your content and soon enough they're going to reach out to you and engage with something that you sent and you’ll have the answer very quickly because you've already sent out all the prior pieces of communication.

Be consistent in your comms, your documentation, and your workspace. For example, with planning the verbiage I use in my email is identical to what is found in Confluence, in that particular workspace. And this eliminates or reduces the chance of confusion or ambiguity. It makes my job a little bit tedious, but just like the traffic report, the same information is available in multiple formats.

Now, while practitioners are busy broadcasting, leaders who have product operations roles report to them, need to be acutely listening...

Listen, share and amplify

Your practitioners are broadcasting a lot and you want to listen to the feedback that your peers are sharing. You want to reference the artifacts that your practitioners are sending out and reference them accordingly.

So if you're planning a meeting, make sure you bring up the planning comms and the planning space that your practitioner has. And you want to solicit feedback in one-on-one time with your peers. When you do receive that feedback, try as much as possible to share it when it's fresh because your practitioners are constantly iterating in order to solve the problems in front of them. Sharing that feedback, when it's relatively fresh, will help out a lot.

Be clear on problems to solve

Just like with product management, there is no shortage of problems to solve. The same is true when it comes to product operations. This is why it’s so important to be very clear on which problems to solve.

Work with your product operations practitioner to illustrate what the outcome is when they do solve that particular problem. Remind your practitioner that when a problem is solved though, that doesn't necessarily mean it's the end. It will very likely aluminate new issues to address.

When you couple the multitude of problems to solve, with the influx of asks, it's important to work collaboratively and prioritize the work. I really want to underscore the collaborative aspect of this relationship. It's important to create that safe space for you and your practitioner, to be honest, and vulnerable.

I'd like to end with what I think is the most important aspect for leaders of product operations practitioners - vulnerability…

Dr. Brene Brown is a celebrated TED speaker, professor, author, and she studies vulnerability.

She recently defined vulnerability as:

“...the skill and ability to lean into uncertainty, and risk, and emotional exposure in a way that allows you to maintain a productive forward-thinking strategy.”

This definition of vulnerability is shared between the hiring manager and the product operations practitioner. If you think about it, the hiring manager has to risk their reputation by advocating for this role. They have to give a budget, a headcount and stake their reputation in order to create this new role within the company.

The practitioner, they had to risk their career for taking on this nascent discipline. They were probably a rising star in the product management space and saw this role as something where they could build something new and make a difference within the space.

There's a level of risk that both assumed and when you add in the fact that success is very difficult to measure, it makes it even more of a risk. For example, much of my success over the past year came from a lot of behind-the-scenes work that the product management team will never see.

So for those of you in leadership roles, carve out the time to recognize the sacrifice both of you made to get to this point, then do whatever it takes to maintain productive, forward-thinking, strategic discussions.

Product operations has certainly been a test of endurance for all of us over the past year or so. We've all had our own challenges and struggled to find even the smallest of wins.

Our passion to build, to learn, to grow, and to make a difference led us here today. You, like me, are perhaps a party of one at your organization, but the second Product Ops Summit and the thriving community within it are proof that you are certainly not alone.

Thank you.