Shintaro Matsui (Head of Product Operations, Amplitude), and Timothy Chen (Senior Product Operations Manager, talabat), gave this talk at the Product Operations Summit in September 2022.


Hello everyone, my name is Shintaro Matsui.


And my name is Timothy Chen.


And we're super excited to be here today. A bit of background on this talk. Tim and I have actually known each other since college, and we both ended up leading product ops teams, which is really funny.

Oftentimes, Tim and I will just catch up and share challenges we're facing, and compare similarities and differences within the role. So we thought it’d be fun to have a similar kind of conversation, but share that with the broader group.

The other thing that's interesting is that Tim and I both started as a product ops team of one and have since scaled our teams to five. There’s been tonnes of lessons learned and mistakes along the way, but we want to share all of those with you today.

We're going to cover a wide gamut of topics. We'll chat through:

And I think all of this is within the lens of B2B versus B2C. What are the similarities? What are the differences and nuances? We’re going to dig into that.

Our paths to product ops


I did management consulting out of undergrad and did that for about four years. It mainly involved digital strategy, digital transformation, and types of engagements.

Then I moved to San Francisco to join Uber on their operations team, working on the Uber Eats business.

And then following IPO, I wanted to go somewhere a little smaller and a little scrappier, and saw this opportunity to build out a product ops team from scratch. At the time, I didn't know too much about product operations. I’d worked with the product ops team at Uber and it seemed like an interesting role. And now I've been at Amplitude for two years, building out the function.

As I'm thinking about my journey through product operations, my piece of advice is that there are so many different kinds of flavors to product operations, and if you're looking at breaking into the function, think about what kind of flavor most excites you. Is it launching new processes? Is it program management? Is it strategy and product planning? And then take that and apply it to your current role.

So if you're on an ops team, think about a process you could improve on and speak to that and highlight some of those skill sets as you're interviewing.


Similar to Shintaro, I also came from one of the ‘big four.’ I started my career at Ernst and Young in tax accountancy and was there for about two years. I then moved to a boutique strategic consultancy company specializing in the hospitality sector, called Savvy IQ.

My career in product ops didn't really start until my next role, which was at HelloFresh. Here, I had my first opportunity to scale a product ops arm, growing it from three people to 13 people in about two and a half years.

And it wasn't until 12 months ago that I made the move to Dubai, in the Middle East, where I’m now scaling a new product operations arm for talabat, which is a subsidiary of Delivery Hero worldwide.

My advice would also be coming from someone that's not originally from a tech background. If you can't apply any flavor in your current role, try to take on an external product ops sprint course to really show your commitment and interest to hiring managers.

Setting up team charters and focus areas


So once you've broken into the product ops field, how do you set up a team charter if you’re a team of one or if you're inheriting a team that might already have an existing charter? How do you go about thinking about that?

What I thought would be interesting would be to compare and contrast the charter we have for product ops at Amplitude versus talabat.

At Amplitude, our product ops team's mission is to:

Empower all teams to execute across the product lifecycle with clarity through processes, tools, insights, and communication.

The key word here that I like to emphasize is ‘clarity’ because when you have clarity, you're able to move quickly but in alignment with others and other cross-functional partners.

Oftentimes, people think of product ops and think of heavy-handed processes and programs. But really, our goal is to help people move faster and move in alignment with one another.

And that leads us to our three key focus areas:

  • Strategy and planning. Our team thinks about and drives annual, quarterly, and monthly planning for the product organization, as well as program management.
  • Building and launching. Thinking about tools, processes, and frameworks to launch and build products to market in a more effective way.
  • Voice of the customer. Thinking about our feedback loop and how we get those great nuggets of wisdom that our field is hearing back to our product team to execute and impact their product roadmap.

Given all of this, my advice would be to revisit your charter and focus areas quarterly. When I look at these now, they’re drastically different from when I was a team of one. So constantly be revisiting your charter, asking yourselves if you're solving the highest leverage problems for your company and product team, and then just solicit feedback and continuously iterate on them.

Tim, can you walk us through talabat’s product ops team's mission and focus areas?


So our mission is to:

Reduce lead time to value for all teams, enabling them to execute across the product development lifecycle with greater efficiency, clarity, and excellence.

The key phrase here for us is to ‘reduce lead time to value.’ This is because we're a lot more operationally heavy, in my opinion. I think it's all about speed and velocity, and therefore, lead time to value is really important here.

So what does that mean for us in terms of focus areas? Well, it translates into three things: alignment, lead time, and product value.

  1. Alignment. From an alignment perspective, an example of that would be drawing from the eight local markets that we operate in to implement these quarterly input collections. Do we have a full understanding of the full visibility and landscape of the local markets?
  2. Lead time. From a lead time perspective, this is your operations 101. So it's about taking these products to market and launching them. We experiment during these product launches.
  3. Product value. With product value, it's very much about: Are we building the right things? Are we continuing to do so?


Later on, we'll dig into some of those nuances between B2B and B2C, and I think that local market input is definitely something that's really interesting to dig into.

  • Challenges on day 1 vs. today


So you have your vision and your charter and you're starting to work through that. But let's talk about the challenges. And I know when we're chatting, Tim, this is what we talk about a lot. And I think it's been interesting to see how our challenges have really changed from day one to where we are today.

So, Tim, when you first started, what were some of your biggest challenges? And are those different than what you're facing today?


They’re definitely very different now, versus day one.

On my first day, it was very much about building trust, showing your PMs that product operations can add value, and getting their buy-in.

There was also an existing way of working because there was an old vision. And very much the challenge was built on trying to convey to them this new vision, this path that we were about to take on, the benefits that would yield and bring to them, and how it was different.

Fast forward to today, it's completely flipped on its head. It's about reprioritization. How do we do the work initiative that really matters and has had the most impact? How do we say no to some of the less impactful work? How do we create a pulse with the local markets? How do we understand them better?

It's about the future states of product operations. As complexity increases and as the complexity of the nature of topics that we take on increases, how do we structure the team in a way that we can keep on learning and growing whilst being scalable at the same time?

And I think my advice would be that evolving challenges here are a confirmation that your team is adding value. So as you solve one thing, you discover another problem. I think that's pretty normal if you're in the world of product operations today.

And I think in a fast-paced and ambiguous environment, you need to take a breather and celebrate the small wins. I think this is often overlooked, so it's important to acknowledge this and really recognize how far you've come with your team.


That's awesome, Tim. I think oftentimes, product ops work can go unnoticed or in the background, so really taking the opportunity to call out those victories is super important. So I think that's great advice.

Reflecting on my day one challenge, it’s quite similar to yours. When I joined Amplitude, no one knew what product operations was, so a lot of it was just education, establishing the vision, and getting people excited about what the function could offer them.

Then it was really building relationships with folks within product and also cross-functional teams to make sure that if we do start to roll something out, that it's really solving their needs, but it’s also something we're able to get their support on.

Lastly, and most importantly, was just chalking up some quick wins, getting momentum for the function, solving people's pain points, and doing that as quickly as possible.

Then I want to compare that to today. Our company has doubled in size since I joined. So a lot of the frameworks we established when I first joined have since become obsolete. So a lot of it's now around creating new frameworks and updating the ones that we had existing to make sure that they’re meeting the needs of the business as it’s scaled today.

Also, we have a different operating model now. We have an embedded scaled model within our team. So we’re working through some of the challenges inherent in that model.

And then also tooling. Tools that we had two years ago also might not necessarily be meeting the needs that we have today. So really having a keen eye there.

I think the advice that I’d give is, if you're not actively improving a process or a tool, you should assume that it’ll regress. And if you do, constantly be looking at those tools and processes. The best way to do so is with the process review.

Every quarter, we pull our product, engineering, design, and go-to-market counterparts as to the tools and the processes that they use to work through product processes and ask them to stack rank them. And it's a great way for us to keep a pulse on these, and also to improve them on a regular cadence.

How to approach hiring in product operations


Now, let's talk about a topic that I've been asked a lot about recently from other product ops practitioners, which is hiring. This is really top of mind for folks who are scaling a team.

One piece of advice that I like to give is to think about team composition. One thing that's worked really well for us at Amplitude is having a mix of both internal and external hires.

Internal hires are people who are working at your existing company but in other teams, and external hires are folks who've worked at other product ops teams in the past, or at other companies, operations functions, or adjacent functions.

That's really allowed us to do a few things. One, the internal hires allow you to have a solid understanding of the business built into your team. So if we're launching a new feedback process, it's really easy to get a pulse on what go-to-market think by tapping into someone that's been on that team before.

And then with your external hires, it's been really fantastic to bring in best practices from other product ops teams. So I think the mix of those two has been really beneficial for our product ops team.

The other advice I’d give to folks is that product ops skills can be taught.

If you have someone who has really great subject matter expertise but might be coming from a support or customer success background, you can teach skills like program management or process improvements, or being customer-centric with voice of the customer programs. And that's something that we've invested time in and it's really borne a lot of fruit.

So that would be my advice in terms of how I’ve approached hiring and skill development at Amplitude.


For us at talabat, I think the problem is that we’re a lot more behind from a product operations job market perspective in the Middle East and Dubai. So I think there's an expectation that I’d have to coach these traits to the team or new joiners. Therefore, the topic of mindset is more important to me.

So the strategy I have here is more on the mindset. For example, being able to deal with ambiguity, having a mindset of driving continuous improvement, and being able to deal with difficult stakeholders. These are some of the traits that I’d look for in order for a person to join us in the product operations team here at talabat.

Being a product operations personnel can be extremely demanding at times, and it’s a role that's often really ambiguous by nature, with evolving challenges that we just touched on. You don't own a product outright like a PM, so sometimes you do suffer from impostor syndrome during bad days in the office.

So my advice is to keep the pulse on the health of the team and really pay attention to their well-being, just to make sure that they're in tip-top form.


That's great advice, Tim. I think that mindset is something that can't be taught, so it's really great to keep that top of mind when hiring.

B2B vs. B2C product ops


So with all that said, we want to dive a bit deeper into some of the nuances that we’ve both discovered between B2B and B2C product ops, which I think has been interesting for us to chat through.

Tim, do you want to start by talking through some things that you think are more specific to B2C product ops?


Yeah, for sure. From a launches perspective, it's evident that the focus here on my side is a lot more on speed and velocity, even in the way we do experiments and bring products to markets. How do we do it as quickly as possible in the right way? How do we take bigger and bolder risk and therefore reduce lead time to value to all eight markets as quickly as possible?

I think from a cross-functional perspective, it's evident that there are a lot more stakeholders here to manage on my side. We operate in eight markets, and from a central business function, we have to continuously liaise with seven different departments.

Therefore, when we're comparing new instances, it's about finding misalignment amongst the local markets. How do we align them together? How do we identify dependencies across all five tribes of the product, and also in the local markets and business functions ahead of time and really resolve them?

How do we work on the right things that all eight markets and seven central business functions are truly happy about? It’s about finding that sweet spot.

So those are the really unique talking points that I found in B2C.


That's super interesting, and there are actually a lot of similarities to when I was working in product ops at Uber. Given how large the customer base is for a lot of these B2C companies, the big focus is on experimentation and rollout plans. So it’s really interesting to see. And I also don't envy your job and how hard it is to have to deal with so many different local markets. So that's a huge challenge.

I think from the B2B perspective, what's been interesting is that launches are really different in B2B versus B2C.

When dealing with B2B launches, I underestimated how important field enablement was.

When you're launching a new product, not only do you have to educate your customers about it through marketing, but you have to enable an entire field, oftentimes hundreds of people in different roles.

You have to enable your professional services team to do technical demos or technical support. You have to enable your customer success managers to understand frequently asked questions a customer might have. You have to educate your account executives to figure out how they should position this with certain clients. So enablement really is a huge part of launches.

I think what’s also interesting is the cross-functional stakeholders. This is by no means an exhaustive list, but when it comes to launches, the teams we work most closely with are really PMM and thinking about crafting the messaging of a given launch, and then also our various enablement teams for different markets.

It’s definitely a lot less complex than having to tailor these launches to eight-plus different markets. There’s some tailoring when it comes to the marketing messaging, but definitely not to the extent that I've seen in B2C.

I think there are also some nuances in terms of customer segments. We treat our enterprise customers and the products they receive a little bit differently than some of our starter customers. So that's another nuance that I've seen be a bit different between B2B and B2C.

But beyond those differences, I think there are tonnes of similarities, Tim, that you and I have talked about over the years. I think the broad categories of work are similar, and I think we've seen that in just the charters that we chatted through today.

I think the evolution of the function is also quite similar. We've seen the model of scaling and how we've structured our teams.

We’ve also talked about interpersonal skills. I think to be in product ops, you have to be pretty process-oriented, scrappy, empathetic, a great stakeholder manager, and a really well-rounded jack of all trades to be able to do it all.

And then finally, I think we've both seen that hiring is a challenge for both of us.

So again, this is just scratching the surface of B2B versus B2C product ops, based on our two unique experiences. I'm sure there are other folks who might have lots of other thoughts and opinions.

B2B vs. B2C product ops

6 top tips for success in product ops


To close it off, Tim, given everything we've talked about today and all the conversations that we've had over the years about product ops, what are your top three pieces of advice for folks?


My top three pieces of advice are:

  1. Don't jump straight into the biggest problem areas. That’s something I've done in the past. Assess effort versus impact, and really strategize on the most effective way to create impact going forward with your company.
  2. Don't copy what others do content-wise. The reason I say that is because every company is truly unique, and therefore will comprise of its own unique problem statements, etc.

Your company's pain points, Shintaro, will be very different to my company's pain points. So, therefore, create your own strategy to approach those, and don't necessarily copy what others do.

  1. Learn through experience. This one really resonates with me. There's no need to try and get something perfect from the very, very beginning. Learn from experience, fail fast, and fail right. But more importantly, take the learnings onboard, and reiterate.


My top pieces of advice are:

  1. Start small. If you're launching a new process or trying out a new embedded model, start with one pod or one product team before you roll it out to everyone within the product development organization. That way, you're able to iron out all of the kinks for a given process or tool before it impacts a lot of people.
  2. Solve customer pain. In this case in product ops, your customers are PMs, engineers, designers, and go-to-market folk. Have a really good pulse on what their biggest pain points are today and continuously try to solve them.
  3. Foster a culture of improvement. Assume that the processes and tools that you rolled out even a quarter ago or six months ago are going to regress, especially if your team is scaling quickly. So continuously be improving and always have that lens on how you can make things better.