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

David Cancel, CEO & Founder, Drift

David Cancel is a five-time entrepreneur, two-time CEO, angel investor, and currently the CEO at Drift, a startup that’s making it easier for businesses to talk to their customers. Previously, he was at HubSpot as Chief Product Officer after they acquired his company, Performable.

Every company claims to be ‘customer-driven’. They’ll have framed posters on the wall – “Solve for The Customer.” None of that means anything unless you actually make the structural decisions to ensure it. Why is hiring people who are customer-driven the key to a successful product team? David explains in this talk how to structure product teams to increase employee retention and customer focus. What does a feedback loop directly between the engineers and customers look like? Roadmaps solve for the company not the customer. What solves for the customer is non-stop testing and continuous improvement. Introducing unnecessary process can create barriers to customer centricity. What processes should you incorporate? What metrics should product teams and engineers be guided by?

Slides, Video & Transcript below

Slides from David’s talk at BoS Conference USA 2016 here

Video

 

Transcript

David Cancel: Hello everyone! Before we get started, I’m trying to dominate my team on Snapchat so I’m wondering if you could all say good morning. Yes! Dominated! Tell my story on Snapchat if people want to snap later.

So, thanks for having me back, Mark. I feel inadequate with my shirt, next time you invite me back, I promise I will wear a proper shirt. It’s ok. Awesome!

I’m here to talk about how to build a customer driven team and before we get started, my name is David Cancel in Massachusetts. The proper way you say Cancel is Cancel – I’m Hispanic, my mom was from Ecuador and father from Puerto Rico so you guys can stop guessing where this big, bald brown guy comes from. I grew up in NYC and there it was Can-sell and I now I moved to Boston and it’s just Cancel and I just go with it, I don’t correct anyone anymore. So, I started, this is kind of abbreviated background, I hate going over this stuff, there were many companies before that so I’ve been doing this for a long time, starting companies. I am a serial entrepreneur – when I grew up, that was a bad word, I grew up in the age of entrepreneur meaning something like you sell infomercials or franchises – it was not this idea of technology entrepreneur, at least when I grew up, so I didn’t know what I wanted to be. My parents both emigrated in the US, they worked like most immigrant families, 7 days a week and I kind of grew up in this small business environment. That’s generous – everything that I’ve done since then I can look back and thank my parents, especially my mother, worked harder than anyone ever worked in the technology space. She is my role model and beyond this stuff I have two kids, my daughter who is 11 and son who is 5 and a great wife! So this stuff I just do on the side. Until I started a company called Drift a year before and before that was Hubspot and a lot of the lessons I’ve learned and will talk about come from Hubspot. Good morning, Ash! Good to see you!

Why do we need to listen to our customers?

First we will talk about why do we need to listen to customers? Everyone looks at this and thinks it’s obvious but like most great lessons they are obvious but no one does them. No one actually follows through on this so this is a nice thing to say that rarely people do. And I will go into an example.

This is a very US centric example, this is the EMV card and I recently learned what that stands for, Europay, MasterCard and Visa. This has been in Europe for over 10 years now and it’s just come to the US. In the last year, and everyone who’s from the US has witnessed this rollout, it was horrible for most of us, especially because not everyone has adopted the standard so you’re always guessing. You go into a store and think is this a chip card or a swipe? And that’s a perfect example of what we do as content creators all the time, which is I call like a transfer of the problem. This is a transfer of the problem and for most of us, we don’t care about a chip card so we use a credit card. So, the credit card issuers will tell us that the EMV card is great, it will solve security problems and you will have great and better security because of that and lower cost from a credit card standpoint. How many think that a rollout of the chip card will mean a lower card cost? Nobody! And so this is the perfect example of the transfer of the problem. This is a credit card issuer problem so fraud from a consumer and customer standpoint, the security problem and the fraud problem is a credit card issuer problem. Part of why we get a credit card is not only to have easy access to transactions but it’s the implied security that comes with using the credit card. In our minds, the chip is a company problem but this is the result from the customer standpoint. So, the credit card issuers transferred the problem to us and we have to suffer and stand in line because of this. We will not get lower rates because of this.

And they’ve also done one other thing, they transferred liability to the merchants who process credit card transactions who don’t have the chip card. So, they transfer the problem to the customer, us – the consumer. But also to their other customers which is the merchants. And this is a perfect example to me of what we do each day and a lot of what I’ve done in building a lot of software B2B was this, a transfer of the problem and it’s what we try to correct. And my background is building software for marketing and sales teams and a lot of what we did was move our problem – we want to quantify leads, go through certain steps, be educated and all these things from customers before we spend our precious time talking to them. And we send the problem to the customer, by making them fill out more forms, download more eBooks, jump more hurdles before they qualify to talk to one of us in the company. That as an industry and what I’ve done in my career is an analogy to this, which is transfer to the problem. So, I want to talk about how we can start to fix this problem.

Being customer-driven today means putting the customer first

And so this is a nice to say thing of being customer driver. Today it means putting the customer first and that’s nice but not many of us do this. It’s actually when you put it into practice, a very humbling practice each day. So, you know, of course coming up with a customer driven approach is not what you think from a solution standpoint would work the best but what would solve the customer problem the best. All these things are easy to say and hard to do, I kind of repeat constantly and I think my mantra is everything you need to know is simple but not easy.

The older I get, the more I think like holy shit, it’s really simple, like I knew what I needed to do the whole time but folks, we overcomplicate this stuff, especially in the software stuff. We overcomplicate what we need to do and it’s a simple world, we’re all primates and it’s simple what we respond to.

What’s wrong with Waterfall & Agile?

So, the first thing I will say is that I hate Agile and Waterfall and I am grey haired – you can feel the grey hairs on my face since I don’t have them anymore. I grew up in Agile, and I was a software developer a very long time ago and my teams don’t believe that at all. I’ve worked in the last 15 years believes that I ever coded. Sometimes I have to code for them and show them. So, I grew up in this age and one thing that you have to keep in mind with Waterfall and Agile was a breakthrough from what we were doing before – was that this came about in a certain context and point in time and history and that context has changed in our lifetime.

I grew up building software where you never had direct communication or access to a customer, especially back in the day you were either shipping software through a 3rd party, kind of an intermediary or someone on your team maybe or outside was implementing this at the customer level, kind of multiple years from the time you wrote the software. The important thing is we had to build these methodologies to guess what the customer wanted and we never had the chance to put a feedback loop in the process. So, you go multiple years building software and you’re never able to access the end customer, you have no feedback so these methodologies – we grew up in that time, so that’s what they look like to me.

What has changed is that we all build – even some of us who build – not myself but others who build hardware are building software in a time when all our customers are connected to the software that we’re building. And so what does that mean? That means that you could incorporate your customers and finally have a feedback loop in your process. So, then when I see people who are still stuck in these old methodologies, especially when they become religious about them – Agile it blows my mind where they are making these guesses at what a customer might want and my question is the same. Have we talked to a customer? And everyone looks at me like I’m crazy. It’s one of those things that’s easy to say, that we’re customer connected but people hardly ever do. Instead of talking to a customer, we argue about story point for 3 hours or point allocation and charts and all these things and the extreme Agile approach. So, if we build software in a world where everyone is connected to the software that you build, that means you can incorporate feedback loops into that software build and more importantly, you can release software at a much higher rate than before. To me the transformation was living through my first start up a long time ago, 1996, internet start-up I should say and finally being in a place where we were connected to the end user and we had this feedback loop which we all know.

I think the other thing that’s important in the way we’re thinking about developing software is that customer expectations have changed, there enough companies that are moving at that speed, that the expectations of everyone changed. There are a few consumers who think of themselves software consumers 10 years ago, but the rise of the mobile phone has changed that, everyone is used to the apps, and update process and software being rolled out continuously but in some ways, the app store of Apple brings back the Waterfall process, right? Because you have a 3rd party in between. So, we will skip that. I think customers think anymore in these release cycles we think about and the things we get obsessed about like roadmaps and I will talk more about roadmaps and release numbers – I know I haven’t done them for a very long time and they don’t think in those terms even if internally you may hear that from your sales team who wants to promise something to customers ahead of schedule so they love the idea of a product road map.

So they think about weekly sprints and don’t want to hear that it’s not on our roadmap for our customers. Ultimately, this is another simple but not easy lesson which is every company is here to serve customers. That is the definition of the company, no matter how much there is in the process and how much we geek out in the internals of building software – we are all here to serve customers and I need to repeat this all the time with my teams and companies. Again, it’s something that very few people think about and process.

Discovering the Customer-Driven Approach

Now I will talk about how I discovered what I call this customer driven approach. In 2009 I started a company called Performable and in that company we had the same problems that all of us had in the early days. We didn’t have enough resources. Building software as fast as possible, trying to talk to customers in real time and take that feedback and incorporate it. And we would do the typical thing that most of us would do which is a product manager, in this case I play product manager in the beginning. We try to convince an engineer that we needed to do x-y and this fix immediately or we need it to do it within this timeframe. This is the way that you can always spot this – we would call this internally the drug deal. We tried to do a drug deal with the developer and try to plead and convince and say please, we need to do this! And they would always push back and I was an engineer myself so this guy is coming in and asking for this thing and it’s gonna take this long and it’s this hard and we need to re-platform and that’s written in this other language that’s not supported anymore. So, it’s like I’m just asking you to change a link – would you change a link? I can change it myself, and it’s like we have so much technical debt, you can’t do this.

You’ve all probably heard versions of this and there are good reasons for this pushback and I was probably one of those engineers pushing back and someone long ago. Right? So because we had more customers than employees luckily, everyone at the company including engineers, we were a 20 person company – had to do support. So, we kind of just out of necessity we had this approach we’re all going to do support and that was quite a drug deal, to convince the engineers to do support. Oh, I can’t do support! I’m busy! Look at this article! I got my headphones and I can’t talk to customers. So, it took a lot of massaging to convince them to do it so we finally out of necessity did this thing where everyone was doing the customer support. And we were doing it on the phone, we were doing it via chat, email, any way possible.

And you know, myself and the rest of the team started to notice that engineers were doing things that we had talked about for a long time and we tried to convince then we needed to do this and all of a sudden it’s like what happened? Why did they change it? They started to do things on their own and make changes that for a long time, they do them immediately in 5 minutes. We were talking about them for weeks and arguing why do we need to do this and it’s a priority? We need to re-platform – and all of a sudden we wake up one day and they do it. And we asked why did you do the fix that we talked about? They would always say the same thing – I talked to these 3-4-5 customers and they asked me for the same thing and I went in and did it. Ok, you just did it. Interesting! So that – to me, was this breakthrough moment [laughing].

How many of you remember this? Yeah! I use the Kool Aid Man busting through walls. It was a breakthrough moment. I said wait, I had talked to so many of these engineers about making this or that change and they would argue for a long time and all of a sudden would do them quickly. So, no rocket science needed but we figured out that our engineers had the autonomy to go and solve problems directly without us being in the loop. And so that was all of a sudden we saw that and thought how do we develop a methodology around that? We built this customer driven methodology with this idea of how do we link engineers directly to the customers? If you were to zoom out, this is all obvious.

It’s just like how do we shorten the feedback loop between engineer and customer and so that they’re hearing it first-hand? But this is how most companies operate in and how I operated in the past. Is this how your company operates? Customer send something to support or PM, they try to do a drug deal with engineers, unsuccessfully. Low hit rate – that is how most companies work and that’s how I used to work. And why? Because conventional wisdom told us that’s the way to scale.

See this? This is how you scale. And what we did was kind of flip it and say how do we build a model around this? Where a customer is directly linked to the engineers so that they always share it directly and there’s nobody in between them trying to interpret or add their own colour or spin to it, but that they have this direct connection. So, this was the beginning of this customer driven approach and we started thinking ok how do we organise the teams this way? What does it mean? Does it actually scale? When does this break?

All these things began this grand experiment back in 2009 and 2010 around experimenting this kind of linkage. We saw immediately was the velocity was insane. The speed at which things would be getting done for the customers was amazing! Second thing that we saw was that you know, our customers back then were largely marketers so business users and they were blown away by this! And we’d hear the same thing all the time which is – this guy – I talked to an engineer today and they fixed my problem. So, for a long time, a lot of their answers were like hit refresh, new feature. On the phone, talking to them. And this created this created this incredible good will with customers because we had business users who were largely inside their own organisations and engineers wouldn’t talk to them. Right? And they would say this on the phone all the time. Oh, you’re a company, I’m using your product, an engineer solved the problem. And they are like my company, the engineers don’t want to talk to me, they will say we have a backlog, we can’t talk to you, and IT will do the same. Nobody would talk to me as a business user on the technical side and here I’m having this feedback loop in direct linkage with your engineers. It blew them away. In retrospect it’s all obvious but it was something we had to stumble upon.

Sure, cool idea. But does it scale?

So obvious question is yeah that’s cool, 20 person start up but this is everyone’s favourite question about anything customer driven. Yeah, that’s nice. Does it scale? Everyone is obsessed with that. Most people that I’ve talked to don’t have businesses that scale, but are interested in it [laughing]. They haven’t scaled but they always want an answer to this. Yeah, but that won’t scale. I’m too busy for that. And it’s like ok.

So, in 2011 when Performable was acquired by HubSpot and I had known Dharmesh from my company compete a long time ago when they were starting out and I went to lead product there as CPO. And it was a bit different in that my team was not only product, but also the engineering team, the design team and a little bit of the dev ops team. So, it was everything that had to do with touching a customer from a product standpoint.

Most of the organisation would have a VP of product and one of engineering. In my experience, sometimes that works, if you have an incredible alignment but more than not, I see problems when you have separation between product and engineering because although you may start with the same set of goals, they diverge when you want to optimise with whatever product related things are engineering is trying to optimise for the next re-write. The next kind of infrastructure thing that they may be working on. So, it takes an incredible team to have those two as separate organisations and have them work well together. So, that’s another way of saying I haven’t seen many do it, there are some but I haven’t seen many. When I got to HubSpot, we had a team about 50, a little less, and when I left, my team was around 200. That was engineering, product, PMs, all that kind of stuff. The important thing there is we got to go from this 20-person company to this larger scale and try to scale this customer driven approach. We had lots of other hurdles at the same time, we had to write 100% of this software over there so we went from 2000 – this was every 2500 customers to around 15000 customers in my time there and then went from 200 employees to over 1000 and multiple offices so there was a lot of growth happening and things that had to be right at the time we were experimenting with this and if it would scale and re-platforming 100% of the underlying of all the software including going into new business areas like sales.

So, when I first got to HubSpot I asked myself how do we build teams and not – most entrepreneurs I found don’t like having a boss or being told what to do, at least that’s what my wife tells me. Don’t like to be told what to do. Maybe Mark’s wife tells him too. Never? [laughter]. She is, mine too! And so I asked myself this question, how do we build teams as autonomous as possible and that I would want to be a part of? So at one point I just made this stuff up – so which is like I said we’re gonna have engineering teams that consist of three people and first question, why three? Do we have any data that 3 works better? Why not 5 or 4 or 7? Cause I made 3 up, who cares? We just made it up. If you want to drive an engineer crazy, just give them and tell them some arbitrary thing, that’s like – they are why 3? I read this article about Facebook and they had 5 and it’s like I made 3 up and if it doesn’t work, then we will try 5,7,9,11. Who cares? The point is we start, and then we measure, learn and calibrate and we fix.

The Three-Person Team

And in my time there in about 4 years, we experimented and we kept it around this 3-person model and the way the 3-person team looked was like this. We had the tech lead which is someone who you would traditionally try to push into a engineering management in another company. But we call them a tech lead and we didn’t want them to become a manager. Then we had two engineers that worked on that lead, the 3-person team owned a product for us. And an example of a product could be anything for us at HubSpot something like marketing was an entire product from top to bottom. That 3-person team owned all of it and that was responsible for everything from deciding what they were gonna build next, whether that was a bug, bugs that they were fixing, features, scalability – whatever the combination was, those teams got to decide that, including what tools they used to keep track of all this. Do you want to use Trello, Combine or this or that– at one point it hit me, why should I care? I don’t care. You want to use whatever, so we said to the tech leads and teams, each team individually you decide what you want to use. Each team has its own family and they decide – they want to use whatever, other people look at that and say that’s not gonna scale, we need one platform. Who cares? Why do you want to care about what tools and dictate what tools the team should be using? Let the teams decide that, like why do you want to care about all that kind of process and overhead? Let the teams decide that, what we should care about is what are we delivering to the customers? Are they getting happier? Are they retained longer and upgrading more over time? And if we can measure those things and aligns the teams to those metrics, that’s all that matters. I don’t care if you use Trello or not – actually talking about if you want to use it or not.

So with just the tech lead mono, the important thing was like – the reason I chose three was if you just had two people to manage and those two engineers reported the tech lead, then the tech lead could spend most of the time coding and that’s what they did. They didn’t have to become manager to grow and progress within the organisation. They could spend their time coding and what we did was we had 3-person teams and they sat together and even though we would shuffle people internally, those three would always sit together. The importance of sitting together in this tight space is actually our thought – and it was proved – it led to a lot less overhead needed from a project and process standpoint cause all three of you were together. And let us push back on tech leads and when they would try to bring back process related questions, I don’t know what Ash is doing and it’s like Ash sits about 24 inches from you. And they’d be like yeah but he has his headphones on and coding and don’t know what we’re doing. So, talk to Ash. And I had a conversation like this 100s of times [laughter] and it would expand and sometimes we would have cross-team things and say I don’t know what the team or Mark is talking on. And then you’d say talk to mark and Mark is in Dublin. So? Send him an email. No, I don’t have time for emails. So, Mark actually was transparent on every team is working on – we have an internal wiki and Mark is posting every week what his team is looking at. What’s on the wiki, look! I can’t read it or find anything. One sec! Ok, this list just goes on and on. And finally I say no, we’re not gonna add more process and a project manager cause you don’t know what Ash is doing. This is communication problem. You people, and we all need to learn how to communicate as humans. So, even though you may be shy you need to learn to reach Mark and say what you’re working on or hey, I will just read what he writes anyway. And again, this shit is simple, it’s not easy. It’s very simple – talk to him!

But instead I find what most companies would do if you have a scaling or process problem, we need to add more people and have more meetings and add, add, add. Instead of pushing the problem and at the same time the autonomy – everyone you worked together to find the best way to fix this problem. So, like I said they would sit together, most teams, almost all teams never had any traditional meetings or daily stand-ups. There were some, if some teams wanted to have them they could, but we didn’t care. That’s up to the team. In the end, very few of the teams had any kind of meetings at all. We had maybe two internal meetings we do monthly, but otherwise there were no meetings. And so you know, each of these 3-person teams, like I said, own the complete customer facing product, from the presentation of the product, meaning what the customers saw, down to the operation of it and kind of support of that product. So, they had to feel the pain of the customer all the way through, there wasn’t another team that did infrastructure or overnights. There was this team that owned that entire cycle, right? And that was important because they had to feel the cause and effect back to feedback loops of what they were doing and the impact it had on the customers.

And this is another area where people would push back and say I don’t have time to support my models, we need an infrastructure team, we have thousands of micro-services and we should have dedicated people there. We always pushed back and said no, we are always gonna have customer facing teams. Each team has to have a link with the customer, otherwise you go back to those old days of agile and waterfall and things running on infrastructure projects going on forever. Who’s worked on an infrastructure project that’s been delivered on time? No one, I have yet to see it so far. Like it never happened where it has been delivered on time and there has been a reduction of the deliverables of what you were gonna deliver and that is why we always push back on those projects. They sound good in theory, when we do this re-platforming, things are just gonna magically be better, we will be more efficient and be able to do X-Y-Z. That’s never happened, we re-platformed entire companies without needing to do that. Also at HubSpot, and we didn’t need to say we need these dedicated infrastructure people, and we will run a project for 6 months. No, we said we will deliver every day and we will be connected to customers.

So, these tech teams will be paired up with the product manager internally and he would usually work across multiple teams and each PM had a dedicated designer and dedicated product marketing manager that worked with each PM and designer group. And those product marketing management were reported into marketing and sat within the product team. So, you had three engineers, you had a PM, designer and dedicated product marketing manager. We had a large sales force so we needed to invest a lot in product marketing, mostly facing the sales force and training them. And so we found that by sitting them all together we could get those teams moving faster and with less friction and process than the traditional way.

So this is kind of what it looked like, that design of PM and PMM worked with multiple engineering led teams, on multiple product lines, and they – this team over here spent their time talking to internal external customers and all the tech leads and engineers had to be connected to customer feedback. So, like I said, the PM owned the customer and worked with the designer to process feedback and iterate/prototype and their job was to get out ahead of engineering and the structure allowed people closest to the problems, being the engineers, to come off with a solution and test them live with customers. So, we had this non-stop customer driven approach where all the teams had to talk and get feedback from customers, but they also had to test the software within our customer base.

Getting Buy-in

So getting some buy-in. So, how do you roll this out in a company, especially an existing company? How do you get buy-in from the organisations? And our approach was that we needed to introduce and have transparent accountability for each of these product teams to go with the autonomy we were giving the teams and they really decided everything. Most of the product management work that I see done most by the product manager is project management work and we took it all away from the product managers and moved it so the tech lead had to figure that out. So, a key to scaling which is not how your product managers sort bugs in Agira all day for the engineering team or create spreadsheets or filter things for the engineering team and that’s what I see most companies doing. And they say I’m gonna help the engineers scale by being like a nanny to the engineering team and sorting things and doing this kind of stuff. I would always push back and say let them decide, and sort and prioritise. You focus on customer feedback and iteration. Alright?

And so to me, it’s obvious like without – there has to be with autonomy accountability and most people they think about it and they’re talking about anarchy. They say autonomy is awesome, I get to decide whatever, no one tells me what to do. No, that’s anarchy, not autonomy. Autonomy has a flipside which is accountability and with the right level of accountability then you can enjoy this autonomy. So, all the teams internally are transparent about the metrics they were trying to drive forward. We had metrics that measured the teams and external customers feedback and the success of the internal customers. And this was the key to get buy in to this approach is that we linked up those individual teams with internal customers and in our case, they were customer success, sales, support and marketing. And those were internal – we call them internal because they were proxies for customer feedback that we were getting as a company that the product team might not be exposed to even though they are talking to customers every day and week.

We set up not only metrics to measure external customers but the success of internal customers and the way that worked is each of the product team had an internal goal with each of the organisations, customer success. And so each 3-person team had a counterpart so we would ask the support team and say this is the email marketing team. You guys get to decide and nominate someone on support to be your email product expert and that person is gonna be paired up with this team. And together, they are going to have a set of public metrics that they report on each month. And in the case of support it’s simple, it can be looking at top call drivers for that product. What are the top instances we’re seeing for a certain product? The email marketing program in this example. And we would see here are the call drivers, the frequency of the calls or emails – whatever it is. And then we look at it, is the engineering team driving the calls down? The top calls. And we didn’t have a number we had our hopes on. We didn’t have a top 5 or 3. We were just looking at change and seeing that ok, we’re trying to drive some top call drivers down and if we weren’t in those teams, they had to explain why they weren’t doing that.

We did the same with sales, it was based on win-loss analysis. So, we would look at sales persons, sales expert for a particular product would be linked up and they would have the top reasons or exceptions, top reasons for loss in that product category. Competitor has this feature and whatever it is, it was sorted whatever way they wanted to and then we would pledge to drive that team and some of those down. We wouldn’t say we will drive them all down next month, we just say we will work together and we’re publicly both accountable for driving them down over time. We did that across all other teams.

The important thing about doing this was this kind of pulled back on the need for a lot of traditional micro-management that other teams within the company might want to have on product and engineering. In the form of road maps and version numbers and dates and that kind of stuff because they were working with these teams every day and they had a set of metrics and they were both publicly accountable for. So, each of these teams looked like this, were linked up with a different person and they all reported on the metrics. Go back! There you go! [laughter]. Is that on snapchat? Ok, so like I said each of them had this public internal metrics so support, this was call drivers, sales, win-loss, and they had this shared accountability so coupled with transparency, this brought the teams a lot of freedom.

So, included in this freedom, we didn’t have to have road maps and version numbers and I have a version of these things in this modern way of developing software in real time because these are company problems, not customer problems. Customers don’t care about your road map and your version numbers even though yes, I know, your sales person told you that customer wants to see your roadmap. To me that’s happened to all of us – that’s a different problem. Someone asking you for a roadmap, especially a larger customer, is asking you for something different. It’s not the literal roadmap, but they want to know they’re being heard, that you will do what you promised to do and this is like that you’re there to help them be successful. And so that manifests itself in this weird things like roadmaps which I think are useless unless you ship in App stores so you need version numbers and dates because you have to go through apple still. So, like I said, company problems. So, customer needs will always change so that means our product will always have to change to. To me this is the reason to have a customer driven approach. You need this feedback loop because things are constantly changing in the market. And for us, we always had an idea and still do that there is no end goal. Like our goal – there’s no instate in what we’re trying to do as a team and our end goal is our constant evolution and everything will change and someday we will go from 3-4- to 5. That never happened, but the goal is not these hard rules but that we’re constantly learning and evolving in the feedback that we get from our customers constantly.

Ship It!

The last thing, the only thing I cared about from a process standpoint, was this idea to ship it as soon as possible. I used to say it so much that it became this internal meme. Towards the end, everything I said was like a magic 8 ball. You could predict what I was gonna say so back then we used chat so if you typed ship it, a spinning icon of my face would show up and that happens in drift/slack so ship it is like a spinning head cause I would always yell ship it! The point behind ship it – the people say you will ship crap software – shipping constantly to customers does not mean shipping shit. It doesn’t say ship shit, it says ship it! Right? [laughter].

The point behind this and why this was so important was that this to me, is the thing that is underlying the idea of constant shipping is this idea that I talk about which is that we should always approach – especially building software, but all things in life – that our opinion is wrong. We should go in as product creators and say whatever our idea is it’s wrong by default and we have to ship it ASAP to the customers to try and figure out how wrong are we? 10% or 100%? Are we out of our minds? The only way to tell would be to get customer validation and feedback and if any of you sat through user testing of your own software, you know how painful – no matter how great your idea was and we all think they are great – you’re sitting through one session of user testing and go they don’t know anything, this is so painful! We would have every team doing user testing every week and you’d know when it was a user testing session cause everyone would walk out like this, demoralised. We gotta redo it and it was so awesome in our minds and when we shipped it to the customers, no one – it didn’t work. No one understood. And so we eventually go to this point where we went from daily shipping to 600 times a day to production from our development teams. Down to co-ops and everyone who joined the team, we had this model they had to ship on the first day and continue to ship to each day. So, we had to default we were wrong, put our ego on the side and learn from our customers. Instead of this which is normal, right?

So, we had this idea of these beta groups and we put our software in their hands immediately. So, those times we’d go from internal mock up prototype to ship it immediately and we’d gate that feature so only a subset of people who volunteered for that could use the product and we would continue to ship each day and we were fine with the feedback from them. So, that was the proof of this new approach, the results and the way the teams felt and also the feedback that we were getting from customers. So, after implementing this, we had to rebuild the entire team, implementing the customer approach. We had the idea of employee NPS score, if you don’t do it, you should. And we ended up putting the highest employee NPS score and the highest tension at a time in the last 5 years which was insanely hard to keep and attract new engineers because they love the approach of getting feedback, having autonomy and being in control of what they were doing.

My Framework for Processing Customer Feedback

So that’s the customer driven approach. I want to talk about this framework for processing customer feedback. One of that I got when I tried to encourage people to talk to their customers more is like there’s just too much feedback, I don’t know what to do. I’m drowning and there’s so much noise. Or they just run around like mad men trying to fix problems, right? And it becomes hard to scale. And so I have this framework for processing customer feedback. All right? So let’s jump into that.

User Experience Issues

I think about getting customer feedback falling into three buckets. Most of the feedback we get, especially form the support contacts, falls into this category which is user experience issues. So, this is why we wanted teams linked on with support early on. Most of the issues that you may see from a customer that come in through support aren’t bugged but there are outages. Everyone knows when those are happening, those are obvious but this other class of user experience issues. And these are examples of how do you know, when you can categorise feedback that is user experience issue related. So, when someone says; how do I bla bla? Or they say, what happens when I do this in your software or click this or send this email? Or they say I tried to do x. Like that to me those are like the words the framework I use to say this is probably a user experience issue. If what they’re talking about and it’s something that our product wants to do and people are writing these kinds of questions, it points to some sort of usability problem because they couldn’t figure out how to do something in your software. They didn’t know if they did it, what would be the end result of that or they tried to do it but they didn’t get the expectations that they had in doing so, right? Or that you led them to think so. To me these are important things to focus in on. What I find most teams do is not focus on these but the subject. For example, how do I integrate slack? They will hear a bunch of people say slack and hear them say drift or HubSpot or whatever and they will focus we need more features for slack, everyone asks about it. The point I was saying is how do I slack? They were saying there is some usability issue in the software they couldn’t figure out how to do it on their own so the small percentage of people that are writing to the support, they don’t know how to do it. They know it exists and possible but don’t know how to do it.

Product Marketing Issues

The second bucket of customer feedback are product marketing issues. And these are the type of things that I look for. When somebody says;

• how do you compare to…,
• how are you different than…,
• why should I use you for…;

those are again, if your software or company does the things that they are talking about the subjects here, then these things point to me that there might be a product marketing issue. Whether it’s training people before they sign up, through the signup or onboarding or signing them up after they were onboarded. If they are asking these type of questions, we put those are product marketing issues and user education issues and we work on those.

Positioning Issues

And then lastly, there are some – this is for early company and there’s some positioning issues kind of things that I look for. Feedback like this; especially when you’re young and doing customer development or prospective customers and they say I’m probably not your target customer … again, if they are the person you think should be your target customer and they are saying they are not, you probably have a positioning issue. We ignore this and don’t categorise it correctly but it’s a positioning issue. The same with I’m sure I’m wrong but I thought… again positioning issue. The important thing with this framework is now you have three buckets that you can take the firehose of feedback that you’re getting. If you don’t have a firehose, get one and categorise it into three nice buckets that you can make the feedback actionable. And it can be as simple as having a Google sheet or somewhere that you store this and then you have a frequency count and what category and positioning or usability issue. You can look at them month after month and now in these product marketing issues, these usability and positioning issues. And that’s a way that I find it easy to take customer feedback and make it actionable. Alright?

So lastly, I think for me, doing all this and having this customer driven approach and listening to feedback changed the way I develop software and the thing we want to avoid as creators of software is the transfer the problem to our customers and avoid doing this to your customers. So, if you need help being a better listener, check out what we’re up to at Drift.

Mark Littlewood: Fantastic! I forgot the reason we invited you back is that you have awesome things to say and I’ve forgotten just how funny and dry you are.

David Cancel: I’m very dry!

Q&A

Mark Littlewood: We’re reminded of that. Questions, hands up! Please ask a question, not make a point. Put your hands up and I will try to get them around. Where is the first one? Here!

Audience Question: Thank you, David! It’s always awesome to hear you speak! So I was curious in that setup where you have very small engineering teams that are connected to customers, making decisions, what are your thoughts on removing product managers altogether in that scenario and having those engineering teams be even more accountable? Cause I’m playing with that setup right now and I wanted to know your thoughts.

David Cancel: I’ve never done that, but it’s come up a lot of times with people who tried a similar approach. One thing that we thought about trying is having that designer play the role as a product manager for at least some time in our history, maybe in the early days, to see how that would work. One thing I didn’t mention is I don’t like to hire people who were product managers before. We can go into a whole reason for that, but that is something we haven’t tried yet and we will try it soon and the designer and PM were tightly linked and were mostly prototyping and getting user feedback in dealing with customer so I could see it possibly working.

Audience Question: Hi! I’ve two questions. One is how much – who does that, does the tech lead do that? And second one is QA [laughter].

David Cancel: UIX we had a designer that was designated per team and we did that and we had a separate – two-person team that helped us with usability and that was mostly from scheduling and user testing. So, they worked with our customers and beta customers and doing beta testing and making sure the PMs and designers were not leading the witness with the customer. And from the QA standpoint, we had it internally in the beginning and then we kept running into problems from a shipping standpoint and we tried every model, we tried QA as a service, embedded in teams, as largely automation testers, human testers, combos and everything and we kept hitting the same wall which was engineers were complaining saying they can’t shit, they are testing the wrong things. It just kept going so we got rid of it. So, an engineer said we’re gonna do QA. I said you will do it now and they own the quality metrics of the team.

Audience Question: Thanks for the talk! This talk was the price of the ticket for me. The question is who is in charge? You have a 3-person team and the PM. Who is in charge in general? Is it team leader or the PM? And also when you’re hiring, do you explain to the candidates that this – they will have to work with the customer upfront or do they find it out when [laughter].

David Cancel: You should ask them both! So who is in charge? Engineering lead teams so the tech and engineering teams had all the power really in the system. PMs were there and the designers also to help those engineering teams where we were engineering led as an organisation. And then on candidates, yes we told them and then that led to over time obviously us screening for and selecting for people who were comfortable with this but in the early days there was a group of people who were there and we had to say surprise, we’re talking to customers!

Audience Question: I’m curious in this arrangement, we get so much feedback coming from customers it’s possible to become very reactionary. Is there someone on the team – who is looking further out and providing the vision and providing the next gen view?

David Cancel: The tech leads are working with the PMs, the designers, and they are largely charged with getting far ahead, they are way out ahead and testing things for a good amount of time before they make it back to engineering and they are pushed out ahead. We would as a company set annual teams so they were very high level themes of what we wanted to do and those were not product specs or features we wanted or expectations of what happens when I click this button. And then the themes interpreted it and worked with customers on that. And lastly the product marketing manager would work to get things ready for the sales team to roll things out publicly from a feature standpoint – one thing I didn’t mention was a lot of times we would release stuff all the time and it’s be after general release but we might not talk from a marketing standpoint for weeks or months later and breaking that dependency between a release of software and public release was one of the most important things to do and how things could work because most of the time that never works. Releasing on the same day on the same day you have a marketing even. Another thing I’ve never seen work and I hear legends of it working but I haven’t seen it myself so something breaks or goes wrong, if you have a sales team they aren’t properly educated on how to sell it. If you don’t have a team you don’t have the right education so things don’t line up so let’s release and get many versions out there and give the PM enough time to have case studies to have the stuff ready for a real marketing release.

Audience Question: Earlier in your talk you said something about communication and it was really specific. You talked about how people came into your office and said this person here, what are they doing? And then you would give them the answer to go and talk to the individual and they would make up excuses. What would you do with the people who made those excuses?

David Cancel: One, I didn’t have an office to clarify. Two, I didn’t even know where I sat. it was just a random area. What would I do if people would keep having the same excuse over and over is I would make a change in the team. It’s very simple, not easy. We made many changes on the team as we learned and we just needed – we can’t change someone’s religion if they are opposed to this idea of communicating with other people it’s built in and it’s fundamental to every company and how we work and we need to learn how we communicate and we would coach them – it would take a long time, there a few people that would do it because of that, but most would learn how to communicate and get comfortable on how to communicate and create strong bonds.

Audience Question: The overall structure in ratio of those teams and how it was divided out. You have a sales staff and it sounds the engineering team you were able to keep a high number. What did the ratio looked like in the end? 50/50 developers to staff?

David Cancel: Good question! It changed over time. It was largely engineers. We had in the beginning 3 to 5 PMs and everyone else was an engineer or designer. And then towards the end of my time there, we probably had less than 10 PMs by that time we had like associate PM and other types of PMs who were learning but the rest were engineers. And we didn’t introduce directors or VPs so I had in the end two VPs of engineering and I reported to me two VPs of product that were reported to me but beyond that it was very flat. We had this model which I didn’t mention and it was the servant leadership model and it’s an inverted pyramid and the people that have the most control of the system are the customers on the top, then the individual contributors in the team. They had the most power in the system, they decided everything. And then the higher time and the lower you are the less you control it.

Mark Littlewood: Fantastic! I know there are other questions but I wouldn’t even attempt to go through them because we’ve gone through them. Do you want to do a lunch? Come and find David and talk about it.

David Cancel: Whichever!

Mark Littlewood: Thank you very much! Really good stuff [clapping].