How I Built a High-Performance Product Culture Across a Fully Distributed Team

The best product teams I’ve been part of had one thing in common: everyone understood why they were building what they were building. Not just their piece of it. The whole picture.

That sounds obvious. In practice, it almost never happens by default.

At Cloudbeds, I worked across a fully distributed organization. Engineering in one timezone, customer support in another, sales spread across markets, leadership pulling in multiple directions. Getting all of those people aligned around the same product reality was a daily job, not a quarterly all-hands.

Here’s how I approached it.

Speaking engineering’s language, not translating for them

Most PMs treat engineering as a delivery function. You write the spec, they build it, you ship it. That model works until it doesn’t, and it usually stops working right when things get complex.

My background as a software engineer changed how I operated in every product role I’ve had. I didn’t just hand specs to the engineering team. I sat in architecture discussions. I understood the tradeoffs they were making. I could tell the difference between ‘this is genuinely hard’ and ‘this isn’t the right approach.’

That changed the dynamic. Engineers stopped treating me like a requirements machine and started bringing me into their thinking earlier. When they had concerns about a technical decision, they’d raise it because they knew I could engage with it meaningfully. When I pushed back on an estimate or a proposed solution, they knew it was coming from somewhere real.

One thing I noticed over time: engineers in distributed teams tend to stay in their lanes. They do their work, they close their tickets, they don’t always understand the broader business context. I made it a point to share that context deliberately. Why are we building this? Who asked for it? What happens if we don’t? What does success look like for the customer?

Something shifted when I did that consistently. The introverted engineers who rarely spoke up in cross-functional meetings started contributing ideas. Not just technical ideas, product ideas. They started caring about outcomes, not just outputs. That’s a culture change, and it doesn’t happen through a workshop. It happens through a hundred small conversations over time.

Customer support as a product intelligence system

Customer support teams sit on a goldmine of product information that most PMs never fully tap.

They hear from customers every day. They know which features confuse people, which workflows break down, which error messages nobody understands. They know the questions that come up repeatedly, which usually means the product isn’t communicating something clearly enough.

I built a regular feedback loop with the CS team. Not a monthly report, a real dialogue. I’d go through tickets with them, ask what they were seeing, share what was coming on the roadmap and why. They started flagging patterns earlier because they knew I was actually listening.

That feedback went directly into prioritization. Some of the most impactful product changes I shipped came from CS conversations, not from user research or analytics. The people answering support tickets often understand the product’s friction points better than anyone.

Feeding the sales team, not just supporting them

Sales and product have a complicated relationship in most companies. Sales wants everything yesterday. Product is trying to build something coherent. The tension is real and mostly unproductive.

What I found worked was treating the sales team as a market intelligence source rather than a request queue. They were talking to prospects every day. They knew what objections came up, what competitors were being mentioned, what capabilities were blocking deals.

I made it a point to collect that feedback systematically and feed it back into the product conversation. Not as a feature request list, but as market signal. When the sales team in Thailand told us they were losing deals because of language barriers, that became a product priority. When they flagged regulatory requirements in new markets, we built those integrations.

In return, I made sure they understood what we were building and why. Roadmap visibility, early access to new features, clear messaging about what the product could and couldn’t do. A sales team that understands the product sells it better and sets more realistic expectations with customers.

Giving leadership what they actually need

Leadership needs to make decisions. To make good decisions, they need clear information about where the product is, where it’s going, and what’s standing in the way.

Most product updates to leadership are either too detailed or too vague. Too detailed and they can’t see the picture. Too vague and they can’t act on it.

I invested time in visualizing roadmaps in ways that made sense for a non-technical audience. Not Jira boards, not sprint backlogs. Clear, visual representations of priorities, timelines, and tradeoffs. When something was at risk, I surfaced it early with context and options, not just a status update.

Leadership teams in distributed organizations are often making decisions with incomplete information. My job was to make sure the product was never the reason for that.

What high performance actually looks like

A high-performance product culture isn’t about velocity metrics or sprint ceremonies. It’s about every person on every team understanding enough of the whole picture to make good decisions in their own domain.

Engineers who understand the customer problem build better solutions. CS teams who understand the roadmap give better support. Sales teams who understand the product close better deals. Leadership teams who have clear product visibility make better strategic calls.

My job was to be the connective tissue between all of those. Not a bottleneck, not a translator, but someone who could move fluidly between contexts and make sure information was flowing in every direction.

That’s what I built at Cloudbeds. And that’s what I bring wherever I work next.