Tanguy Crusson: evaluation

Transcript context

…Got it. So the advice there is just limit how many people get exposed to your very early product, even if it's going to hurt your numbers. You don't want to cause people to be like, "What the hell are you doing over there, man? [inaudible 01:23:17]." So [inaudible 01:23:17] your numbers is now the interesting one. So how do you frame success and how do you define metrics when your goal is basically to work with a small number of customers for a super long time? So that's what I ended up defining for this, is based on a term that was used at Atlassian that I tried to formalize it into something that everyone could refer to, which is the Lighthouse Users Program. And so the principle for it is it's a program, so it's an official thing. We have hundreds of thousands of customers at Atlassian, but we would only build the experience for a small number of them. And so there are stages to it. The first stage is we work with 10 and we prove that the problems that they had are the things that we solved and where we spend most of the time for the first 10 Lighthouse Users is to explain why they are the Lighthouse Users. Everything that explains why we believe they are a proxy for every customer that we serve afterwards. We then have this stage from 10 to 100 where we recruit more customers, but we're still not in the fully self-service, don't need a lot of onboarding stuff. We're still testing out the value, but we're testing the different variations in the scenarios that people face to make sure that the core solution that we've got can cater for those. So there's a lot of different options and different security needs. There's a lot of subtleties that you catch between 10 and 100. Then we get to a stage where we're like, "You know what? It's good. It solves people's problems, but it's not self-service. We just need to explain stuff. We need to work with people on Slack. We need to work with them and answer a lot of support tickets or do a lot of Zoom calls to explain stuff." Now we need to get from 100 to 1,000, and by getting there we basically need to solve all of that and after that we graduate. So basically by detailing that and explaining all the success criteria in between, it helps to define success in that in the make phase, we've got 10, 100, 1,000, and then people can understand exactly where we're at there, and the types of questions we're trying to answer. In the 10, we're answering every question with a user, snippet of a video call with them, either talking about their problem and solution but showing the product and how they solve with it. That's how we wanted our stakeholders to view it, which is it's very qualitative, but have it felt from the user's perspective. It's different when we go from 10 to 100, from 100 to 1,000, but for each of those there's a playbook for how you go from one to the other. That helped us because we could then clean the space to do the right thing and we will not ask to hit, for example, a multi-active user's number or number of customers' number or percentage of users who use this number. Because it's very qualitative still when we're at that stage. That is super cool and super interesting. And it's along the lines of the gates. It aligns with, at each gate, here's how many users we're looking for. Basically, it sets expectations for what success is, keeps you from having to scale things too early. It's such a cool idea. And you call it Lighthouse Users, like the Lighthouse Users Program?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.