How do our product teams work with COps?

We recently added a shiny new role in our Customer Operations (COps) team. This person is called the eCOp.

As well as sounding like a law-enforcing robot, the eCOp is "embedded" (that's where the "e" comes from) in a product team. Their job is to make sure we use the feedback we get to inform the products we build.

Here's how it works, and why we set it up.

How it used to work

Naturally, our COps are the first port of call when customers have any questions through our rapid-response in-app Support.

They're also the first people who hear about our customer's light-bulb moments, like the kinds of products and features people really want to see us build. These insights are really useful for us - you've got to give the people what they want (within reason 👀).

We all do customer support, but we couldn't rely on that to get the insights across. We needed to make sure that these bugs, niggles and great ideas were being properly fed back to our product teams. Then they could work out how to fix them, or turn the ideas into a reality.

We'd have meetings every few weeks to see whether we could actually do whatever the idea was, and find out what was getting in the way.

But as the COps team grew, we grew out of those meetings. "Too many cooks" and all that. People were spending a lot of time talking about what we could do, rather than actually doing it.

Making things smoother

We knew we needed a better connection between the COps team and the product teams. That way, we'd have constant feedback, without needing half the company all crammed around a table.

After some careful thinking, we settled on the "Embedded COp".

"But what is an eCOp?" we hear you say

We like to think of eCOps as the glue between the COps team and the product teams. They sit directly in the product teams to pass on customer feedback and let the teams know about any bugs or ideas for new features.

Every quarter, the role swaps between different members of the COps team. That way, everyone gets an even better understanding of our customers, the products, and the "feedback loops".

In theory it was a solid idea. But these things always have their complications.

The good and the bad

Some things about our new role worked really well from the start.

eCOps gained a deeper understanding of the product teams' roadmaps. 🗺

Our wider COps team upped their knowledge of the mythical inner workings of product development thanks to the eCOp's debriefs.

The working relationships improved between COps and product, because eCOps picked up on gaps in communication.

But the role brought along new challenges, too.

Changing things too quickly could backfire if we didn't really iron out the collaboration.

Some of the information could get too technical and specific for the eCOp in the product meetings, which wasn't a productive use of time.

A lot can happen in multiple meetings, so sifting through notes to feedback key points to the COps team was sometimes a challenge.

Learning is the aim of the game

While we faced some challenges along the way, the eCOp role has proved really worthwhile to boost our internal feedback loops.

Thanks to our eCOps, we've been busy working on how our customers take photos to make the process smoother, and changing the magic link to help people login.

And we're a lot more confident about what we need to work on in the future for the role.

We're going to keep tweaking the way we collaborate between different teams. That way we can scale internally to meet our customers' needs, as we develop new products and our user base (hopefully) keeps growing.

Want to be part of it? Take a look at our job openings.