As a VP Product, my job is to make the team excellent at what they do.

When I moved from being a founder who wore many hats (doing all of the work) to making my first hires, and then on to a VP role, there was a voice in my head that you may recognise: "It'll be faster and better if I just do it myself".

Resisting that pull, and instead focussing on developing the team, gets you to that magical point where you can say "Wow, that was done better than I could've done it". That's our job as managers and leaders, and how we scale our impact through teams.

I took over a product team whose work wasn't having the impact it should've been, even though we were shipping. We were producing output, but not seeing meaningful outcomes. To figure out why, I went back to our inputs, examining how we were building.

Going back to the inputs

I observed the product development process and spoke with the PMs and designers to understand our approach.

Very quickly, I spotted a missing key input in our discovery process: speaking with customers. It wasn't happening much at all, and when it did happen it was sporadic and unstructured.

Of course, the solution is not just telling the PMs and designers to talk to customers more. I needed to understand why it wasn't happening. It's often a natural habit for PMs to talk to users, so what was stopping us from developing that habit?

I found a few key reasons:

  • We struggled to find the right customers to talk to in the first place.
  • We were worried about interfering with Sales or Customer Success: who owned the relationship?
  • Our team lacked confidence in conducting customer interviews.
  • We weren't sure what the output of an interview should look like- what insights to capture or how to use them.
  • There was no shared sense of how many interviews we should do or how often we should be doing them.

This was a great starting point. I knew I could work with this list of challenges.

How I develop capability in a team

With these insights, I set out to develop our team's customer centricity. My approach was to remove friction, hone the craft, set up habits, and show that the work was worthwhile.

Remove organisational friction and create alignment

First, I tackled the organisational friction. One issue was the need to ask for permission every time. PMs were reaching out to account managers and customer success managers to ask for permission before speaking with their customers. These ad-hoc and infrequent request made Sales and CS wonder why product suddenly wanted to talk with a customer they'd built a relationship with. Asking for permission caused delays and uncertainty.

I worked with our VP of Revenue & CS to understand his team's concerns about us speaking with customers. It turned out to be really simple: if there's an open support ticket, active sales deal, or renewal coming up, an outreach from a PM could confuse the customer and make us look uncoordinated. I completely agreed.

We made clear rules of engagement for product conversations with customers. PMs could reach out to customers without asking for permission each time by checking some simple criteria. The VP Revenue and I communicated our shared, customer-centric vision to both teams, highlighting that deeper customer insight will allow us to ship more impactful products, benefiting everyone.

Now, both teams could operate with consistency, clarity and understanding. We had leadership alignment and a birds-eye view of how these interactions should work. By removing friction and ambiguity, we enabled our teams to do a better job without delays or misunderstandings.

Work on the craft with them

Next, we turned to honing the craft of customer interviews. Some PMs were better than others at things like outreach and how to run interviews, and each person had been doing it differently with varying results.

My goal wasn't to hand down a rigid script of templates, but to share my experience about what works, what doesn't, and the pitfalls and opportunities, so that the team could find what worked best for them and improve their skill.

I had just run a batch of 20 interviews myself, so I used that experience as a case study. I walked the team through how I executed that batch: for example, using our sales win/loss emails to find good customers to talk to, and screenshotting a Salesforce record to use ChatGPT to write a personalised interview request email. I shared practical tips, like to expect a single-digit response rate to cold interview requests, so send out at least 50 invitations if you need a handful of interviews. And to send polite follow-ups after 3 days and 7 days to bump up the response rate in busy inboxes.

We also brought in others' expertise. One of our Product Marketing Managers was even better at outreach than I am, and she shared her own templates and learnings: things like crafting a great opener, keeping the message short, and making a clear ask. These sessions surfaced a lot of questions and concerns, and we all learned from each other.

Next, we tackled the interview technique. Some PMs weren't sure what to ask once they got the customer on a call; others conducted calls with a strong idea of what they wanted to learn, but tended to ask leading questions.

To build our interviewing muscle, I introduced the book Deploy Empathy to the team. It's a practical guide to planning and conducting customer interviews, and then distilling the learnings. One of our PMs volunteered to lead a weekly bookclub for it. We read a chapter or two a week, and then discussed our takeaways and questions. This group of peers learning together provided structure and normalised that everyone was still learning how to do this well.

Soon, interviews started getting booked. I offered to sit in or even lead the first few interviews for any PM who wanted to build confidence by watching how it's done. Some took me up on that; others preferred to conduct the interview themselves and then have me give feedback afterwards. Over the next few weeks, I saw all of us getting better at running tight customer interviews. We were getting clean signals from customers, with unbiased insights, to inform our product decisions.

Everyone has their own style of course, which makes our craft personal. As leaders, our job is to share what we've learned, and coach the team through practice. Sometimes that means demonstrating techniques live, other times it means observing and giving constructive feedback. Not only was our team improving rapidly, but it turned out to be enjoyable and rewarding.

Help them build habits with simple systems and clear expectations

With these skills in place, we needed habits and systems to sustain this customer-centric approach. Clear expectations mean the team doesn't need to wonder if they're doing a good job, they'll know it from the process. I wanted to switch us from doing big batches of customer interviews sporadically, to developing a habit of continuous customer curiosity.

I set a baseline expectation that each PM should interview at least 3 customers a month. This was an intentionally low and achievable number. The point wasn't a big number, it was to ignite a habit of customer curiosity. I wanted talking to customers to become second nature. It should feel natural to jump on an interesting support ticket or sales call, to read through a candid customer review and understand why they wrote what they did, to comb through new signups. To be consistently curious about our customers.

We also put in place a few lightweight systems to support the habit. I created a simple template for synthesising each interview. Using the same template for all interviews made it easy for us to review each other's because everything was in the same format.

We set up a shared Slack channel where we'd announce when an interview was scheduled, and later share the completed interview synthesis. This made our customer learning visible across the team, creating momentum and a bit of positive peer pressure. I also set up a lightweight repo of insights to collect them in one searchable place to draw from in our work.

These simple systems and clear expectations took a lot of the cognitive load off the team. Nobody had to invent their own way of doing it, there was a process and everyone knew the bar they were expected to hit. We started small to ensure the habit would stick. Wins and learnings were shared openly in our Slack channel, which helped to reinforce the behaviour. Over time, that habit began to compound. What started as a daunting 3 interviews a month commitment evolved into a genuine mindset of customer curiosity, rather than just a goal to hit.

Make the work matter

Finally, I had to make the work matter by closing the loop from interviews to impact. Initially, there were voices outside of our team (and some doubt inside our team too) asking "why do we need to speak to customers at all?" I was convinced from experience that speaking with customers would be the difference between launching features that flop and ones that truly resonate. But to prove that, the insights we were gathering had to visibly influence our product decisions and then lead to real results. Only then would this new habit feel meaningful and worthwhile to everyone.

I noticed in product and leadership meetings that there used to be a lot of "I think that we should..." or vague "Our customers want..." statements being thrown around. Customer stories were rare, and when we did mention customers, it was the same three examples repeated over and over. Old insights that didn't represent our Ideal Customer Profile (ICP). That had to change. Now that we were frequently interviewing customers, we needed to pull those insights into our decision making.

We started referencing specific customers and their stories in our product one-pagers. Instead of saying "Many users are asking for X", PMs started saying "Customers A & B from our interviews last month struggled with Y, which is why we're prioritising feature X." It immediately made our reasoning more sound.

I revamped our roadmapping process to start with a session about what we learned from customers in last quarter. New roadmap ideas had to be backed by evidence: which customer segment does this benefit, and what have we learned from specific customers that lead us here?

When the PMs and I presented the roadmap to leadership, we could clearly articulate why each item deserved to be there, and why some popular asks weren't there. We cited actual customer learning, switching the conversation from opinions to evidence.

At the end of the quarter in our leadership and all-hands Quarterly Business Reviews (QBRs) we highlighted real customers' quotes and traction to demonstrate the value we'd shipped. We tied those successes back to business metrics, closing the loop: here's what we learned, here's what we built, here's the impact. That created energy around strong product velocity in the team.

No one was asking why we were talking to customers anymore, the value was evident. And the product team felt it too. PMs and EMs could see that the hard work of continuously speaking with customers was paying off in tangible ways: features were getting adopted, our enterprise win rate more than doubled, we closed record sales deals, and the rest of the company was regaining trust in the product team.

One memorable moment was when a previously churned customer, who one of our PMs had interviewed, came back to us. We'd acted on their feedback. Not only did they come back, but they became one of our strongest public advocates. This was a huge win for the company, and reinforced the value of speaking with customers in creating products that really matter to our customers.

There was some initial skepticism about investing time in all of these customer conversations. As leaders, we sometimes have to champion efforts that we believe in, before the results are obvious. When we follow through and highlight every win, we prove the effort is worthwhile. In this example, we reinforced the value of a customer-centric approach to building product and rebuilt trust in the product team through the company.

The pattern I use to help the team do its best work

This is the pattern I use to develop new capabilities on product teams. First, identify the capability that needs building, in this case it was customer discovery. Next, remove organisational friction and get alignment so that the team has a clear path. Then, hone the craft together. Share knowledge, demonstrate techniques, and coach. So the behaviour sticks, help the team build habits with simple systems and clear expectations. And finally, make their hard work matter by tying it to impact and celebrating the wins.

I still enjoy doing the hands-on work myself. I love talking to customers, digging into problems, and forming my own product hypotheses. But as a manager and leader, I've learned to judge my success less by my individual output and more by how good my team is at their jobs. It's rewarding to step back and see the team consistently delivering work that's better than what I could have done. When I see that, then I know I'm doing my job right. My job is to make the team excellent at theirs.

My job is to make the team good at theirs