How to Build a Customer-Driven Product Team

David Cancel

Business of Software

About David Cancel

• 5x Founder / 2x CEO

• CEO/Co-Founder, Drift

• Chief Product Officer, HubSpot

IPO: HUBS

• CEO/Co-Founder, Performable

acquired by HubSpot

• Owner/Founder, Ghostery

acquired by Evidon

• CTO/Co-Founder, Compete

acquired by WPP

• Investor/Advisor/Director to Various

Companies and VC Funds

Why do we need to listen to our

customers?

Here’s why.

EMV cards solved one customer problem

(security), but at the same time they

created an entirely new problem …

Ugh.

Being customer-driven today means

putting the needs of the customer first.

It’s not about coming up with the solution

that you think will work best …

It’s about continually communicating with

your customers so you can understand

what solution will work best for them.

And for software companies today, that

means avoiding Waterfall and Agile.

What's wrong with Waterfall and Agile?

They’re outdated.

Waterfall and Agile made sense in an era

when talking to customers and getting

feedback was hard.

But today, there’s no excuse.

Why build software in an internet-

connected world and not lean into the

advantages of that ecosystem?

The bottom line: customer expectations

have changed.

Do you honestly think customers are going

to stick around until you fix that bug in your

next release cycle in six weeks?

Your customers don’t operate in six-week

release cycles.

They don’t think about weekly sprints.

They don’t want to hear, “It’s on our

roadmap for next quarter.”

Ultimately, every company is here to serve

customers.

Discovering the Customer-Driven

Approach

In 2009, I started a company called

Performable.

And we had the same problem in the early

days that all software companies have.

A product manager or myself would try to

convince an engineer that we had to do x,

or do y, or that we had to fix this thing.

Of course, engineers are usually skeptical,

so they would push back and say it was

going to take too long and this and that.

But because we had more customers than

employees, everyone at the company —

including engineers — had to do support.

And all of a sudden, the things that we

were trying to get engineers to do, they

started doing on their own.

And they were doing them immediately. It

would take them 5 minutes when before

they would’ve argued for weeks.

So we started to ask them, “Why did you

do that?”

And they’d say, “Oh, well I talked to three

customers and they all had this problem,

so I went in and fixed it.”

This was a breakthrough moment.

Our engineers had the autonomy to go and

solve problems that they were hearing

about directly.

So we started to build a methodology

around this idea of having engineers linked

directly to our customers.

Customer Feedback: The Old Way

Customer Support PM Engineer

Customer Feedback: The New Way

Customer Engineer

Sure, cool idea. But does it scale?

In 2011, Performable was acquired by

HubSpot, and I went on to lead product

there as CPO.

I built that team from about 50 people to

around 200 by the time I left (which was a

few weeks before we went public).

When I first got to HubSpot, I asked

myself: “How do we build teams so they

are as autonomous as possible?”

So at one point, I just made it up …

We’re going to have engineering teams

that consist of three people.

The Three-Person Team

Engineer Tech Lead Engineer

With just two people to manage, tech leads

could spend 80% to 90% of their time (if

not more) coding.

The small team sizes also meant that

everyone on a team could sit together.

As a result, most teams did away with

traditional meetings and daily stand-ups.

So we had these three-person teams, and

each team owned a complete, customer-

facing product …

… from the presentation of that product,

down to the operation of that product, to

the support of that product.

We paired up each of these teams with a

product manager, who would usually work

across multiple three-person teams.

Then for each PM we had a dedicated

designer, as well as a dedicated product

marketing manager.

Designer PM PMM

Engineer Tech Lead Engineer Engineer Tech

Lead Engineer

The Customer-Driven Product Team

In order to scale, we needed the

engineering teams to own the solutions.

The PM, meanwhile, owned the customer,

and worked with the designer and PMM to

process feedback and iterate/prototype.

This structure allowed the people closest

to the problem to come up with the

solutions and then test those solutions with

the actual customer.

Getting Buy-in

In order to get company-wide buy-in for

this approach, we needed to have

accountability alongside autonomy.

There is no autonomy without

accountability. That’s something totally

different—that’s anarchy, not autonomy.

So all the teams were accountable and

transparent about the metrics they were

driving toward.

One thing we did that really helped:

We had metrics that measured teams not

only on the success of their external

customers, but also on the success of their

internal customers.

There were point people across the

organization that worked with Product to

make sure we hit our internal goals.

So each three-person team had a

counterpart in Sales, a counterpart in

Support, a counterpart in Success, and a

counterpart in Marketing.

Sales Support Success

Engineer Tech Lead Engineer

Product’s Internal Customers

Marketing

And each team shared public internal

metrics with each of their counterparts.

Example: Support. Each team was

measured on decreasing the call-drivers

on the list that their Support counterpart

had created each month.

Example: Sales. Each team was measured

on fixing the issues and adding the

features that their Sales counterpart had

prioritized based on win/loss data.

That shared accountability, coupled with

transparency, bought us a lot of freedom

…

… including the freedom to not

have things like roadmaps and

version numbers.

The way I think about it: those

things (e.g. roadmaps) are

company problems, not customer

problems.

Customer needs will inevitably

change over time, which means

your product will need to change

too.

There is no real end-goal. The

end-goal is evolution.

The only thing that I pushed for

was that teams shipped as soon as

possible.

I eventually got to the point where

our teams were shipping 500 to

600 times every single day.

Instead of having two to three

releases per month, we had

thousands.

We put products into the hands of

beta users immediately so they

could help us correct and iterate

on our direction.

The proof of this new approach

was in the results, and those were

results we saw directly from

customers as well as from within

the teams themselves …

After implementing the new

structure, our product team had

the highest employee NPS score

of any team in the company.

My Framework for Processing

Customer Feedback

Every company in the world will tell

you they are customer-driven.

But unless you actually make the

structural decisions to ensure it,

it’s meaningless.

In addition to structuring your team

to solve for customers, you also

need to put structure in place for

processing customer feedback.

I like to think about customer

feedback as falling into three

buckets:

1. User Experience Issues

• How do I …

• What happens when …

• I tried to …

2. Product Marketing Issues

• Can you/I …

• How do you compare to …

• How are you different than …

• Why should I use you for/to

…

3. Positioning Issues

• I’m probably not your target

customer …

• I’m sure I’m wrong but I

thought …

Separating customer feedback into

these three buckets can help

ensure you’re using your time

effectively.

People often misinterpret being

customer-driven as focusing only

on major improvements/features.

What I have learned is that

customers appreciate an

incremental approach.

An incremental approach shows

customers that you are listening to

them and making changes based

on their feedback.

Remember my example from the

beginning?

No one was listening to them.

Need help becoming a better

listener?

Check out what I’m up to at Drift.com