PTH Conf 2015 - Shai Wininger Fiverr

Okay, hi. So today I want to talk to you a little bit about culture, and specifically about what I call data-driven culture. And I think that most of you have probably heard about Fiverr. Maybe we can start with a little show of hands: how many of you have actually heard of Fiverr and visited that site?

Okay, so Fiverr was actually created in 2009. That's more than five years ago. And when I started the company, I decided to, instead of being the CEO, I wanted to run the product and really be involved in the technology and the making of it. And so I was the CEO of the company for the past five years. And just to get a little understanding of what Fiverr is: Fiverr is currently the world's largest marketplace for small services. We started off just like any other small startup, but in the last five years we became a large company. I'll tell you a little bit about the process that we've been going through in those years. So just to get a sense of how big this company is right now and what type of scale we need to handle: we have orders in, you know, every less than four seconds, and we have billions of requests that we have to handle in the system. We currently have hundreds of people working for Fiverr and running, you know, hundreds of servers and pushing hundreds of deployments each day. So that's scale. But unfortunately, it's not that easy to reach. Scaling for Fiverr was pretty hard. And if you look at this picture here, that's actually Fiverr in the first office that we had. That's us sitting in the balcony. It's a very typical view of us if you would come and visit us at those days. That's the team, that's the company. And at that point we were already handling, I guess, hundreds of thousands of dollars per month in sales. And half of this team is actually customer support. So that's a very, very small team. And it was a lot of fun. You can imagine that working with just a small group of your friends and drinking a lot, smoking a lot, eating a lot of junk food is a great experience. And it's very hard to beat when you start to grow and become a corporate like this. Now, this is Fiverr about a year ago. That picture taken from our offices in Tel Aviv. We currently have offices in Tel Aviv, New York, Amsterdam, Chicago, and Miami. So that's just a small part of the team that we have back in 2014. And as you can imagine, that's a long way to go from that, you know, that day in the balcony with the beers and all that stuff. So we had a lot of growth pains. And I think that the first one that, you know, I guess a lot of you know pretty well is the fact that when you add developers to your team, it doesn't necessarily mean that you get more productive. It doesn't mean that you can do things faster. And that was for us a big problem because we really wanted to scale fast. We wanted to kind of, you know, maintain our position as a market leader. And for that, we had to push a lot of new features to the product and really come up to par with other products that were out there. So we hired a lot of people and we couldn't maintain velocity. The second thing was that we discovered that even if we could have got better at doing things faster, we couldn't do more than one big thing at a time. We used to work on a big feature and then all the others were kind of working on bugs or smaller iterations and things like that. Everybody knows boring meetings. The more people you add, the more meetings you're gonna get. People want to be in the loop. They want to be part of what you're doing, and that means a lot of meetings. And of course, the famous bottlenecks, right? You have more people, you need to manage them, and you have a lot of kind of bottlenecks that, you know, you have a team who needs design services from one place and they need QA services from another and they need the product to give them some love and there's not enough resources to manage these. And so we were beginning to look like an ugly corporate and people were losing their startup spirit. It wasn't fun anymore. So the thing that kind of got us most occupied is the thought that we needed to scale, but we wanted to keep everyone happy with it. And when I say happy, and when I say everyone, I mean the customers as well. And so if you think about what management wants... oh, I see that the Fonz got screwed a little bit, but okay, just imagine that this is up there. So that's what managers dream about, right? And that's what people really want. We don't want this big office, at least most of us. And so we were trying to find a way to have both worlds at the same time. And I actually, I have to share with you, I've been in this industry for just a little bit over 20 years. We've always tried to get to that point where everybody's happy and the company scales but it remains kind of a young spirit and culture. And it's not that simple to do. And I've been looking for a way to solve that problem for many years. And I think that, you know, Fiverr has been the first time that we actually, I think we actually nailed it. And that's what I want to share with you today. So what I call data-driven culture doesn't mean big data. It doesn't mean having a big database. It's a totally different notion. And it actually means that data-driven is a way for the entire organization to work in synchronization in a way that people and management and creativity remains as good as they were in the first day of the company. And so I'm going to cover some of these aspects today. And we're going to start with the team structure, where I think it's a foundation for everything. So this is a typical dependency graph. And I have to say that when I drew that, I kind of, I couldn't do any more arrows. There should be much more. I don't know, something happened with PowerPoint, it wouldn't let me add arrows. But that's a typical, I mean, that is a dev team and another dev team. There are just two development teams in the whole world for us. But we have a product team over there, we have the QA team over here, and the design studio. And just think about the dev team leader over there. He thinks he's working agile, which is great, but then he has to get services from QA and he has to get services from product and he has to get services from design. And he keeps waiting for those services to arrive. And that's not really agile. So we figured out that there must be a better way to handle this. And this idea that I'm about to tell you came to me after I've met with a couple of very smart people from Spotify and Gilt. And it turns out that they've came across an idea called squads. I'm sure some of you have heard about that. And the idea of a squad is a totally different notion of a team. Instead of taking teams of people who are specialized in a specific area, they try to combine everything into a little small startup that will work within the company. And so squads are basically a group of people who are autonomously working in order to achieve a certain goal. And the point here is, I think, measurable, and we'll get back to that in a few minutes. So if you want to see how a squad looks, there's nothing special about it. That's actually a picture taken in Fiverr in one of the floors in the Fiverr office. And when we designed the office, we designed it to be optimized for the work as squads. And what that means is, you'll notice that it's really hard to see from that picture maybe, but there's like islands of desks there. Each one has their own area, and each one of those desks is a squad. So what does a squad mean? A squad is a group of people that have a certain set of ingredients or talents that can basically, they can have an idea or a concept or a goal and achieve that without needing any interaction with management or any other external resources. So this is a small squad, and you can see that there is a product manager, UX designer, a front-end, QA, and back-end working there. So all the disciplines are at the same table. There's no need to wait or to go to any other service providers. Now, what we limit one means, that's another very interesting notion about squads, is that these guys work on just one big thing at a time. They don't try to juggle several things. If the process they're working on is stuck for any reason, the entire team intentionally stops working until that thing gets resolved. So, and there's a little caveat around that, and I'll touch on that in a minute. But what that means is that this entire squad works on just one thing at a time. Now, in most companies, and it depends on the amount of people working in the company, but in bigger companies you can get a squad that looks like this, where you have actually two big products or features working at the same time. So if you remember the dependency chart that I showed before with all the arrows, this is how it should look when you work right with squads. So squads are totally autonomous. They don't need anyone else. So the only touch point that they have with other people in the organization is when they need to update or they need to get some updates from the organization, which is usually either on a bi-weekly product review, which is around the product idea of the squad, or on the growth review, which I'll touch upon in a minute, around the KPIs and the performance of what the squad is working on. So it's very, very simple. Now we said that squads need to have something that is measurable. And how do you measure things and work around specific things in a squad? So we have this notion of key performance indicators. I'm sure you all heard about those. And we mentioned the autonomous approach and the trust. And in order to get to that, we need to have something that we can measure the squad by and understand if the squad is doing well or not. And the idea is that it's important both for the squad members and also for management to be able to communicate around the same set of KPIs. And so I'm going to discuss KPIs in a bit. That's a usual term that is in many cases used a little bit wrong. A KPI has to be something that you can take action upon. So for example, a good set of KPIs: average order value, monthly active users, cart abandonment, conversion, churn. These are good KPIs. These are things that if something goes wrong in one of those KPIs, you can actually take action and fix that and know around which areas in your product you need to work. Now, useless KPIs, these are very often seen: page views, time on site, number of users, clicks, right? We use those all the time. These are not important because if you have time on site or a little bit less pages, what can you do about that? Is that important at all? So back to our squads with the KPIs. So now we have a squad that's in charge of retention and lifetime value. So now we have a squad that the whole intention of this squad is to improve on those KPIs. Now we mentioned trust and we mentioned autonomy. And when they know that they work on this alone and they transform their KPI performance to management, then there's no really a need for so many meetings anymore, right? And the same thing for that as well. And that's how you really scale the company. You add more and more and more squads, each one getting their own set of KPIs to work on. So another very important idea around squads and KPIs is the ability to track what you're doing. And the first very important thing that we've discovered is that in order to keep people engaged, we need to have information and data and KPI tracking come to them instead of having them go to an analytic dashboard or something like that on their own time. And so push email is a very important part of that. Everybody who works at Fiverr knows all the data, they know all the KPIs. Each morning we send out an email with all the critical KPIs to everyone. But also each of the squads get their own email with specific KPIs that they're responsible for. Another very important aspect of that is the live analytics dashboard. And of course, I guess most of you know that they probably have that already in the product. The question is what do you do with that and what's the policy of the company in the squad in order to make sure that when you break things, and you know, everybody breaks things, we're actually champions of breaking things at Fiverr, you can respond very quickly and fix what's wrong. And so the live KPI dashboards are very important for that. And the last element is the monthly KPI report, which if you remember the sketch from before, that's what you take to the meetings that you have with management. And so you can actually look at data and understand how well you're doing as a squad and how well the product you're building is working. So let's talk a little bit about product. How many of you think you're working agile today? Agile, I mean, yeah, okay. How many think they work waterfall today? To admit you're working waterfall is like, you know, it's not very easy in this crowd. So I want to attempt to show you something that we've learned. We've actually, we've been quite surprised by that. We thought that we were working agile and it turns out we weren't. So I guess that this is something many of you will relate to. That's just a normal process of, you know, developing products. And it starts with the management road mapping, which happens, I know, in a good case once a year, prioritization meetings, product backing, product reviews, UX design, and goes on and on until you have something that is approved by everyone, is have Ronnie, everybody's happy about, and it goes down to the agile, to the development team. And that's where agile starts in a good way, right? So if you think about it, the agile process is only a small part of the entire life cycle of the product, which doesn't make it agile. So let's look at the typical agile team time frame. So that is, each one of those lines is an iteration. Most teams that I've seen work with either one week or two week iterations. And the thing is, that makes a lot of sense. We don't want to change that. But as all you know, and you'll probably go to discuss that in this conference quite a bit, creating scalable products takes time, right? And so this makes sense, but it doesn't leave any time for experimentation, for doing things that are quicker, for doing things that do not require high scale. And so I want to tell you a little bit about an idea called product discovery. Product discovery is something that is a term that was made by Marty Cagan. He was a famous product guy at eBay for many years. And the idea behind product discovery is that product people need to have a faster process, not the one that I've just shown you, but something that is much, much quicker and allows them to run experiments and actually test ideas in a different timeframe that the product itself gets developed. And so we all know the term MVP. The problem is that in most cases MVPs get shipped to production. And so we want to find a way to skip that, and I'll show you how that works in a minute. So product discovery is a way for product people to separate from developers in order to run experiments on a daily basis. And the idea is to try and understand what are the most important features that we want to work on and just discard the ones that are not important anymore. So remember we talked about KPIs. We now have a mean to identify what's important to us. So we want to find the right things to work on. And in order to do that, we need to work very, very fast. I don't know how many of you have seen this very smart saying by Paul Graham. What he meant here was that when you're working on things that scale, that's gonna be too slow. So we're working on something that is going to take weeks or more to develop, only to come to market to realize that it wasn't the thing that you should have built in the first place. So let's look at this iteration scheme from the product perspective, and that is the product discovery iteration. If you take out developers altogether, put them aside, and only talk to product people, they don't care about software. They just want to see how users respond to what they're developing, right? So the idea is, with all the tools that we now see like InVision and others that let you create interactive prototypes, a product manager and UX can actually produce small products and test them without developing anything. And when you do that and you get to a right point where you can actually run that very fast, you can get to a one, two-day iteration process where you can ship things, have them tested, and reiterate on that and really learn what works and what doesn't. So one out of eight things that you're gonna build, that's the average, one out of eight things that you're gonna build will actually make an impact. That's the basic idea of this approach. So just think of the things that you've recently released, let's say in the past couple of years. If you take only one out of eight, that's an awful waste of time. So the idea here is that we can test things very, very quickly and understand what's gonna work for us and only pick those and only develop those in the process that we saw before. So if we go to the squad iterations, we now call it a dual-channel. And what that means is that we have actually two separate channels, two separate time frames in the squad. One is the slow production delivery, that's what we all do today, these are our one week or two week iterations. But then we have the quick product discovery channel above, which is run by product managers and UX. And these guys, they test things and they pick only the ones that really make an impact, and only these things graduate into the actual development of the product. So in this case, we do two things: we build things that scale on the lower side, and we build things that don't scale and shouldn't scale on the faster iteration path. Now that works only if you manage to do that right, which means that 10% of the work done above is actually involving developers, and the rest of it is done by product and UX. And that's how it works. And we don't interrupt the main flow of the production, which is 90% development and only 10% interaction with product. Any questions? So I want to share with you a couple of examples that we had in Fiverr working like that. And these are pretty simple ones because it's much easier to illustrate, but I can assure that there are really major changes that we've done using that approach. Now this is a part of Fiverr's homepage a while back. And I remember exactly when that was, I guess two years. And we had that button which was the main call to action, sorry, the main call to action on the homepage, and a little 'Join Now' link below. So we've done a small test. We decided to replace the call to action and to make the 'Join' the call to action and put the 'How does it work' below. So this little change that was done in parallel to what we were working on at the time, the squad was working on a totally different feature, without interrupting production, we got 300% conversion improvement on join actions on the page. Another thing: search. So we know that search works really well for Fiverr. And if I go back here, you see that search is not the main call to action. It's just up there, right? So we said, why don't we make that more prominent and put that just front and center for the users to do more searches? And if search works well, then we can somehow impact revenues. So again, this is something that was done only by product, only by a little work of user experience, and I should say maybe 5% of front-end developer. We moved search over here. There was no coding involved in that. And we've reached an improvement of 6.5% in revenues. That is major. These are millions of dollars just from moving a small search around on the page. And one last example is this. This is just a part of a product page that we have. And we wanted to add a hero area for our sellers to be able to make their page kind of nicer and more appealing. And this is the kind of, this guy, I think he makes pixel, yeah, pixel characters. So he made a very nice drawing to make his page look better. But what we noticed is that it pushes down the main call to action of the page, 'Order Now', right? And so that hurt our conversion of the page. So we wanted to try something to play with it. And without, you know, taking the developers' time, we just made a small test which shrank the hero area a little bit. And so we just scrolled the page up when you were going into the page. And that improved the conversion by 91% click-through of that button specifically. And so again, we didn't interrupt anyone, we didn't involve any development resources, we just did it and it worked. And that's how we work today. So as a final element of these changes that I recommend doing in a company is the code architecture. And code has a lot to do with the ability to become data-driven. I don't know how many of you are aware of microservices and how do you implement that in your current company, but this is a critical element in becoming data-driven. Microservices are basically a way for us to break down the product into a lot of small elements and open those elements up as APIs so that we can use those internally in the company without changing things in the core of the product. So we took a big project. We started off, I guess, four years ago with breaking up the one code base that we have for Fiverr, which was huge. And we spent about a year and a half just breaking that down to microservices. I guess we have more than 150 repositories last time I checked, currently on GitHub, only for the Fiverr product. Each one of those is a microservice. Each one of those has its own HTTP, and it allows teams and squads to basically play with the product without risking breaking any of the internals. So microservices is an important element. I mentioned breaking down the code base. How many of you have more than 20 repositories for your one product? I think almost none, right? So I was... oh yeah, yeah. Well, eBay, nice going guys. Well, you have more than 20 products. Oh, I was asked the same question a few years ago, and unfortunately I was very embarrassed to say that we have only one and we had like tens of thousands of lines of code. And so we started this really challenging project of breaking down the product into many, many repositories. And I can say that this was the most beneficiary thing we've done with the product so far. It's unbelievable how well this changes everything. It lets people work on the same things at the same time. It lets you be really pretty flexible in how you manage code changes. And so this is something I really recommend investing in. And the last element is the independent UI layer, which in a way corresponds with the microservices. What that means is, if you want to have people change things without being a developer, or at least like front-end people change your product, you need to have a product that most of it is done on a services level, and the entire interaction can be changed and done on the front-end without needing to go back to back-end and change stuff just to change the experience of the users. And so an independent UI layer is very, very important for that. Now, as I said, the squads, they really rely on microservices. And just an example is that, how many of you by the way use Sketch? Not a good question. Oh no, not a lot. Okay, so that's another recommendation I got for you today. Ditch Photoshop, move to Sketch. Sketch actually lets you create a workflow that synchronizes CSS that you have on the site with the UX and designers' resources, so that people can actually change and work on UI without having to redesign and redo all the buttons and all the, you know, define the fonts and all that each and every time. Again, so to conclude that point, data-driven culture is a change that happens to the entire organization. Something that I think should be started by the tech team. It's optimally, I think, driven by the CEO of the company, but it's up to the tech team to drive that because I think they will have the most impact on the change and eventually go through the entire organization. I just want to leave you with one last comment, and that is one test that you can do in order to make sure that you're working right or not: check if you're having fun. For us, when we moved to that, we could go back to these days on the porch where we could actually finish the day and say, 'Wow, that was great fun for us.' Thank you very much.