Transcript
Alright. So, when I talk about making products users love. What I mean specifically is like, how do we make things that has a passionate user base that our users are unconditionally wanting it to be successful both on the products that we build, but also the companies behind them. We're gonna go over tons of information. Try not to take too many notes, mostly just try to listen.
I'll post a link to the slides on my Twitter account. And on that link, there'll be a way for you to annotate the slides and you can ask me questions. And so if we don't get to them, I'll answer them after the talk. So, you guys have been listening to and hearing a lot about growth over the last several weeks. And to me, I feel like growth is usually fairly simple.
It's the interaction between two sort of concepts or variables. Conversion rate and churn. Right? And the gap between those two things pretty much indicate how fast you're gonna grow. And most people, especially business type people, tend to look at this interaction in terms of a very calculated and a mathematical sort of way.
And today, I sort of want to talk about these things at a more human scale. Right? Because at a start up, when you're interacting with your users, you have a fairly intimate interaction that you have in the early stages. And so, I think there's a different way of looking at this stuff in terms of how we build our products.
And we'll look at a lot of different examples of that and how it's executed well. My philosophy behind a lot of things that I teach startups is, the best way to get to sort of a billion dollars is to focus on the values that help you get that first dollar, to acquire that first user. If you sort of get that right, everything else will sort of take care of itself. It's a sort of faith thing.
So I came to be a partner at YC by way of being an alumni. I went to the program in February. It was the second ever program. And I built a product called Bufu. Bufu is an online form builder, helps you create contact forms and online surveys and simple payment forms. It's basically a database app that looks like it's designed by Fisher Price.
What's interesting though, is that because it was fairly easy to use, we had customers for every industry, market and vertical you can think of, including a majority of the Fortune 500 companies out there. Ran the company for five years and then we're acquired by SurveyMonkey in 2013. And at the time, we're very interesting acquisition. We were only a team of 10 people at the time.
And while we acquired funding out here in Silicon Valley through Y Combinator, we actually ran the company from Florida. We had no office. Everyone worked from home. And we're an interesting outlier. So each dot here represents a startup that was, that exited through IPO or acquisition. And we're this outlier to the left. The bottom is the funding amount they took.
And the vertical axis is the valuation of the company at the time. To sum it up, the average startup raises about $25,000,000 And their return to their investors is about 676%. Wufoo raised about $118,000 total. And a return to our investors about 29,000 percent.
So a lot of people were very interested in sort of like, what makes Wu feel a little bit different or why do, how do we run the company very differently? And a lot of it was focused on product. We weren't interested in building software that, I guess that just people wanted to use. Right? That reminded you that you worked in a cubicle. Because it was a database app at its sort of core.
We wanted a product that people wanted to love. That people wanted to have a relationship with. And we were actually very fanatical about how we approached this idea. At the point where it was almost sort of sort of sciency sort of way. So what we said was like, okay.
What's interesting about startups in terms of us wanting to create things that people love is that love and unconditional sort of feelings are things that are difficult for us to do in sort of real life. And at start ups, we have to do it sort of at scale.
So, we decided to do is start off by just looking at like, okay, how does real relationship work, work in the real world and how can we apply them to sort of how we run our business and sort of build our product that way. So we'll go over basically these two metaphors. Acquiring new users as if we're trying to date them and existing users as if it's a successful marriage.
So when it comes to dating, a lot of the stuff that we uncovered had to do with first impressions. All of you often talk about your relationships in terms of the origin story. If I ask you to tell me about the first kiss, how you sort of met, how you proposed. These are the things that we say over and over and over again. They're basically the word-of-mouth stories of our relationships.
And they're the same kinds of things that we do with companies. Human beings are relationship manufacturing creatures. We cannot help but create and anthropomorphize the things we interact with over and over again. So, whether it's the cars we drive, the clothes we wear, the tools and softwares we use, we eventually describe characteristics to it.
A personality, and we expect it to behave a certain way, and that's how we sort of interact, interact with it. Now, first impressions are important for the starting of any relationship because it's the one we tell over and over again. Right? And there's something special about how we regard that origin story. I'll give you an example.
If you're on a first date with somebody and you're having a nice dinner and you catch them picking their nose. You are probably not gonna have another date with them. Right? But if you're married to someone for about twenty to thirty years and you catch them on the barking larger digging for gold. Right? You don't immediately like call your lawyer. Right? And then say like, we have a problem here.
I need to start drawing up papers for divorce. You shrug your shoulders and say, at least he has a heart of gold. So, something about first time interactions means that the threshold is so much lower in terms of pass fail. So, in software, and for most products in internet software that we use, like, first impressions are pretty obvious.
And they're the things that you see a lot of companies sort of pay attention to in terms of what they send their marketing people to work on. My argument for people who are very good at product is they discover so many other first moments. And they make those something memorable. Right? The very first email you ever get from a piece of software. What happens when you first log in?
The links, the advertising, the very first time you interact with customer support. All of those are opportunities to seduce. So, how did we think about sort of like making first moments on there? And we actually took this concept from the Japanese. They actually have two words for how to describe things when you're finished with them. In terms of saying like, is this a quality item?
And the two words of quality are Atateme Hinshutsu and Midyo Kitaki Hinshutsu. And the first one means taken for granted quality. Basically functionality. And the last one sort of means enchanting quality. Right? Take for example a pen. Right? Something has media kateki.
Right? If the weight of the pen, the way the ink flows out of it, the way it's viewed by the people reading the handwriting from the pen is pleasurable both to the user of the pen and the people who's sort of gonna experience the byproducts of it. Right? Taking it to the sort of next level. Start with some examples.
So, this is Wufu's login link and it has a dinosaur on it, which I think is awesome. But if you hover over it, the spec has the added benefit of having a tool tip that doesn't explain you like how to log in and what it does, but basically, var. And what we noticed about this, like in early usability studies, as like this put a smile on people's faces. Like hands down, right, universally.
And I think a lot of times when we are assessing products, we never think about like, hey, what is the emotion on the person's face when they interact with this? This is Vimeo's login page. This is actually a couple of iterations ago. It's one I find to be the most beautiful. But, it lets you know that when you're starting out on this journey with Vimeo that this is gonna be something different.
They do this all over the app. If you search for the word fart, as you scroll up and down, it makes fart noises as you do this. Right? There's something different like this site interacts with you. It's little bit magical. It's a little bit different. And it's something that you wanna talk about. You don't have to always do it with design.
This is a sign up form for court, which used to be a social network for people who love to drink wine. On it, it says email address. It's all your sign in, and to be legit. First name, what your mom calls you. Last name, what your army buddies call you. Password, something you remember but hard to guess. Password confirmation, think it, type it again, think of it as a test.
It's literally a poem as you fill out the form. Right? And this is the kind of like thing where you're like, oh, I like the people behind this. I, I, I'm gonna enjoy this experience. Now, does it say when you fill out a form like this, right, on Yahoo? About what the personality of this site is gonna be.
And what's disappointing to me is like Yahoo forces every product and service under them to use this exact same login form. Flickr, I had thought, had one of the best sort of call to actions. It was, get in there. Right? This is Heroku's sign up page. I think this is an older version.
But, what's remarkable about it is that, what you start getting a feel for is like, oh, scaling up my sort of server and back end services is as easy as just sort of dragging up and down different sort of knobs and levers. It's gonna be beautifully used and looks fairly easy to scale. Since we're a room full of computer science people, I think you'll appreciate this. This is Choc Cloud.
This is a code editor. And they only have one call to action. When the time limit is up, they said, everything in terms of all the features are exactly the same except we change the font to Comic Sans. And what they're basically saying is like, hey, we know who our users are, Who our real customers are. And they're gonna be the people who care about this. This is Hurl.
This is a website for checking http requests. And sometimes the places where you get errors are opportunities for first moments. If you hit a four zero four, this is what you get. When we need help, oftentimes what we do is we create like really beautiful mark, marketing materials. But when you actually need like documentation, we sort of like skimp out on sort of design features.
And this is a point that like you see happen over and over again. A company that gets this right is MailChimp. And what they did was they redesigned all of their help guides so that they looked like magazine covers. And overnight, basically, readership goes up on all these features and customer support for these things that sort of help people optimize emails goes down.
Speaking of documentation, Stripe, what's interesting about an API company is that there is no UX. The UX is actually just documentation. Right? And there's opportunities even in documentation sort of the enchant and amaze. So one of the things that I love about them is their examples are wonderful.
But if you're actually like sort of logged into the app, one of the things that is a super pain for most people when you're dealing with most people's APIs is like grabbing your API credentials and keys. And what Stripe does is it says, oh, you're logged into the app, we automatically put your API credentials into the examples. So you only have to copy paste once when trying to learn their API.
When Wufu wanted to launch the third version of our API, we realized like, that finally this is good enough that we want people to sort of build on top of it. We were trying to figure out like, how do we launch this out to the world that sort of has our personality behind it? Because a lot of people, they usually do things like a programming API contest, and they give out iPads and iPhones.
And it makes you look like everyone else. And so, in our company one weird value they have, it's a quirk of us, is that the co founders are big medieval nuts. And we would take everyone out to medieval times every single year on the anniversary of the founding of the company. And so, we said, we have to do something in that flavor. And so we contacted the guys at armor.
com and we said can you forge us a custom battle axe? And what we said was, if you win our programming contest you would win one. And the result is, like, people wanted to talk about this. It was something that people wanted to work on because they wanted to be able to say like, I'm programming for a weapon.
And what's cool is, we had over 25 different applications created for us of quality and quantity that we could not have paid for on the budget and sort of time that we had for this. We got things like an iPhone app, an Android app, and WordPress plugins. Right?
And all because what we did was we changed how people want to talk about the origin story of how they're interacting with one of our services. We can go like all day long on going over these examples. But I'm gonna shortcut this by saying, you should just subscribe to little big details. It's just basically tons of screenshots of software that's just doing it right.
That shows that they're being conscientious of the user and the customers. When it comes to long term relationships or marriages, the only research that we ended up having to read is the stuff that was done by John Gottman. He's been featured in This American Life and Malcolm Gladwell's books. He's a marriage researcher up in Seattle and he has an interesting parlor trick that he can do.
He can watch a video tape of a couple fighting about some issue for fifteen minutes and predict with an 85% accuracy rate whether that couple will be together or not or divorced in four years. If he increases that video up to an hour and asks them to also talk about their hopes and dreams, that prediction rating goes up to 94%.
They show these same video tapes to marriage counselors, successfully married couples, sociologists, psychiatrists, priests, etcetera. And they can't predict with random chance whether people are gonna be together or not. So John Gottman understands something fundamental about how relationships work in the long term.
And that basically how we fight, even in a short term period, could indicate sort of the whole system and what it's gonna look like. And one of the surprising things he discovered is not that successfully married people don't fight at all. Turns out everybody fights. And we all fight about the exact same things. Money, kids, sex, time, and others. And others are things like jealousy and in laws.
To bring this around, right, you can actually attribute every single one of these to problems that you see in customer support when you're building out your products. Right? So, this costs too much. I'm having problems with the credit card. If you're building a service that helps people deal with their clients, they're very sensitive about anything happening with that. Performance.
How long you're up and how fast. Others are, I said, jealousy and in laws. Right? So that's competition and partnerships. Anything weird happening there, people are gonna write to you about.
And the reason I like to think about this in terms of customer support is that, in everyone's sort of processing of like a conversion funnel, customer support is the thing that happens in between every one of these steps. It's the reason why people don't make it further down there. It's the thing that prevents conversion from happening.
Now, as we were thinking through all these ideas and as we're building up the company, we realized that there's a big problem about how everyone sort of starts their company or build up their sort of engineering teams. And that is there's a broken feedback loop there. People are divorced from the consequences of their actions.
And this is a result of actually the natural evolution of how most companies get founded, especially by technical co founders. Right? Before launch, it is a time of bliss, nirvana and opportunity. Right? Nothing that you do is wrong. Right? By your hand, which you feel is like God, everything that you write, every line of code feels perfect. Right?
And is a genius to you. The thing that happens is after launch, reality sort of sets in, and then all these other tasks sort of come into place that we have to deal with. Now, what technical co founders want to do is get back to that initial state.
And so what we often do and what we often see is that companies start siloing off all these other things that actually is what makes a start up or a company sort of real, right? And have other people do them. To, in our minds, these other tasks are inferior, right? And we have other people in the company do them.
And so for us, what we're trying to figure out is how do we change software development so that we inject some values that we don't talk about enough. Responsibility, accountability, humility, modesty. Right? And we call this like a lot of other people, we, we, we had an acronym, support driven development. And it's basically very similar to t t t d d or other agile practice.
It's a way of creating high quality software. But it's super simple. You don't need like a scrum. You don't need a bunch of post it notes. All you have to do is make everyone do customer support. And what you end up having is you fix the feedback loop. Right? The people who build the software are the ones supporting it.
And you get all these sort of nice benefits as a result. So one of them is, support responsible developers and designers. When people build the stuff, they give the very best support. Now, we're not the first person to think of this. Paul English was a big proporter of this at Kayak. And what he did was install a red customer support phone line in the middle of the Engineering Floor.
And it'll just ring with customer support calls. And people would ask him often times, why would you pay engineers one hundred and twenty thousand dollars or more to do something that you can pay other people a fraction of to handle in like a call center? And he says, well, after the second or third time that that phone rings and the engineer gets the same problem, they stop what they're doing.
They fix the bug. And we stop getting phone calls about it. It's, it's a way of having QA in a sort of nice elegant solution. Now, John Gottman talks about the reason that we often break up with one another as due to four major causes and their warning signs. He calls them the four horsemen, right? Criticism, contempt, defensiveness, and stonewalling.
That criticism is basically people's starting to focus not just on the specific issue at hand, but on the overarching issues. Like, you never, right, listen to users or you never think about us all the time. Right? Contempt is when someone is purposely trying to insult somebody. Defensiveness is not trying to take accountability, trying to make excuses for the actions.
And stonewalling is basically shutting down. Stonewalling to John Gom is, is one of the worst things that we can do in a relationship. Hold up. And, oftentimes, you know, we don't worry much about this in customer support. Criticism and contempt, right? Defensiveness, you see this all the time, all the times in companies, especially as they get older.
But stonewalling, this is something I see happen with start ups all the time. You get a bunch of customers sort of coming in and you just think, I don't need to answer it. I don't need to respond. Right? And that act of just not even getting back to them is one of the worst things you can do. And it's probably some of the biggest causes of churn in the early stages of start ups.
This is how support worked at Wufoo. When we were acquired, we had about 500,000 users on the system. 5,000,000 people used Wufoo forms and reports whether they knew it or not. And all those people got support from the same 10 people. And usually, it was only one person dedicated support a day or any, any shift. Resulting about 400 issues a week. That's about 800 emails.
But a response time from 9AM to 9PM was between seven to twelve minutes. Right? And from 9PM to midnight, it was an hour. And then on the weekend, would be no longer than twenty four hours. And we carried this up all the way up to this scale.
What a lot of people forget about, and often talk about with Airbnb, is how like, oh, they did this interesting thing where they had, went up to New York and offered like professional photographers and the founders would go out there and actually take pictures of the people's apartments to help them sell more. Focusing on the stories around conversion.
What most people don't realize is, a lot of times when I saw Joe in the early days of Air n b, he had a phone sort of headset stuck to his head all the time because he was doing phone support non stop. Churn is a story that we don't like to talk about all the, all the time.
Airbnb sort of growth really started picking up once they figured out how to match capacity to the demand or the phone calls they were getting into their support system. At Wufu, we actually constantly did experiments around support because we were so obsessed with it.
One experiment we did was, we heard Cathy Sierra do a talk about there's a disconnect between the emotions that we have when we need help and sort of the content and the reactions we get from people when we get help from them, especially online. Because they just don't see all those non verbal cues.
So she said, there's face recognition on the web, we're just always gonna be disconnected from our users. Our feeling was like, well, we're not face recognition experts. So, I think there's another way of getting empathy. So, as form builders, we added a drop down. And what we said was like, hey, what's your emotional state? And our hypothesis was that no one was gonna fill this out.
We basically thought, oh, okay. You know what? This is gonna be pretty a lame experiment, but we'll see how it sort of goes. And it turned out the emotional state drop down field was filled out 75. 8% of the time. The browser type drop down field, just in comparison, was filled out 78. 1% of the time. Right?
So, people were basically telling us, for my technical support issue, How I feel about this problem is just as important as like all the technical details you need to sort of figure out how to debug it. Now, didn't prioritize things or triage things by emotion. Right? And for the most part, didn't game the system.
One of the interesting byproducts of it was that we noticed that people started being nicer to us. And the question was, It was something sort of subconscious. We just were thinking like, wow, our users are so much better now. What's going on? And we went back and looked at the data and we did some text analysis.
And what we realized is that, oh, when it comes to only communicating with people over written words like email, there's only three ways that you show strong emotions. Right? Exclamation marks curse words, and all caps. And sure enough, on all three of those metrics, they've gone down in sort of the way people were talking to us and the customer support.
Once people had a simple outlet for their emotions, right, people would be a lot more rational and it made our jobs a lot more pleasant as a result. The other byproduct that is awesome is that you actually build better software when you do this. Far better software. This is actually backed up by tons of research.
Jared Spool at user interface engineering, is sort of the big players in this space says like, there's a direct correlation to how much time we spend directly exposed to users and how good our designs sort of get. He says, it has to come in a specific way. It has to be direct exposure. Right? It can't be something where someone generates a report or through a graph.
You have to be interacting with them somewhat real time. It has to be a minimum of every six weeks. It has to be for at least two hours. Otherwise, your software will get worse over time. Our developers, our people who are on, on Wufu were getting exposed to our users four to eight hours every single week. And what it does is it changes the way you sort of build software.
Shared spool has another way of talking about how we build products. Right? And let's imagine that this represents all the knowledge needed to sort of use your app on a spectrum. Right? This is like no knowledge. Right? And this is all the knowledge needed. Right?
And these two lines are pretty much your interaction with users. What you're trying to get them to. This is currently where their knowledge point is. And this is the target knowledge point that you're trying to get them to, to understand and use your app. The gap between those is called the knowledge gap, Jared call. It's both calls.
And what's interesting about this, is there's only two ways, right, to sort of fix this. That gap represents how intuitive your app is. Right? You either get the user to increase their knowledge or you decrease the amount of knowledge that's needed to use your application. And often times, as engineers and people who build and work on products, we think, let's add new features.
And new features only means, let's increase the knowledge gap. So, for us, we actually focus a lot on the other sort of direction. And so what that meant is we spent a lot of time, 30% of our engineering time was spent on internal tools to help with our customer support stuff. But often times, it was spent helping people help themselves. Things like frequently asked questions, tool tips.
Things like, if you just click the help link, right? Instead of taking you to the generic help sort of documentation page, you go to the specific page where you're looking at that's gonna be most sort of appropriate for what you're working on. We redesigned our documentation over and over again. AB tested it constantly. One iteration of our documentation reduced customer support by 30% overnight.
It's one of those things where like, overnight, all the people that work on the product immediately had 30% less work to do. Now, what happens if you have everyone work on customer support constantly and thinking about it in terms of a remarkable way? Well, I talked a lot about in the very beginning, growth is a function of conversion and churn. This is Wufu's growth curve for the first five years.
Right? What's interesting is we paid no money on advertising, on marketing. All of it was done by word-of-mouth growth. Right? And the interaction between like new users and downgrades are this. It's so slight what it takes, that gap, making that sort of work.
And what a lot of people keep forgetting is that there's almost no difference between an increase in conversion rate, 1% increase, and a 1% decrease in churn. They do exactly the same thing to your growth. However, the latter is actually much easier to do. It's much cheaper to do in your apps. And a lot of times we neglect this, neglect this to way far along. Right?
And we usually have our b team works on these sort of products and services. This is actually not the graph that we track most of the time at Woof. It's not even the one I'm proud This is the one I'm proud of. Because, even though we had this sort of nice, awesome curve of growth, this is what allowed us to scale. Keep the company small, have an awesome culture.
And that required doing a lot of these things to help people sort of do what they need. So John Gottman noticed there was a different type of behavior for relationships and why people divorced. Basically, would be some subset of people who would stay together ten, fifteen years, and then all of a sudden, they divorce.
There was none of the other indicators which sort of show that this is what was gonna happen. And I was looking through the data and he realized, oh, there's no passion. There's no fire between these people. Right? When it comes to relationships, they kind of follow the second law of thermodynamics. Right? In a closed energy system, things tend to run down.
So you have to constantly be putting energy and effort back into it. Now the way a lot of people sort of think about showing people that I care about you in products and in companies, is to do things like, let's have a blog. Right? Let's have a newsletter.
The thing is, we'd look at these rates and basically it was such a small percentage of our active users that it was like, most of our users have no idea all the awesome stuff that we're doing for them. So we built a new tool. We called it the Rufoo Alert System. And what allowed us to do is just timestamp every new feature that we're building for users.
And then every time they would log in, we would look at the difference between their log in time, or last log in time, and the new features that were implemented. And we had this message show up. Hey, since you've been gone, here's all the awesome stuff that we've hooped, did for you. Hands down, this was the most talked about future I've ever had every time I went out to talk to users. Right?
They'd say like, dude, I love that since you give, since you've been gone thing. Even though I pay the same amount every single month, you guys are doing something for me almost every week. And it's totally awesome. It makes me feel I'm getting maximum value. The other thing that we did, in addition to having everyone support the people that paid their paycheck, is have them say thank you.
And this was a large part due to us injecting sort of humility and modesty into sort of the equation. Every single Friday, we would get together and we'd just write simple handwritten thank you cards to our users. And, I know there's tons of people who would not be sort of excited about doing this.
But it was a ritual that made sort of all the difference in terms of like, having a team that was very tightly neat, tightly knit also. And working on stuff that they really cared about. They always constantly knew what the mission was for and why we sort of did what we did. These aren't fancy thank you cards. Right? They're just simple like handwritten stuff on an index card.
We threw in a sticker and slapped on a dinosaur on the front of it. And what's interesting is, we started this practice as a result of of the early days of starting Wufoo. Chris, Ren and I were talking and we're trying to figure out what are we gonna do to sort of show our users that we appreciate them around Christmas. And he, Chris came up with this idea where he said, hey guys.
So a couple years ago, my mom like made me write thank you notes to all of my relatives for my Christmas gifts. And I didn't really like to do it, but the following year, all my presents were super good. So, I think we should try this for our business and see how it goes. So, that first year we wrote handwritten Christmas cards to all of our users that first year.
Second year rolls around and we have too many customers. It's like, and it's still just the three founders. And we were going like, we're kind of screwed. I don't know what we're gonna do. And we read a book called The Ultimate Question. And in it, he talks about, hey, just focus on your most profitable users. If you just send them and take care of them, things will work out.
So we're like, alright, that, that makes sense. That's scalable. So that year we only write to our highest paying customers. And the January rolls around that second year, and one of our long time loyal users writes us. And he's basically like, hey guys. I, I really love that Christmas card you sent me the first year. And I just wanted you to know, I haven't received my second card yet.
And I'm just looking forward to it. I know you didn't forget about me. Thanks a lot. So we're like, fuck. Because, best way to sort of exceed expectations is not to send any to begin with. So we were like sort of in this conundrum. And what we decided after thinking about it for a while is that, we need to stop doing it, you know, just one time a year.
It needs to be something that's part of the culture. It happens every, every, every sort of week, even. And even though we'll never catch up to all of our customers, just the practice of doing it will make all the difference. I talked a lot about a bunch of like, lovey dovey stuff and sort of like touchy feely things that I think a lot of engineers don't like to think about too often.
And so I'll end on some sort of hard business data or research. There's an article that was put out by the Harvard Business Review several years ago by Michael Tracey and Fred Wazirma. And in it, they talk about the discipline of market leaders. They say, there's only three ways that you achieve market dominance.
And depending on how you want to achieve that market dominance, have to organize your company in a very specific way. Best price, best product, and best overall solution. If you want to be the best price out there, you focus on logistics, a Walmart and Amazon. If you want to be the best product out there, focus on R and D. Apple's usually a quintessential example of that.
Best overall solution, it's about being customer intimate. And this is the path that you see followed by luxury brands and hospitality industry. What I love about this path towards market dominance is that the third one is the only one that everyone can do at any stage of their company. It requires almost no money to get started with. Usually just requires a little bit of humility and some manners.
And as a result, you can achieve the success as any other people in sort of your market. That's all I got. Thank you very much. Yeah, let's take some questions. You guys have any? Right in the back there. Using products that users love, you might have multiple.
different types of users. How do you build one product that.
all users love? Maybe there's a feature that one really likes but detracts value from one end. Right. So what do you do when you have a product with lots of different type of users? Right? Some users will love one thing and another will, will another. And I agree, there's a interesting fine line for that.
What I always usually tell people is focus on the people who are the most passionate, especially in the early stages. Right? Whoever's, whatever niche it's gonna be, that's who I focus on completely. Things that a lot of different product, products did. I think Ben Sullivan of Pinterest started off with design bloggers. Right?
Curtail your thing for them, and eventually, you'll figure out sort of universal values that will appeal to a lot of other people. So just start one at a time. And the, a lot of the examples that you see up there, a lot of people make the mistake is like, oh, I'll just make my app funny. But humor is like really difficult to do. Right? When you want to shoot for something sort of witty.
And quite honestly, you have to get functionality right. So, like the Japanese quality. If you don't have a tareme on there, right, don't try to do anything witty. Right? Because it will backfire on you. So, hands down, our number one focus is to make it as easy to use as possible for Wufu. And anything else on top was polish. Right here.
So, I'm co founder of Richel Bhutat, you. So, everybody says that focus on your product. I'm also a dev guy. I love to build product and I love to make it the best. But we are at certain point that we are focused on our product but we don't get like customers. Right?
So mean, some of second thing, so how much we should focus on product but because we should do now marketing, we should like get some other customers, you know, like and like start talking to customers. But when you are too focused on your product, like, users are not coming. Right? So what exactly do you guys mean when you are saying like focus fully on your product and give the best product?
So. Okay. Exactly. So, the question sort of is how do we balance this sort of thing where we wanna be obsessed with working on product. Yeah. But all the other skills and sort of tasks that are needed by a company like marketing and branding and all that stuff. How, how do we sort of balance that? And the thing is like, it would start as you're juggling like tons of things constantly in the air.
The thing is, if you're working on product, like, you should also always have this flip side is when you're talking to users. Right? And for us inside of Wufu, the way we got people to talk to users is they just did customer support. And they got to see first hand right away whether that feature sucked or not.
And it also impacted everyone else in the company because everyone had a customer support shift. So you had this sort of social incentive to sort of make everything work. And so, like I said, there, there should be no point where you only focus on product. You should always have time where you work on product and then you see sort of what users say to you.
And you should always have this virtual like feedback loop on there. So be careful when you don't have that. Usually what ends up happening, if you're lucky in terms of marketing and sales, like, usually, my feeling is like, you having to spend money on marketing and advertising, all that stuff, that's usually a tax you pay because you haven't made your product remarkable. Right?
Word-of-mouth growth is the easiest kind of growth and it's how a lot of the great companies sort of grow. So figure out how to wait, how to like have a story that people want to tell about your product. Where they're the most interesting person at the dinner table. Right? And then that person is your salesperson. Right? That person is your sales force for you. Right here.
Like,.
why do define more crystal clear customer or user need and the demand is there and it's the right solution. How do you communicate with engineering and design team to make sure the execution. You sometimes go in the team with ideas and but still at the end of the day, have to make a decision of where to go. So how do you make a decision on product.
and communicate that with your sort of engineering team when there's like lots of different directions to go? My feeling is that, so for us, we just looked at support and it was really easy. Because you often just saw, what are the things that people are having the most amount of problems with? Or people asking all the time. You cannot help but get feature requests from people.
No matter of like, whatever opening or orifice you have in your product or app, right, people will like jam feature requests in there. So you're easily gonna know sort of what they sort of want. Your job as a product person, an engineer, is to not just do what they say, because that, that way you'll just be a slave.
It's to figure out sort of deeply what are the reasons why underlying those things and sort of solve that deep underlying reason. The thing is that everyone wants to have a different way to, to sort of go, then ultimately it comes down to like, someone's gonna figure something out. But also, make the smallest version of each little idea. No longer than a week or two weeks to build it out there.
And then you can try them out and see sort of what works or don't, don't work. I think it's dangerous to have multiple different product directions that requires lots of time to sort of figure out.
Sam. Related to that, can you tell the story of how the king for a day thing is gonna go through? Yeah. Okay. So so.
I don't like hackathons. I think they sort of suck in terms of ones done inside of companies. Because you spend like forty eight hours like working on something really hard that you're sort of passionate about, and 99% of them never make it to production. Right? And it's so, sort of really super sad.
So for us, we like flipped the nut on's head and we came with an idea that we called king for a day. And it actually worked over the weekend. But how it worked is someone randomly in the company got drawn and they got to be the king. And the king got to tell everyone else what to do on the product.
So everything that that was bothering them about Wufu about the customer support stuff, or some feature they really want to have built. They got the engineering resources, the marketing resources, advertising resources of everyone inside of the company to make it sort of happen. And of course, we'd work with them to figure out like, what can be actually done in forty eight hours.
But we would do this one to two times a year. And it was like a huge hit and it was a boost to morale. Because what people most love is like working on things where it's like, oh, I made a difference to the app. Right? And so, for us, that's one way that we would like sort of divide time for like product direction.
It's like sometimes the people that work for you, they have a strong opinion about where it, where it should go. And that's a good way to sort of democratize it a little bit by rotating it around. Yes. You said you guys all work from home. Usually seems like a nightmare. Getting out of office, how did you make that work? Okay. So we all work from home.
So I, we'll tell you this. We all still work within the Tampa Bay area. We would allow anybody to work from anywhere, but usually, as we try to recruit them, they sort of meet our team and they just decide, okay, we just wanna come and move here anyway. Remote working is especially tricky. It, it, a lot of people like to romanticize it, especially people who are like employees.
But the thing is an office gives you a lot of sort of benefits, right, and efficiencies that you now have to compensate for when you have remote working. But remote working also have these other sort of efficiencies in place. For example, I don't have to worry about my employees losing two hours of their day to commuting, for instance.
So the biggest thing that we had to do for remote working is to respect people's time. And so the way we had it set up is, we actually had a four and a half day work week at Wufu. Half day on Friday was for all the meetings stuff. We said like no biz dev deal meetings, no talking with other outside parties. They often be done on Friday on that half day.
It couldn't be done in the middle of the week. And then also one day of everyone was already dedicated customer support. So everyone in our company effectively only had three days each week to actually build or work on whatever they were doing.
But I actually firmly believe that if you have three solid days, right, eight to ten hours, where you're only working on what you need to build, you can get a ton of shit done. And so, what we said was, get have restrict everyone's time during that three day period, if they're in that three day period. And what we came up with is a fifteen minute rule.
And the way it worked is you can have a discussion, like a chat or a phone call or whatever with someone, but it could go no longer than fifteen minutes. So if you have some complicated issue that you couldn't figure out, we'd say, at fifteen minutes, you are to immediately table that item. Right? And have us discuss it on Friday. And you'd move on to the next item on your list. Right?
The enhanced productivity. More often than not, I I would say 90% of the time, the item never got brought up on Friday. Because usually what would happen is people would sleep on it, and then it would magically say like, hey, I found a solution. Or like, hey, that's not a big problem whatsoever. Because most problems inside of company, they don't need to be solved in real time or right away.
The only things are when like, the site is down or payments aren't working. Right? Everything outside of that is basically kind of luxury. So focus on your priorities as much as possible. And as a result, our 10 person team did far more than many, many other companies as a result. But it takes extra work to make remote working happen. We are an extremely disciplined sort of team.
And I would have to say, there's almost not many YC companies that actually have been able to replicate sort of what we do. I think there's only two other companies I think in YC that sort of have the same sort of discipline working style. It takes more work in a very different fashion. Right? An office allows you to be a little bit lazier, right, in terms of all these things around productivity.
Okay. Over here. Hi.
Just to build up that question. As the leader of the team, how did you manage to, instill a company culture, right? And also like, have accountability.
for, for your employees, especially because they're in the same working space. Okay. How do we, how do we set up accountability for employees as, as a manager? Alright. So at Wufu, we were profitable nine months after launch. So we had profit sharing. Right? And so it makes incentives pretty simple and clear.
It it would be a multiple of whatever bonus pool that we sort of had. And the performance measures would be based on sort of how they did in customer support. Right? On their duties there. And sort of what they said they were wanting to accomplish or do. I don't like process and I don't like lots of tools to help get people to be productive.
So the only thing that we had for helping people manage sort of their projects is to do lists. And that is like simple text files that we shared in a Dropbox account. Each person had their name on it and you got to see every time someone updated their to do list. When we said this every single night, you just said everything that you did that day. Right?
And then on Friday, we would just go over, okay, this is what you said last week that you're gonna do. This is what you actually got done. What are sort of problems at hand? And it's super simple, right? It creates this like nice written trail for how to sort of handle stuff, right? And I don't have to worry about managing them, right?
They sort of set the tone for how they want to be sort of assessed. And it makes it really simple. And for people who are excellent at what they do, right, it works very, very well. And then when you actually have problems, it's very easy to fire people. I was fortunate that I never had to fire anyone at wufu. Right? But we were able to correct a lot of people's behavior very, very quickly.
Cause we just kinda look at this and it's like, look, this is your pattern of behavior. You finish a fraction of the items on your list. You do most of the items at the last second right before Friday. That's a problem. You've gotta manage your time better. And this is evidence that you've provided to us. All we have to do is sort of describe it back to you.
And because everyone in the company sort of sees it, right? There's social pressure that's put in the place that helps make it all sort of happen.
Right here. How did you hire people that, you know, you felt would be able to work remotely in this kind of environment that's, that's not standard?
So how do you hire people that can work remotely and then sort of work in this sort of fashion? So, pretty easily you have them work on a side project for you. So you contract them out and they have to work remotely as such. Usually the project I like to have them work on is about a month long. Right? I could do things much faster for a week.
But usually get a good sense of like how well people sort of manage themselves and work on things from a project like that. So that was always the first assessment. Like we never did anything just by interviews. The other thing we had to sort of screen them for is their ability to do customer support. Because not every engineer sort of has empathy skills to handle that stress.
So sometimes I would have people write break up letters to me, right, in an interview. Just like, hey, pretend like you have to break up with me. You have fifteen minutes to write, write it on there. You can only write it by hand. What are you gonna say? And so, you get a good sense of sort of their writing skills. Because like 90% of what you do in customer support is tell them bad news.
Like, we don't support that feature. Sorry, that's not gonna work. Or it's not gonna be available. And so people have to have sort of tact at that. How about one more question? One question.
Right here, the glasses. Cool. So it seems like you have all these like tricks and experiments that really help the company. Do you have any stories of ones that didn't work out?
Have all these tricks and experiments to help the company, are there any ones that didn't work out? Alright, I'll talk about one. So, one of the things that we did early on to try to motivate ourselves was try to get, like we understood this idea of like crunch mode, and that it's really bad for people. Like if you're doing a subscription business, you need people to last for the long term.
And video games, lot of times, like crunch people all the time. For like a specific deadline or have multiple sprints every two weeks and you have to shoot up to this deadline and it's like exhausting. And so peep, because what ends happening is like, you might get an increase in productivity, but the recovery period that you need for people is always greater, right, than the productivity you gain.
And in a company where you need everyone doing customer support and being on their game and constantly put, pushing out features, you don't have time for recovery. So we, we were thinking about, okay, we wanna build like a company vacation into how Woofy sort of works. To reward our users every single year.
And we said, okay, the vacation is sort of built in there for the recovery, we can have one crunch period, right, before that vacation setup. And we'll just only do customer support that will, that sort of scale with people. So, the way we did the very first crunch mode is that it was just between the three founders. And we had each of us draw up a 10 item to do list.
That would be fairly aggressive. And the first person to get through seven of their items would win. And the last person to get through seven of their items would become what we called trip bitch. And trip bitch meant that you carried the other person's luggage and got people drinks when you're on the company vacation. So we did that.
And during that period, everyone was like pretty excited about it and motivated. And, oh, in the winter got to choose the next company vacation the following year. And then all of a sudden, Ryan had basically poorly estimated the items on his list. And he realized very quickly, I'm going to fucking lose. And so he was just like, I give up. And he just sort of stopped.
So crunch mode turned out to be blah mode for him. Because he knew he was gonna lose and became pretty demoralized. So as a result of doing that, we decided not to do it in that similar fashion anymore. So, good idea that we like to talk about, but it's one that we, we never did again. Alright guys, thanks a lot. You can email me at kevinycomdata dot com.
✨ This content is provided for educational purposes. All rights reserved by the original authors. ✨
Related Videos
You might also be interested in these related videos