David Cancel
I believe that in today’s world, helping is the new selling and customer experience is the new marketing. Companies that fail to adapt, and that fail to listen to and communicate with their customers, will inevitably lose out. (Location 161)
Agile and Waterfall were created in an era when communicating with customers and getting feedback was hard. Those approaches made sense in a context where you had no connection with your customer (because you were shipping a product that got installed or put in a box). (Location 200)
Customers find value in being part of a community, and being part of that journey of creating the product. (Location 213)
It’s called Responsive Development (RD). RD is based on a set of principles that I’ve been battle-testing since my Performable days: (Location 225)
In order to implement Responsible Development at Drift, we created a framework that we call Burndown . This new approach to creating and improving products allows us to provide maximum value to our customers. (Location 249)
When you spend more time talking to “internal stakeholders” than your customers, you’ve lost the ship. That’s the truth. It’s a failure that can sneak up on you. (Location 257)
We built everything at HubSpot around having an engineering-led organization. And we built the engineering teams around this idea of being small and autonomous. (Location 337)
The three-person engineering team ended up working because it was so small that a tech lead could manage the two other engineers on a team without devolving into becoming a full-time manager. (Location 353)
So we had these three-person engineering teams. And the core thing for each engineering team was that the engineers had to own a complete, customer-facing product -- from the presentation of that product, down to the operation of that product, to the support of that product. (Location 360)
Our model was always the servant leadership model, meaning the higher your title, the lower you are on the totem pole -- and the more your job is to support the individual contributors and the customers above you. (Location 397)
Getting Rid of Roadmaps Customers care about being heard, and they care about having their feedback taken into account and knowing that something is being done because of that. They don’t care about when the next version of your product is coming out. (Location 431)
The problem with product roadmaps, however, is that they often satiate company curiosity more than they solve customer problems. I’ll give you an example. (Location 443)
Roadmaps solve for the company not the customer. (Location 452)
After implementing the customer-driven product model at HubSpot, our product team had the highest employee NPS score of any team in the company (Location 543)
At Drift, there are lots of ways we are communicating with customers. But communicating alone isn’t enough: We’ve also made sure our internal incentives are aligned with our goal of serving the customer. We set up all of our metrics internally -- both for the engineering and product teams, as well as across the entire company -- to be metrics that are proxies for customer success. (Location 561)
As the CEO, or a leader within your company, getting out of the way and doing everything you can to support those individuals on your team is the best thing you can do. It’s uncomfortable, it’s probably not what you’re used to, but it’s the way that innovative companies have to work today if they want grow. (Location 597)
My ingredient list for achieving HYPERGROWTH (Location 601)
4. Iterative Approach After accountability, this is the ingredient that most people get wrong. They interpret 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. It also turns out that most of the biggest impact items you can improve are user experience issues that are preventing a customer from using your product fully. (Location 622)
So maybe, without even knowing it, we were self-selecting for the kinds of engineers and PMs who enjoyed talking to customers -- so it kept naturally reinforcing itself in the culture. (Location 662)
Separating Product Releases and Marketing Releases It’s a common mistake I see people make: taking the product release and marketing release and making them the same. (Location 680)
And that would give the product marketing team time to go back to those customers so that when we had a marketing launch, we could have case studies, examples, and real data. The takeaway: With any of your releases, work with marketing so that you always have separate tracks for product releases and marketing releases. (Location 692)
At HubSpot, sales would be studying their win/loss data: Which deals did they win, which deals did they lose. Then they’d come up with a list of features and functions that they heard about from the prospects that didn’t become customers. It was sales’ responsibility to prioritize those issues and feature requests for each product team, and then we’d commit to work with them to deal with those issues to add those features. (Location 717)
So we’d look at those quantitative metrics, and then we’d have more qualitative ones, which included: (Location 737)
Making Customer Research a Priority Our best insights come from user testing and customer research. A lot of this has to do with getting into the daily practices of the customer. (Location 749)
So we learned way more by having those interviews and watching what they were doing, and seeing their daily practice, and seeing how they had to go through ve different apps to do something, or download something into Excel. (Location 766)
I have earmarked in my schedule a certain percentage of my time that I’m always out talking to customers and prospects and learning from them. I try to organize these meetings to happen in-person because I want to see the customer in their natural environment. (Location 778)
The Spotlight Framework 1. User Experience Issues (Location 814)
We need to get outside of the building and talk to customers, and we need to ship as soon as possible, because we need to find out how much of what we’re building is wrong. (Location 896)
Your team needs to be able to move fast enough to make changes based on product usage and customer feedback -- not because something is next on a roadmap. (Location 901)
While we used to organize product updates into scheduled releases to help our marketing and sales teams, under David’s leadership the team instead made rapid product fixes and improvements to focus on getting better product to customers as fast as possible And while internal stakeholders used to debate at length what should get added to the product next, under David’s leadership we ended the debates and delegated it to him and the product team guided by customer feedback to determine the high priority product updates. (Location 935)