Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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-Found...
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 thi...
Of course, engineers are usually skeptical,
so they would push back and say it was
going to take too long and this and tha...
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
...
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
i...
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
counterpar...
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 cre...
Example: Sales. Each team was measured
on fixing the issues and adding the
features that their Sales counterpart had
prior...
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 w...
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 custom...
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
David Cancel, Building a Customer Driven Product Team, BoS USA 2016
Upcoming SlideShare
Loading in …5
×

David Cancel, Building a Customer Driven Product Team, BoS USA 2016

647 views

Published on

David Cancel of Drift at BoS Conference USA 2016.

See all talks here: http://businessofsoftware.org/2016/07/all-talks-from-business-of-software-conferences-in-one-place-saas-software-talks/

Published in: Business
  • Login to see the comments

  • Be the first to like this

David Cancel, Building a Customer Driven Product Team, BoS USA 2016

  1. 1. How to Build a Customer-Driven Product Team David Cancel Business of Software
  2. 2. 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
  3. 3. Why do we need to listen to our customers?
  4. 4. Here’s why.
  5. 5. EMV cards solved one customer problem (security), but at the same time they created an entirely new problem …
  6. 6. Ugh.
  7. 7. Being customer-driven today means putting the needs of the customer first.
  8. 8. It’s not about coming up with the solution that you think will work best …
  9. 9. It’s about continually communicating with your customers so you can understand what solution will work best for them.
  10. 10. And for software companies today, that means avoiding Waterfall and Agile.
  11. 11. What's wrong with Waterfall and Agile?
  12. 12. They’re outdated.
  13. 13. Waterfall and Agile made sense in an era when talking to customers and getting feedback was hard.
  14. 14. But today, there’s no excuse.
  15. 15. Why build software in an internet- connected world and not lean into the advantages of that ecosystem?
  16. 16. The bottom line: customer expectations have changed.
  17. 17. Do you honestly think customers are going to stick around until you fix that bug in your next release cycle in six weeks?
  18. 18. Your customers don’t operate in six-week release cycles.
  19. 19. They don’t think about weekly sprints.
  20. 20. They don’t want to hear, “It’s on our roadmap for next quarter.”
  21. 21. Ultimately, every company is here to serve customers.
  22. 22. Discovering the Customer-Driven Approach
  23. 23. In 2009, I started a company called Performable.
  24. 24. And we had the same problem in the early days that all software companies have.
  25. 25. 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.
  26. 26. Of course, engineers are usually skeptical, so they would push back and say it was going to take too long and this and that.
  27. 27. But because we had more customers than employees, everyone at the company — including engineers — had to do support.
  28. 28. And all of a sudden, the things that we were trying to get engineers to do, they started doing on their own.
  29. 29. And they were doing them immediately. It would take them 5 minutes when before they would’ve argued for weeks.
  30. 30. So we started to ask them, “Why did you do that?”
  31. 31. And they’d say, “Oh, well I talked to three customers and they all had this problem, so I went in and fixed it.”
  32. 32. This was a breakthrough moment.
  33. 33. Our engineers had the autonomy to go and solve problems that they were hearing about directly.
  34. 34. So we started to build a methodology around this idea of having engineers linked directly to our customers.
  35. 35. Customer Feedback: The Old Way Customer Support PM Engineer
  36. 36. Customer Feedback: The New Way Customer Engineer
  37. 37. Sure, cool idea. But does it scale?
  38. 38. In 2011, Performable was acquired by HubSpot, and I went on to lead product there as CPO.
  39. 39. 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).
  40. 40. When I first got to HubSpot, I asked myself: “How do we build teams so they are as autonomous as possible?”
  41. 41. So at one point, I just made it up …
  42. 42. We’re going to have engineering teams that consist of three people.
  43. 43. The Three-Person Team Engineer Tech Lead Engineer
  44. 44. With just two people to manage, tech leads could spend 80% to 90% of their time (if not more) coding.
  45. 45. The small team sizes also meant that everyone on a team could sit together.
  46. 46. As a result, most teams did away with traditional meetings and daily stand-ups.
  47. 47. So we had these three-person teams, and each team owned a complete, customer- facing product …
  48. 48. … from the presentation of that product, down to the operation of that product, to the support of that product.
  49. 49. We paired up each of these teams with a product manager, who would usually work across multiple three-person teams.
  50. 50. Then for each PM we had a dedicated designer, as well as a dedicated product marketing manager.
  51. 51. Designer PM PMM Engineer Tech Lead Engineer Engineer Tech Lead Engineer The Customer-Driven Product Team
  52. 52. In order to scale, we needed the engineering teams to own the solutions.
  53. 53. The PM, meanwhile, owned the customer, and worked with the designer and PMM to process feedback and iterate/prototype.
  54. 54. This structure allowed the people closest to the problem to come up with the solutions and then test those solutions with the actual customer.
  55. 55. Getting Buy-in
  56. 56. In order to get company-wide buy-in for this approach, we needed to have accountability alongside autonomy.
  57. 57. There is no autonomy without accountability. That’s something totally different—that’s anarchy, not autonomy.
  58. 58. So all the teams were accountable and transparent about the metrics they were driving toward.
  59. 59. One thing we did that really helped:
  60. 60. We had metrics that measured teams not only on the success of their external customers, but also on the success of their internal customers.
  61. 61. There were point people across the organization that worked with Product to make sure we hit our internal goals.
  62. 62. So each three-person team had a counterpart in Sales, a counterpart in Support, a counterpart in Success, and a counterpart in Marketing.
  63. 63. Sales Support Success Engineer Tech Lead Engineer Product’s Internal Customers Marketing
  64. 64. And each team shared public internal metrics with each of their counterparts.
  65. 65. Example: Support. Each team was measured on decreasing the call-drivers on the list that their Support counterpart had created each month.
  66. 66. 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.
  67. 67. That shared accountability, coupled with transparency, bought us a lot of freedom …
  68. 68. … including the freedom to not have things like roadmaps and version numbers.
  69. 69. The way I think about it: those things (e.g. roadmaps) are company problems, not customer problems.
  70. 70. Customer needs will inevitably change over time, which means your product will need to change too.
  71. 71. There is no real end-goal. The end-goal is evolution.
  72. 72. The only thing that I pushed for was that teams shipped as soon as possible.
  73. 73. I eventually got to the point where our teams were shipping 500 to 600 times every single day.
  74. 74. Instead of having two to three releases per month, we had thousands.
  75. 75. We put products into the hands of beta users immediately so they could help us correct and iterate on our direction.
  76. 76. 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 …
  77. 77. After implementing the new structure, our product team had the highest employee NPS score of any team in the company.
  78. 78. My Framework for Processing Customer Feedback
  79. 79. Every company in the world will tell you they are customer-driven.
  80. 80. But unless you actually make the structural decisions to ensure it, it’s meaningless.
  81. 81. In addition to structuring your team to solve for customers, you also need to put structure in place for processing customer feedback.
  82. 82. I like to think about customer feedback as falling into three buckets:
  83. 83. 1. User Experience Issues
  84. 84. • How do I … • What happens when … • I tried to …
  85. 85. 2. Product Marketing Issues
  86. 86. • Can you/I … • How do you compare to … • How are you different than … • Why should I use you for/to …
  87. 87. 3. Positioning Issues
  88. 88. • I’m probably not your target customer … • I’m sure I’m wrong but I thought …
  89. 89. Separating customer feedback into these three buckets can help ensure you’re using your time effectively.
  90. 90. People often misinterpret being customer-driven as focusing only on major improvements/features.
  91. 91. What I have learned is that customers appreciate an incremental approach.
  92. 92. An incremental approach shows customers that you are listening to them and making changes based on their feedback.
  93. 93. Remember my example from the beginning?
  94. 94. No one was listening to them.
  95. 95. Need help becoming a better listener?
  96. 96. Check out what I’m up to at Drift.com

×