About Sachin Agarwal
Sachin Agarwal’s talk last Friday sparked the most hand raises we’ve seen in a while! The stories about different product setbacks, losses and wins kept the crowd engaged and entertained as always. Check out the podcast as you read through our summary below.
I Didn’t Set Out to Create a Consumer Product
As an engineer at Apple living in New York, Sachin didn't have the desire to create a consumer internet company. All he wanted was to help his family, his friends and himself share photos on the internet. The easiest way to share photos was email, so he decided to create an simple app to make it even easier.
He had no idea that anybody else would ever use it:
I didn’t set out to create a company. I did no user research. I built this for myself. I was the only guy using this thing.
As his app's power user, Sachin focused on building the product he wanted to use. When he showed the app to his friends, it turned out that they all wanted to use it too! In 2008, Posterous was accepted to Y Combinator and launched at TechCrunch. People got behind the app's simplicity right away.
Accidental Innovations
Sachin mentioned a couple of accidental decisions that proved to be valuable pieces of the Posterous experience:
1. Posterous has one email address that all users email to post to their blogs, [email protected]. This was initially done because Sachin didn't know how to set up a mail server. At a time when all similar services had a unique email address for each user, the simplicity of this feature became tremendously popular with Posterous users.
2. If you don't have a Posterous account and send an email to [email protected], an account and blog will be created for you instantly. Sachin isn't a designer and chose to do this rather than deal with creating the interface necessary for account creation. Simplicity won over the hearts of users again here.
Big Problems For New Users
The team at Posterous introduced Groups to the service to accommodate the large percentage of existing users who were trying to collaborate by sharing pictures and information in a group like fashion. A few months down the road the team ran into problems:
We were growing nicely, getting more and more customers everyday, but we had problems. New users were confused between the photo sharing blog site and groups. They did not understand what the site did. In addition to that we had added so many new features to the interface that new users became lost. There was no one call to action, there were 50 buttons. The exiting users loved it, but new users didn’t get it.
Posterous had accumulated a ton of code and design debt over the years. The team decided to start over, asking themselves, "what are we really trying to build here?" They took a month to think about how to best introduce new users to Posterous. One thing was clear - they had to nail private sharing; that's what their users wanted.
Locking down once screen per day, they spent 7 months going from page-to-page, rethinking, rebranding and redesigning each from scratch. They brought in users ever week to test new concepts in front of their target audience. The very early user testing sessions were brutal - people hated the new interface and concept. The Posterous team would go back to the drawing board after these sessions and iterate over and over again until they got it right. Everyone on the team was also using the new interface they were developing every day.
Sachin continued the talk by sharing some losses and wins during the redesign process. He then took questions from the audience about how Posterous compares to Google+ and Facebook, his experience at Y Combinator, his user testing methodology, his decision making during the 8 months and the process they used to gradually roll out design changes.
We’d like to thank Sachin for such an engaging and inspiring story of starting from the ground up after a few years of building a product. You rarely hear of a startup doing that these days!
Transcript
Moderator: I wanted to welcome Sachin Agarwal from Posterous. So famous, up until recently a simple sharing site, right? It's been in operation for about three years, I think, too and is pulling in about 15 million unique.
Sachin: Monthly unique, yeah.
Moderator: So no big deal … quite a few people have taken advantage of that. We're catching him at a really interesting time too because we've been talking to him about actually getting him in for a little while now and he's been putting us off, putting us off, because he's like, "I've got something, I've got something." He spent the last eight months rethinking, redesigning, and rebuilding Posterous from the ground up and rebranded as Posterous Spaces and just launched this about a week ago now … a little over a week ago.Sachin: Two weeks, yeah.
Moderator: Yeah, two weeks now?
Sachin: Yeah.
Moderator: Wow! So we're catching him at a really interesting time so we invited him in to actually give the first talk, he's talked about it anywhere, about how they did it, why the heck they did this, and what are some of the methods and things they actually went about doing this.
So without further ado let's welcome Sachin.
Sachin: Thank you. Thanks Jerome and thanks everyone at ZURB for having me here and everyone for attending.
So yeah, I'd love to just sort of tell you guys the story of Posterous, how we got started, how its roots got sort of formed, and then obviously talking about the Spaces launch, which happened less than two weeks ago. It was just the biggest undertaking we've ever gone after in terms of our product and sort of where we want this company to go.
So for any product like Posterous, it's a consumer product, you need this like product visionary to sort of formulate what are we going after? Who are we building for? And all that. So, I'm not that guy. I'm an engineer disguised as a product guy. So, what I'm going to really talk to you about is not really like all these methodologies that we used, and that we're like so perfect and we therefore built this great product. There's actually a lot of learning a lot of mistakes, and a lot of just like interesting processes that we developed over the last few years that got us to where we are with Spaces.
So my background — I'm an engineer. I was a CS major at Stanford and then I went to go work at Apple. At Apple I was working on Final Cut Pro. So it's a professional video editing software. I was doing a lot of backend code for playback and real time effects. So it's as far as possible to consumer, to Internet, to product design. I didn't do any front-end code at all. So really looking at me you'd be like, "This guy knows nothing about how to start a consumer internet company." And that was true — I didn't.
So the way Posterous really started, the way that this sort of came about … so I'm an engineer at Apple and I was living in New York and I wanted to create an easier way for people to share photos online. I'd just got an iPhone and I'm like, "Okay, well this is the first time I've had an Internet enabled camera and why is it so hard for me to publish photos to the Internet?"
So I've always wanted to build something that works for normal people. I'm not the guy who wants to go and set up servers and host my own blogging software and things like that. I'm like, "What is the easiest way to just get this done?" So the easiest way was email. I wanted to just email photos and somehow magically these things should appear on my blog, and that's what happened.
I just wrote it for myself. There was no idea that this would ever turn into a company, no idea that I would ever hire anyone, or that anyone else but me would ever use this thing.
I think that's one of these really great lessons where, I didn't set out to start a company and then sort of search for a problem. I found a problem and just built it for myself. That's what allowed a non-product guy like myself to do this because I didn't do the user research or I didn't think of personas and who I'm trying to cater for — I just built it for myself. That doesn't work for all products and companies, but like I said, I was trying to start a company.
So that's how it started. I was the only guy using this thing. I started showing it to some friends and got some interest. Then in 2008 I got into Y Combinator and launched at TechCrunch. We had a really great launch, which sort of surprised me because I actually thought there was going to be a lot of, "Hey, email is dead. Why the hell are these guys betting on email? This is way too simple, I'm a tech nerd and I want something more powerful." But, actually, people really got the idea of it being so simple and the simplicity was what made it interesting.
So this is something that I've never talked about before. So some of the things that really made Posterous innovative on day one were complete accidents. We got branded right away as easy blogging, blogging by email, and it worked really well and it was really simple. One of the things that we got famous for was that when you wanted to email to your blog you would email it to [email protected], it was one email address.
So other services were giving secret email addresses. So you'd be XYZ123@flicker and somebody else would be XYZ1124@flicker — we had one. That wasn't some conscious product decision that I'd made like eight months ago. That was because I didn't know how to set up a mail server.
So the first version of Posterous that I was using has a Gmail address that I would email to and then my script would sort of like scrape it for photos and put it on my blog. If anybody figured out what that Gmail address, they could post to my blog, but I wasn't worried about stuff like that.
Another interesting thing was that you could email [email protected] without creating an account. It would just create a blog for you instantly and all that. Again, it wasn't that I necessarily thought that this would be cool, it was that I didn't want to build a registration system, and a login system, and a whole web interface because I wasn't a front-end guy.
So I'm like, "You know what? If I get an email from somebody I don't recognize I'll just do all the work automatically, I'll just make an account for them." Purely by accident and that really became one of our big marketing things upfront was, "Hey, this thing's so easy, just email us — you don't even need to sign up."
A third thing that's really big, and this is still big for us today, is the idea of auto posting where if you email Posterous — or post@posterous — we'll update your Twitter, Facebook, and all these other services. Again, it wasn't really this insight that this is something users want, my blog was posted on Blogger.
Before Posterous evolved to be a fully hosted platform, the idea was that I just wanted to build that little intermediate email gateway that would then post to other places and let Blogger continue to be my blog so even that really just came up accidentally.
When we became a fully hosted platform it sort of stuck around and expanded and became a really big part of what we did. So there was just a lot of really cool accidental innovation there.
So after we launched, for the next year or so, we listened to our users. The company would do help email, within the organizations every engineer, everybody at the company would take days to do that. It really helped us develop the product and listen to our users, and build to our people. This is something that I'd observe and is really, really important. So that worked really well and we continued to build features.
One of the interesting things that we did was we tried to figure out how are people using Posterous that maybe would surprise us. One of the ways that they were using us was for group collaboration. So what that meant was they would set up a Posterous site, make it private, add a bunch of different contributors to it. Because we worked so well over email they would sort of use us as a group collaboration email list product in place of Google Groups or Yahoo Groups because it was hosted and handled media really well and things like that.
So that's what led us to develop Posterous Groups, which we launched at the end of 2010. So that was really just going after this idea that normal people — and in fact our own users on Posterous — what they're looking for is better private sharing and controlled sharing.
Most normal people out there don't really want to blog and they don't really want to put their whole lives out in public, especially in long form text, which has been traditionally what people think of blogging, so we put that out there.
Traffic exploded, user growth exploded. Groups is a very viral product so people are inviting their family and their friends to participate in groups and that all came about organically from our users and what they were doing on Posterous. So again, if you listen to your users and you use that to . . . don't over listen to them, don't dictate your product road map, but use a lot of those insights, it can really take you in a good direction.
So the interesting thing that happened, the twist in the company — I don't want to say pivot — the sort of redesign process started at the beginning of this year … so this is about six or seven months ago. Posterous is doing well, we're growing, new users are coming on board every day, things are looking good, but we have these problems. These are like really, really big problems.
The first problem is that when you went to Posterous we had two products. We had sites and groups, and this is really confusing, "Do I want a site? Do I want a group? What's the difference? What's right for me?" So people just didn't know what the hell was going on anymore. We had a lot of technical debt. We'd been coding and hacking for two and a half years, and code is really crufty. It was really hard to maintain and to really move fast and build some really cool stuff.
We had a lot of design debt. So over the course of, again, two … three years … every time we added a feature, we added a button somewhere for users to use that feature. This is the problem, for us it made sense because we were learning the product over the course of two years, and our existing users … they are actually totally happy because they'd see a blog post and they'd be like, "Oh cool, Posterous just added whatever, the button for that here." They were just like, "Now Posterous has added this — the button for that is here."
So they learned this product over the course of years. Now you have this page that has like 50 buttons and no clear call to action on what you should do, but our users are totally thrilled because it does these 50 things and it's exactly the 50 things that they want it to do. But a new user comes onboard and they're like, "What the hell am I supposed to click on? What does this product do?" And they're totally, totally lost.
So there were just a lot of these issues with the current product that we were like, "We've got to do something bigger and we've got to fix this." Also, we were growing, but we've got to figure out what is the right way to, sort of, grow by an order of magnitude faster and figure out how to just ramp it up even quicker than it has been growing.
So this is when we sort of took a step back and we took a long time, like a month, to just sort of sit and think about, "What's Posterous? What are we building here?" And going back to the original idea from three years ago, which none of that had changed … it was helping normal people share online, an emphasis on email and mobile, and an emphasis on controlled sharing, which could be private. But controlled just means sharing different content with different people because, again, that's what normal people want and that's what we found that people on Posterous were already using us for, just because they figured it out.
So between all that we realized like, "What should this experience look like? Let's sort of take the risk to throw everything out. Nothing is sacred. No features have to stay if they don't make sense anymore. Let's sort of figure out what would be the best product for new users who are coming in to understand this and use this."
So what we ended up doing was we started by redesigning our mobile product. This was important for a few reasons. First of all we made the decision that this company as it moves forward is going to bet on being platform agnostic. So this is not a website that you can also use on your iPhone or website that you can also use on your Android, but this is a place where you share and whether your touch point is the web or the touch point is a mobile device, or purely email, or I think in the future television and things like that because that's where my mom is consuming content.
In the future, my mom is not going to own a PC. In fact, no one is going to own a PC in a few years except for engineers and designers … maybe. "Why am I building websites?" And also because I hate the Web. I think it's the lowest common denominator, not really a great experience. So we wanted to build the best mobile product possible and we started there. We also started there because it let our web guys rebuild all of our infrastructure and build this really great API while our mobile guys went and innovated on the design and that experience.
So again, that was sort of accidental; it just sort of worked out in terms of research allocation that that's what happened.
Yeah. So a couple of quick things on how we designed the mobile product — we sort of sat down and figured out what the feature sets were and mapped out the screens. Then we actually used Posterous Groups as a way to collaborate on the product itself. So we liked to see ourselves as the entire company has a product sense and the entire company is invited to all product discussions and helps innovate.
Again, that goes back to I'm not the product guy, I'm not alone in that. So what we would do is we had this cool process where we were going to do one screen per day for like 30 days and the app has like 30 screens. So we use a Posterous group, somebody would design it, email it into the system, there would be a lot of collaboration and a few revisions during the day, and then we would lock down on it by the end of the day.
This was like a first revision so obviously during the course of the six months of development we scrapped a lot of it and made a ton of mistakes, but it led us to really collaborate and build the initial design pretty quickly.
So once that design was done and the mobile team started to develop, the web team was freed up from all of their infrastructure and back-end work and then they started to work on the website. A lot of the learning that we had gained from the process of building the mobile app, the web team already had that to their advantage so that process went a lot faster.
If you go to the new website, it's very, very simple and it actually looks almost exactly like our mobile app in terms of the way things are laid out. That was one of our goals, consistency between the two products. That was also one of the hardest things for us to do right because we had two separate teams — we had a mobile team and a web team.
But, at some point, we realized that if these things don't look the same and act the same then this product is going to suck and people are going to get really confused again. So we sort of brought that together and let the web team really learn from what the mobile guys had done and go from there.
One of the things that we did for the first time in this release was user testing. I think it's said to say that for three years we had not done user testing. That was a huge, huge mistake. I believe that if you're trying to build a product for my mom to use, there is not a designer in the world who can claim that they're inside my mom's head. And that they can build something that's like, "Oh yeah, I built this thing so Sachin's mom would totally get it." Impossible, right?
So it … I think … it's really important for people to do user testing and to really take the input that you get to heart. So we had people come in and use our app and just rip it apart, just hate on it left and right, and also just be completely lost and just have no idea. It was really tempting to try to say, "Hey, these aren't really our users. This guy is a total weirdo. He's not a techie, so he doesn't get how this works."
Well, that's the problem, like these are your users and if they don't know how this thing works and they're confused, then your product really does stink and you should be willing to accept that, so some of the early user sessions were really brutal. I could totally imagine it be demoralizing you and saying, "We're building this thing and it's not going to work."
But my team would basically end a user session. Sometimes they would end it early because they would be like, "We don't need more feedback. We see a million issues now." Go to the whiteboard and iterate fast and 24 hours later just have these new designs, and three days later have a lot of this stuff implemented. Then we would bring in new users, and we'd just use Craigslist for that.
So it was cool to do the user testing as early as possible and then really just accept it and say like, "Yep, what you guys are saying is totally true." We sort of said that we weren't going to launch a product until it worked. It wasn't going to have a million bugs and it wasn't going to be confusing, so we just kept at it and kept doing user testing and refining before we actually said, "This is ready for market."
It was a really tough process. I don't know if I've ever heard of a start-up sort of stop for six to eight months to rebuild everything, but what we have now is a product that's much easier to use. Existing users are happy with it. We made sure that there was a really great transition path for them. New users really understand what Posterous is now. The goals were to really nail controlled sharing, and now we have a unified message around, "Why should you use Posterous Spaces? How do you use them?" And all that.
So besides the product stuff there was a ton of work on the marketing to figure out what our message is, how we're going to get this out there in the world? We redid all of the marketing pages on our website, from the homepage to our jobs page, about page. We made sure every sentence was consistent with what we were going after because we basically had one shot to get in front of the new users that were coming through the door.
So now we have this great new product and we also have this great new code base and this is what's going to let us move a lot faster. So sometimes you just have to bit the bullet, to just take that time off to fix it, to get over that technical debt that you've acquired over some time. If you don't, you're just going to move slower and slower and slower.
You become like Friendster. Your site just becomes so slow that no one's using it anymore. You also can't hire people because they're going to ask you what your stack looks like and you're like, "Well, we're on two-year-old versions of Rails." And this and this and this. They're like, "Dude, I don't want to work here."
And that's true. One of our board members came in and he's like, "If you guys don't upgrade these components to your system, you will not be able to hire somebody in six months." So it's hard to get around that, but the team did an amazing job to sort of balance technical debt with trying to put out a product. And it's really hard to sort of balance the two. But now that we're launched everyone's really psyched and I'm going on vacation next week for the first time.
So, yeah, that's pretty much it. It was an exciting process.
Moderator: Thanks, really good.
We'll open it up to your guys' questions too. Who's got a question?
(question asked … inaudible)
Sachin:Yeah, for the first part we found that anytime you make a major redesign to a site that actually has millions of users, you're going to piss people off and all that. But, besides that, we made a lot of mistakes as well with current users. So that's something that we didn't do enough of, was to bring existing users in to user test the new design, so that was definitely one of our mistakes.
For the big vision … the big vision is basically like where everyone's going to be sharing stuff online. Facebook does not cut it. Facebook is essentially public sharing at this point as your network is growing and all that. When people share it online, the number one way that people share privately is through email. So email works really well because it's really transparent, you can address it to multiple people, you know exactly who's seeing it.
So we want to build something that's as simple as that, but then it's hosted and archived so that you can go back in time and you can see what you posted before and sort of have media in the cloud. In the future, we're not going to have computers, we're not going to have hard drives so it's like, "Where do my photos live?" So sites like Facebook it's a stream. It's like, "I post a photo, some people see it, and then it's gone in a few minutes." We want to be the place where your photos live forever.
Audience Question: So Facebook has like their list and Google Plus is also going in this direction, do you think they're going to be the threats in the future?
Sachin: I think they're threats now, but we fundamentally have different models. So Posterous Spaces are symmetric groups, so basically the idea is you create a space for, like, your family and you add your 10 or 15 family members. They can all contribute into that one space. That's not how Google Circles works, that's not how Facebook Lists work.
So the way that their model is it's more of just like a fan of like, "Who can see this content?" But if I add my mom to Google Circle she can't share into that circle and that is not the way that email works. It's sort of like Google Circles, it's like using the BCC line.
It's like, if I address and I put 10 people in the BCC line, like my 10 family members, they can't reply and all that. So I think that's absolutely our competition and we think that Spaces matches real life sharing better than what they're doing.
So we were really doing two different things when we were doing sites and groups. That was one of the biggest reasons to merge those into one product. But then we do have all these existing users that are using us in all these interesting ways. So I think it's really hard to figure out what that one thing is once you already have a product out there in the market that's being used by a lot of people, but that's again where we use our users to help us.
I didn't really talk too much about metrics and instrumentation, but that as well is really like understanding what are people doing on the site and what's working. When you see what's working hopefully that sort of helps you distill down into one or a very few things that your product should be doing. I didn't run it myself, our marketing guy did. But from what I understand we basically put an ad on Craigslist looking for people to come in and test a new software product, but then we linked to a Wufoo form that basically asked questions like, "Do you share online? What's your technical expertise level? Do you have an iPhone?" things like to that to sort of try to figure out that we're getting people who aren't super techie but then also do use the Internet and do understand sort of . . .
Audience Question: Did you do a beta?
Sachin: I don't like the idea of beta. This is just my own philosophy, if you have a product that's out there, just take the risk and put it out there. I think, especially for companies like Google, they sort of hide behind the beta moniker of like, "Yeah, this is sort of done, it's not really done. If there are bugs in it you can't blame us because it's beta." Like, you know what? Just put it out there.
Audience Question: Do you pay [inaudible @26:32] …
Sachin: Oh, pay them. Oh, sorry I thought you said beta.
Moderator: Yeah, I mean screw beta.
Sachin: Yeah, screw beta. Yeah, we did pay them.
We saw trends really quickly. We were talking about this earlier. We'd get three users in the door and we saw instantly some of the big issues just like that. Then we do a lot of metrics and instrumentation now and that data is real time and you'll see changes instantly. It's like that story of the shade of blue for Google. If we wanted to run that experiment, we could do it in a day. It's just really amazing the tools that we have now. If we had to build our own analytics software, forget it. But now we use Mixpanel and there are other similar tools out there.
Audience Question: Did you actually put builds in front of customers too for those tasks or what did you actually run them through? Fully functioning builds?
Sachin: Yeah, fully functioning. So one of the things we did while developing this product was everything we were building was live on the site, only enabled for certain users. I meant that internally, in the company, we were all using the new stuff as our living, breathing app. Our board members at some point were all using it, our investors were all using it.
Then we could just sort of start to bring people in over time. So that was really nice because it meant we were getting real world use and it also meant that we didn't have this scary night before launch of like, "Oh my God, our entire codebase is just going to change." It was actually like, "No, we're just going to flip the switch so everyone's using the new stuff."
Y Combinator's awesome. I think that if you need help launching a company and all that, it gives you a lot of support. Again, I came from an engineering background. My dad is a business guy, but I never knew how to do any of the million other things that you have to do to run a company so they were the first step in learning all the other angles.
We've done an angel round, a Series A. Basically, the goal has always been just find investors who are passionate about your product. Don't worry about the price and all that sort of stuff.
We're happy now with Spaces. Our core message is much clearer than it was before, that it's controlled sharing and sharing in different groups. I think we rely mostly on word of mouth to get that message out there. That's always worked really well for us and with groups, specifically, it just works perfectly where people start a family space, invite their family, and then those people learn about the service.
If that one space is active and people are actually engaging on it and it's working, then those people realize, "Hey, I'm going to create other spaces for other things." So word of mouth users and then obviously the press has always been great for us and we appreciate it. They got the message, they were on the ball with what we were trying to do and what we're going after.
That's always a fear as well, that somebody gets it wrong. I mean, someone called us like the next photo sharing app and you're like, "We're not a photo sharing app." But mostly the press is great.
I think that you always have to start with this big vision and what you want to do especially when you have a team and they're going to march to your orders. If you don't have them, then they're going to lose interest and lose passion. But then you have to be willing to take the happenstance and when things happen a certain way and they work, then double down on that. If something happens in a way that doesn't work, then fix it, but I think just being open to that is important.
Moderator: I want to thank you very much for your time.
Sachin: Thanks. Thank you.
Moderator: I want to thank you guys so much for coming out today. Good talk, man.
Sachin: Yeah, thanks a lot.
