IDCEE 2013: Giora Kaplan (Co-founder & CTO @WIX)

🎥 Jun 01, 2013 📺 IDCEE ⏱ 20m 👁 995 views

http://idcee.org/p/giora-kaplan/ Giora Kaplan talks about Lean scalability: product, HR and technology for rapid growth on the Tech Stage of IDCEE 2013. Check out his presentation here: http://www.slideshare.net/idcee/3-gio... Pics are here: https://www.flickr.com/photos/idcee/c... Website archive: http://idcee.org/archive/2013/ Follow us on: YouTube: / officialidceechannel Facebook: / idcee Twitter: / idcee_eu Google+: http://gplus.to/idcee VK: http://vk.com/idcee Linkedin: / idcee-3940138 Flickr: http://www.flickr.com/photos/idcee/co... SlideShare: http://www.slideshare...

Watch on YouTube

About Giora Kaplan

At the IDCEE 2013 conference, Giora Kaplan, co-founder and CTO of Wix, discussed his approach to building consumer-focused companies, drawing on his experience with six startups. He described Wix as a platform that allows users to build websites without coding, noting that the company had grown to 250 employees and 15 million users by the time it transitioned from Flash to HTML5 in 2012. Kaplan advocated for minimizing organizational divides, stating that separating teams like server and client or product and development creates problems. He argued that in early stages, teams should interact directly with users rather than relying on QA or support, saying, "the minute you bring QA or support people become less involved with the product." He also emphasized the importance of failing early, stating, "It's better to fail early than to not succeed late; it's better to waste just one year, learn something, meet good people and move to the next stage than to try to survive forever without clarity."

Source: AI-verified profile updated from Giora Kaplan's recent appearances. Browse all interviews →

Transcript (31 segments)

Giora Kaplan0:01

Okay, one thing I would like to ask... I'll start doing it this way. This presentation and my core skills are based around consumer companies. So anything I say, I have my own opinion about how to create a company and how to create a business and a product, but it's really in the consumer aspects. Probably enterprise is very different.

A couple slides about Wix. We started Wix seven years ago. We started it as a platform and the main idea was we were missing a capability that we had enough as founders building websites, going into the CSS, HTML, going back and forth to the graphics. So the one thing we were trying to do is create a situation where you can just like a PowerPoint, just go on the web, click a couple of buttons, put stuff on it, and you're online.

So this is how we started it. It was the first and we still like probably one of the very few that's real WYSIWYG. It's not just a template, it's not something very simple that you do. You can really control your entire website. We started in 2008, first platform was on Flash, added e-commerce, and in 2012 we switched to HTML5. And this is probably taking a company which at that stage was 250 people and already had like 15 million users and converting it totally to an HTML5 platform within six months is something that I learned a lot from surviving.

We also added an app market where people can, without any technical knowledge, integrate widgets into the website. And on top of that, we're also adding the capability for business applications. You already have a website, you have a business online, you can add anything from 1-800 numbers, CRM, etc. So we're creating a platform where we can integrate the web into your business. And we just launched a complete responsive solution which pretty automatically creates the website with all the complexities without having to understand anything, turns your website into responsive.

Myself, it's my sixth startup. I'm managing as a CTO. At the beginning, I managed like the four disciplines which I'm interested in, which is R&D, product, system, and HR. And the last three years I'm mostly focusing on how to scale as a company. We're nearly 450 people and I don't want to slow down. So how do you create scalability, how do you keep being lean with 450 employees? That's the thing that really interests me most.

My background is a developer. I started developing at age of 12, professionally since 15. But my last code was 2003, I still remember it. What I would talk about, and basically this is a presentation that I use within the company, when I coach startups, when I work with companies. It's the same presentation, about 50 slides. So I'll ask you in a minute what's really interesting as a crowd here and I'll try and focus on that.

The way I see it, the fundamentals are always the same. You need team building, and I think the most important thing in technology is team building. The most important thing in technology is getting the team right and the developers right, and everything else in technology doesn't really matter. The other thing which really fascinates me and I think is as critical is creating a product technical lifecycle which works. And I don't care whether it's Scrum or any other thing, but the way the product people, QA people, technology people work together is probably more important than any technology choices you're going to make.

I see two product lifecycles: the early stage of building a product and the ongoing management of the product once it's online, it has users and there are issues. Tech choices, and the one thing for me is becoming methodical. That for me was the biggest growth in Wix. And that's the one thing, this is why this presentation, it will be online. It has about 50 slides, it's recipes of how to recruit, how to do this, how to do that, which I keep pushing into the company and I keep pushing to other companies.

So what I would like from you guys, I would like to know how many of you guys are from startups, if you can just raise your hands. How many of you are from like bigger companies? Okay. And how many of you guys, what would interest you more, like the product lifecycle? Team building? Technology? Okay. So I will start with the team building. I don't know how much time I'm going to have, so just give me like five minutes heads up.

Team building, and that's one thing like the Americans keep saying, 'It's not personal, it's business.' I see within a company it's totally the other way around. It's only personal. The personalities you bring in and the way they mesh is probably the most important thing for your company.

What we're doing in Wix, which I think is, and that's how we try to survive the growth without becoming this, and we have it in some departments and some days you see meetings with 12 people talking about architectures, blah, blah, blah, long emails, etc. We're trying to kill this trend and the way we do it is we create teams which we call 'gangs', which are like micro business units.

And these teams, one of the things, they not necessarily, most of them do not have a single manager. I think one of the, as a startup, the one thing that worked for us is that we are three to four founders, we work well together and we mesh according to skills and not according to roles. And for example, my partner is really good to start a product and he's really good with the product marketing packaging. I'm good with creating the UX and explaining it to the developers how to move forward. And obviously the CEO is the stamina to make sure that it's gonna happen. So a lot of the products within Wix, we just move them between each other instead of just saying you're the manager, you decide all the time, because for each part of a product or for each part of the technology, there is someone in the team probably knows best.

And we took about 200 R&D people and broke them into small groups of five to 15 people. And we're working a lot on what we call the human architecture. It's making sure these teams are not overly dependent on other teams so they can work together. The one thing we encourage, which again is not customary in a lot of companies, we encourage people, as long as they are not mean, to be aggressive, to be open. This is one thing that removes a lot of the politics. And we allow people to be weird, to come at whatever hours, to do whatever they want, as long as they're productive and they move forward.

The recruitment process, I think, is probably the most important thing people should focus. If you're a startup, also how to match the founders. And over there, smart people. Seriously, if people are like, you come out of an interview and you're not sure the person is smart, cut it. Fun people and that are really committed to execution, that would be the three things. In order to facilitate and understand whether people can really execute, we test. So if it's a product person, they write a spec. If it's a developer, they write code. If it's a QA person, we actually have a buggy piece of software where we can give someone and see how they QA in real time.

And I'm trying to hire skills, not knowledge. So I prefer to recruit a coder in any language. If the guy is really a good coder, I don't care about the language, they will learn after. So that would be very important for me.

Open culture, okay, blah, blah, blah, everybody knows. And the one thing, and this is a recipe book, so probably the most important thing would be that you need indicators. You can start seeing when your company is going off. So the one thing is we don't give prizes to people because they bring their friends. This is the KPI, this is the most important measurement of the company. Right now we are around 70% of people recruiting their friends, and this is how we know that it's a really good place to work at and we're doing our things right.

We encourage people to meet after hours. We have a rooftop so people can hang around and people have places where they can just meet without any divides, because otherwise people are cramped into the workspace and they never meet. And I try to see, like, you see a good team is a team where people just interact and meet together and do things together without any formalities. And if you see a team with suddenly there's too many meetings, etc., something is wrong.

Human architecture. Software and teams and names create divides. The minute, everybody here probably knows, the minute you have a server team and a client team, you have problems. The minute you have a product person and a developer are not the same thing, you have a problem. So this is something as management that we really focus on, is putting them together, putting pressure on the group together and not letting them be in their own trenches.

Product manager, probably the most important thing for a tech team is to have a product manager they can work with. And the minute you have a divide between the product person and the developers, you have problems. They start speaking in 'us' and 'we' and things like that. I don't see product manager, and I'm kind of responsible for the entire product management in Wix, I don't see product management as a profession. It's a set of skills, no one has them all. And you need all those skills within a team for the team to succeed. And one of the things we do is we encourage developers to offload some of the PM responsibilities. So you can have a group of people but one of the persons is much better at product packaging or UX or use cases, so they do this and we know that this is the right person for this thing.

And probably the other important things, developers. A good developer, first, you cannot afford a mediocre developer, they kill teams. And a good developer, unless you get them involved within the product, with the users, with the business ideas of the company or the team, then they destroy the team. They destroy effort because like, good developers are intelligent, are curious, and if you start seeing them develop too much technology while they're supposed to develop the product, or becoming like architects and keep talking, 'Oh, this is new technology, that technology,' whatever, then it means again you have a problem. And the problem is that your developers are not integrated with the users.

One of the things we do, we send them, we have a support center in the States, we have a support center in Israel, we send the developers there. We get them engaged with users, they read the support, we record phone calls and the team gets the phone call. So they hear like a pissed off user, a developer will hear a pissed off user about a feature and then, 'Okay, I'm going to fix it, it's really cool.' Otherwise you have the breakdowns. And the other thing is technology is a product, so we encourage people to develop product skills. You want to build a new server, okay, how do you think about it? We coach them in this and they become more involved in the product process.

QA and support. In a lot of situations, I would challenge that you don't need QA and you don't need support. It's something that, if you need to, read one book about this, it's 37signals' 'Getting Real'. Not really, seriously, for a lot of the situations, the minute you bring QA, everybody is becoming less involved with the product. The minute you bring a support team, people become less involved. So at least for the early stages, in a lot of the teams we do not let the people have QA and we don't have them support. They should interact directly with the users, and this creates a really good core of people from the beginning that are really involved with the product.

We're using continuous deployment, so for smaller features it's enough that they're tested and we have A/B testing and everything and we measure the logs. So let people get features out. Sometimes ignore the product management, the developer has a great idea, okay, give it to the users, see what happens. And this gives more freedom and again less, you know, ongoing 'should we do this feature or not'. Sometimes actually arguing about the feature takes more time than actually writing them and testing them.

Good practices, you can read it after that, but probably the most important thing and the thing I take from Scrum, everybody should be in the same room. And the minute everybody's in the same room and everybody's seeing what other people are doing, they see the challenges that the product is facing, they see the challenges that developers are facing. It doesn't matter whether you're doing Scrum, you're doing Agile, you're doing this version, other version, people are in the same room and they care about each other. And the last point is really important, we get people drunk together. So we try to create a team which we take the team out, the team become friends, and again, this is personal.

Problem indicators: long emails, long specs, ideology kind of, 'Oh my god, we need to use this, no it's Clojure, no it's Java, come on, chill.' It really doesn't matter, you need to work together. The minute people start talking in 'us', 'we are the product', 'we are the developers', 'we are the client', then obviously you have a problem and you need to work on it. And too many meetings, everybody is suffocated by them. So don't do that. And all these, the minute you see them, and you're going to have them for sure, the minute the company grows there are issues, the minute the company grows you have problems and it starts, and people start dividing into groups. This is something you constantly work on.

How much time do I have? Five minutes? Perfect. Do you have any questions about that first?

I know. We have offices in Upper Petrovsk, which is development offices, they're not outsourcing, they're our employees. And it took us a lot of time because the way I see it with the Ukrainians, in the beginning they were like, really developed, 'No, no, no, we prefer to be in our own safe environment.' And we said, 'No, it's going to be really fun, it's going to be really cool.' People like, 'We don't trust you.' So what we've done is, it's a good space, it's not like the standard, I've been to several outsourced companies where you have a small desk and it's gray and it's depressing a bit. So what we've done is, it's a really nice space, PlayStation, everything, it looks a little bit like the Valley or Tel Aviv.

We send people in, in our case, and we recruit the top talent. It's easier to take like someone who is really good, is more open to being in an adventure and he trusts his skills. Like you say, if you have a really good developer, they trust their skills more and they're not afraid to take chances, while the medium level developers, they're afraid they might not find a job or something like that. So you try to recruit, you go to conferences, we go to the Ruby conferences, cutting edge Scala things like that, where obviously people are more curious about technology than the average guys. And over there we meet them, we talk about them, we show that we have the same set of values and through that we recruit people in Ukraine.

Any other question? So I'll focus just on this slide. The early stage recipe is get a great team, we discussed that. And the most important thing would probably, the biggest problem when you start a company or you start a project is if you do too much, you're going to create legacy both in code and besides code, also with too much UX or too much features. It kind of kills your ability to shift, and you never know exactly what your user will want, again in consumer space, before you actually got the product out. So the minimal feature set is something good that we focus a lot. And the biggest tip there is, as a product manager, as a team, imagine, because imagine what the thing you do is, you imagine that someone comes back to you and says, 'We can't do this feature, something got stuck, it will be in another two weeks.' If you can live with it, then it's not part of the minimal feature set and then you just drop it. So that hook for me is the biggest tip to give.

Go to the market early, get users. If it's not complete, it doesn't really matter. And then you start testing, getting feedback. And the other thing would be talk to users and analytics. It's the two things that I will never let go. The product has analytics and we have to talk to users and see what users are doing the minute we launch it. And then there is an assessment side that what we're trying to do is, do we want to continue with this or not? And it's okay to say we failed and get it out.

It's much better also for startups, the best thing would be to be a success, but this is my sixth startup and I'm honest about it, it's better to fail early than to not succeed late. It's better to kind of waste just one year of your life, learn something, meet a good group of people and move to the next stage, than actually try and survive and survive and survive. And for that you want to be very honest with yourself about, is it failing? And you see it in a consumer product, once you have a successful one, the minute it's on, it kind of sucks you in. You see the servers going, everything, you know you have something good. And if not, if you have a lot of angry customers, then again you're doing something good because they want the capability, you're just not doing it well. Anything else, if it's just okay reception, this is the wrong product. Thank you.