Koichi Hirano's Weblog

I have recently had the opportunity to interview Satoshi Nakajima and Yuuichiro Masui, developers of PhotoShare, an iPhone App from a startup called BigCanvas Inc. PhotoShare is a photo-lifelogging app—a photo version of twitter for iPhone, so to speak. Users can upload photos captured with the iPhone camera and share them with people publicly, with friends, or with family (e.g. sharing a baby's photos with the grandparents).

As of now (only 19 days since the release), more than 2000 photos are uploaded everyday at PhotoShare. Most of them come from iPhones all over the world. This is an amazing accomplishment to achieve from scratch for an unknown startup. I flew to Seattle to interview the developers in person.

What's Happening at PhotoShare?

Koichi Hirano (KH): I was surprised to see more than 2000 photos uploaded within two or three days of the launch. What is going on at PhotoShare now? Is it getting more popular?

Satoshi Nakajima (SN): Yes, we now have more than two thousand photos being uploaded every day. We have observed that many users are starting to use PhotoShare even more frequently. They now seem to be starting to use PhotoShare as a lifelogging tool. An example. I have a friend whom I met through PhotoShare in Japan. He uploads photos frequently, like what he had for lunch, where he was and so on. So I know he has had Ramen noodles for lunch for the past three days. He is sharing his life with me through PhotoShare. He looks like he is enjoying photo-lifelogging, and I am enjoying looking at his photo-lifelog. Our users are from all over the world including U.S., Japan, Hong Kong, U.K., Amsterdam, Canada and so on. That's what's been happening recently.

PhotoShare also has a very high participation ratio, too. A participation ratio is the ratio of the number of users who are actively generating content to the number of total users (active users + read-only users). At Web 2.0 Expo 2007, I saw a presentation which said YouTube's participation ratio was 0.4% or so. At PhotoShare the ratio is about 70%. I mean about 70% of users are uploading several photos every day.

KH: That's pretty high.

A Healthy User Community

SN: Additionally, our user community is very healthy. Users are protected from inappropriate photos now. At the beginning, some users uploaded pornography, which was against Apple's policy. We had a feature which allows any user to report inappropriate photos to us. When a user reported such a photo, we would review it and delete it when necessary. As it turned out that this manual process was too slow so we changed the feature. Now if any user alerts us about a photo, our app will keep the photo hidden until we review it.

Now, if a person uploads a pornographic or inappropriate photo, other users will flag the photo using this feature within several minutes. Recently, a user in the U.S. uploaded a photo of a hand-written piece of paper which said something like "Stop using stupid Asian letters!" which we thought was offensive to the diversity of the world. That photo got reported and hidden via user alerts, not from Asian users, but from other U.S. users. We are very impressed with healthiness of our community.

Why PhotoShare has Become so Popular

KH: It seems to me that the kind of success that you achieved it is next to impossible to have within two weeks of release on the web nowadays. You have huge competitors like Flickr, and many other giants in the Photo arena. It would seem like there is no room for late comers. What was your secret? Did you hire a PR firm to promote PhotoShare? Did you pay sexy users from MySpace to upload their photos at the beginning as promotion?

SN: We did hire a PR firm to promote PhotoShare inside the media, but this has not become effective yet. It may take time. And we didn't pay anybody to use PhotoShare. Therefore, this success has been purely due to the fact that we were able to submit the application to Apple by the deadline date, which was I think July 7th or 8th.

Yuuichiro Masui (YM): Our application was listed as the second app in the Social Networking category at the App Store (Apple's application store for iPhone users) at the very beginning, simply because our application name there was "Big Canvas PhotoShare" which starts with "B". So it was well-exposed to public at that time.

KH: It was reported that during the first 72 hours of the App Store launch, 10 million applications were downloaded.

YM: Yes. That way, we were able to reach people who were playing with various iPhone Apps.

SN: The reason we hired the PR firm was that we wanted to be mentioned at TechCrunch. But at the moment, not achieved it yet.

KH: So you are telling me that you not only have had no mention at TechCrunch, but you didn't even cheat by paying users to boost your apparent popularity? Basically your success is solely based on meeting the submission deadline at Apple? Your user community has grown organically, and PhotoShare's vision has been sufficient. I suppose I should ask you how you come up with this app?

Why Did You Start Your Company?

SN: To tell the truth, we originally started this project in order to obtain Yuuichiro's U.S. investor's visa. I met him in Tokyo in October 2007 for the first time. I could tell that he was a good geek and he said he wanted to live in the U.S. Within 30 minutes, I proposed that we should start up a company in the U.S. so that he could apply for a U.S. class E visa. We did not have any ideas for PhotoShare then. In March 2008, for the visa application purposes, we needed to write a business plan for the company. We had a discussion by chat. I brought several ideas, and the idea of a photo sharing service interested Yuuichiro. At that time, I was cracking the iPhone SDK (NB Apple released the iPhone SDK in the early of March 2008) and was really into it. So we decided to go for a photo sharing service as an iPhone App.

YM: I wanted to have a photo service with which I can share my daily photos with people like my grand parents, who are not internet-savvy. So in that sense, I liked the plan. However, I was also very skeptical about the idea of photo sharing. It was obvious that there were many photo sharing/storage players like Flickr and I was not sure how we could really differentiate our prospective service.

PhotoShare Underdoing Competition

KH: PhotoShare users seem to be developing a culture that's quite different from Flickr's. Flickr users spend a lot of time to making their photos beautiful and even artistic, whereas PhotoShare users are just uploading quick snapshots casually and frequently. The vision of PhotoShare, or "Photo-lifelogging", seems to be understood and well-received by many users, and this vision itself has successfully differentiated PhotoShare from other players. So I want to know how you come up with the vision? Did you have that in mind from the very beginning?

SN: Well, I wish I could say I'd had that vision clearly from the beginning, but I didn't (laugh). However, we reached the progression to this vision very naturally because there were already several popular photo sharing/storage services on the internet. Due to this fact, we knew we had to fully leverage the fact that we had nothing. You know Flickr already had tons of accounts, which we didn't have at all. We were really a new startup. Thus the logical conclusion was that we should aim for non-Flickr users. I mean people who don't even know what Flickr is. We figured that this market would be huge. Another key point was to make the app so that new users can register very easily, meaning the registration process should be throughly minimized. If Flickr develops an iPhone app, it is obvious that users will sync their account information with the iPhone app. So we knew that our app needed to excel in this regard to compete with existing Flickr users' experiences on iPhones. And we started with the very simple idea of sharing photos of people's daily life with friends or families. So even though we concretized our vision of "Photo-lifelogging" later, the idea was already there when we started planning the app. Once we decided on our vision, we did not look at the features of any other existing players. We felt that would have caused us to start to adding this feature and that feature and end up with an unusable app. We just focused on our vision.

KH: If you are targeting non-webby people, you really don't need to be mentioned by TechCrunch. TechCrunch is really a popular media among VCs, startups, web designers, programmers and heavy users of web, but none of them are your target demographic. So even if TechCrunch had posted about PhotoShare, there might have been no positive impact to your target prospective users. Perhaps it was lucky for you that you didn't make it into a TechCrunch post at the beginning.

YM/SN: (Laugh)

SN: I could describe our service to potential investors very nicely now. We have seen the advent of the Text communication age that followed the onset of voice communication. Now this age will lead to photo communication..... or something like that. But we are not actually interested in investors.

We Were Supposed to Win Apple iPhone App Award

KH: I read Satoshi's blog post in which he declared you were determined to win the Apple iPhone App Award.

SN: We were there at WWDC to receive the award. It turned out that many winners are famous players on the web such as Twitterrific, AOL and OmniFocus, but not new startups like us.

KH: The best iPhone Show Case in the social networking category was Twitterrific. Although I think Twitterrrific is a great app, I wrote about this in my post arguing that PhotoShare should have won the award because you guys show the fullest potential of Apple's platform, without relying on user assets on the web.

YM: Two or three people from apple seemed to review our app quickly and left. They did not carefully look at PhotoShare. And at that time, there were only three test users who had uploaded photos, Me, Satoshi, and my wife. The contents might not have been particularly exciting at that time.

PhotoShare Running on the Cloud

KH: So you were ready for the award? Also, in your blog post, you said that you were trying to handle 300 thousand users. How did you design your backend?

YM: We are running all of our servers on Amazon EC2 and storing uploaded photos at Amazon S3. The backend is built on Ruby on Rails. There are two big EC2 instances for database servers, one instance for load balancing with PerlBal, one for caching contents, two for Apache, and some for mongrel.

KH: Somewhere, you said your performance criteria was handling 300 thousand users. So, that is roughly one photo upload per second? That's about 46000 photos daily.

YM: Yes, we can handle that now. And we can scale out very easily by adding mongrel instances and changing the load balancer configuration a bit.

PhotoShare, Only 2 Developers and Not Hiring

Photo: Satoshi Nakajima (Left), Yuuichiro Masui (Right)

KH: Now tell me about your team. How many people do you have there? When did you start developing it?

YM: Satoshi does the iPhone side development, and I do the backend and keep the servers on the cloud running. And we also have Adam who oversees legal and operational things. In total, 2 geeks and 1 suit.

We started to develop this app during the second week of April, 2008. The submission deadline date at App Store was July 7th. We had only three months. In my professional experience, I used to spend 2-3 months to set up a robust, reliable infrastructure. Satoshi told me to prepare an infrastructure which could handle 300 thousand users. That was to assure the reliability of the project. But we also had to complete user interface design, application development, and building the infrastructure all in the three months. I shouted "No, I don't have enough time!"

SN: Indeed. If any of us had caught a cold during the three months, we could have never finished that by the deadline date.

YM: I worked from 10am to 3am, and Satoshi worked from 3am and went to bed at around 11pm.

SN: It was only possible because this project was ours and there were only two passionate developers. We are not VC-backed. If we felt any part of project was owned by somebody else, we would not have been that motivated. If we had one million dollars invested by VCs, we would probably not be successful, either. With one million, VCs would tell us set goals, spend a lot of money, hire people, and achieve the goals. We would need to give fancy presentations to VCs regularly which would consume our time, and would need to spend time to hiring and managing people. Under those circumstances, we would not have finished the development within those three months. We are two motivated developers, and that had turned out to be enough and efficient. We are the guys who brought this miracle to pass. We are not aiming to be VC-backed. It's just because we would like to be successful.

KH: I believe the 37signals people would love to hear about your method of success, although the TechCrunch people would not be very happy about it.

SN+YM: The key was not to hire people.

Next Small Things, But Not Next Big Thing

KH: What is the next thing for you at PhotoShare?

SN: First of all, we would like to build our community and provide continuous tweaks to satisfy our users. Then, we would like to introduce some priced plugins for PhotoShare, such as a photo editor or annotator for further enjoyment. The price of these tools should be equivalent to a cup of coffee. If the number of users is large enough and 5% of users purchase the plugins, we could be pretty profitable as we are only three people. That is our business model. We would like to run our company like a good local Italian restaurant. We will spend a week or so to develop a plugin, then release it to see how it goes. We would like to do this kind of things with various ideas. An italian restaurant would not invest a year in preparing new a la carte menu item would it? They just add a new dish after spending about a week experimenting. If it does not do well, they just take it off of the menu. That is it.

KH: When will you introduce the plugins?

SN: It will be after we are confident in the growth of our community. We hope it will be at the beginning of 2009. One idea is for a preset device which a user can send to less tech-savvy users like grandparents to share their uploaded photos in a television. We have plenty of other ideas along these lines.

Apple vs Microsoft

KH: Do you have any comment on Apple? iTunes, iPhone, or iPhone App Store?

SN: Just that it's incredible. I want to say "Hey, what were you doing Microsoft?" Apple announced the iPhone SDK at the beginning of this year 2008, and released it at the beginning of March 2008. It has been only seven months since the announcement. Now, there are more developers for it than those around Windows Mobile or Symbian OS. Developers are moving from those platforms to the iPhone because they understand they can do much more interesting things on iPhones. I should point out that iPhone excels in terms of hardware and its operating system. In that sense, Microsoft is three years behind iPhone.

KH: Satoshi, you could go back to Microsoft and rewrite the Windows Mobile OS from scratch (Note: Satoshi Nakajima lead a Windows 95 developing team at Microsoft).

SN: I would hate to do that. I could do that technically speaking, but I don't have any real motivation because Microsoft is not my company. The very key to us is building a small team and growing it organically. In that sense, our future success, if any, will be simply because our company was founded for Yuuichiro's visa application. You can not start up a company with VC money for a visa of a person.

KH: Satoshi and Yuuichiro, thank you so much for this stimulating discussion.

Agile Software Development is a style of software development which has been gaining popularity. According to a former colleague, upwards of 10% of corporate software development projects in North America are now conducted this style. Agile Development (hereafter Agile) is to beat the long lasting development style called Water Fall Model (hereafter WF).

Suppose you want to build a dream house. With WF, you hire an architect who designs all the elements of the house . You then move onto the actual building stage (i.e. foundation -> framing -> plumbing/wiring -> walling -> flooring etc). Once you start, you are relatively locked in to the plans. You cannot abruptly change things and decide that a faucet should be installed in a completely different location. Well, you could, but it would be very costly. In this model, the longer things continue to be built, the more unexpectedly things may turn out. And it may not be at all like you imagined. Within the WF model, once a project is in motion, and the "water is flowing," you cannot really go back "upstream" (i.e. the design stage). Instead you must wait for the design to run it's course, and then pay for it. Once the project is in motion you don't have much control.

Agile however addresses the above problems. Agile developers always work with the client step-by-step from the design stage to the flooring installation. Agile developers in fact welcome changes to the plans so they can ultimately build a better home. They always try to show what the actual finished product will be like along the way while working, or in the form of a mock-up made at least to scale. This way the client can confirm what the finished product will look like before it is completed. In a nutshell, Agile's strength is that it permits change derived from mutual conversation with clients throughout the development process.

One very specific and opinionated approach of applying Agile Software Development to create web products efficiently is called Getting Real. Created by Chicago-based company 37signals, Getting Real utilizes Agile Development to build the best web product possible. One of the greatest challenges to developing a successful web product is the fact that you have not met your potential users in person. Also, potential users are quite diverse in their needs and internet savvy. So, you need to explore what would be the best features and interface for millions of different users, which is pretty challenging to do at the beginning of a project. WF doesn't work here because it requires a plan for the product to be set before the construction can begin. But what is really needed is exploration.

Getting Real is quite agile, in the sense that you can create a product step by step, and in each step you observe customer behavior and take into account client feedback. From there you can adjust the product to implement the most recent feedback. If it doesn't work, you can easily go back to the previous step. This rewinding in product development can be confusing to clients at times, but this can be avoided if the changes (or "tweaks" as we call them) are small enough.

37signals' project management product, Basecamp, which I recently started using for coordinating this blogging project with my proof reader Emily (whom I utilize as I am not a native English speaker), was developed with Getting Real. 37signals created Basecamp five years ago. Currently, they have more than 2 million users, and they still continue to change and tweak the product little by little fairly frequently (sometimes weekly, or even daily). It seems that Emily understood how to use Basecamp almost instantaneously. In fact, she did not even ask me any questions about how to use it, and she figured out very quickly what can and cannot be done with the built-in wiki called Writeboard. For several reasons, we are drafting the actual blog posts on Google Docs and doing the rest (like To-Do management and messaging) on Basecamp. The point I am making is not that that there is anything wrong with Writeboard, but that she had to spend only a few minutes exploring Basecamp to grasp what it could and couldn't do. From there it was easy to make a decision—that we should just use Google Docs for editing my blog drafts. It is very easy to understand and therefore made it very quick to reach a decision. We did not have to spend hours figuring out how to do this and that. 37signals has spent five Getting Real years slowly crafting Basecamp in to the outstanding work of art that it is, and as a result it is easy to use, intuitive, and requires no manuals or training.

While Agile development may seem like a logical model, it is actually rare to see it implemented in the real world. I'm sure you have experienced this already. For example, when you call customer service at a company to complain about something, the customer service reps seem like they are listening to your concerns, but they are probably just being polite. If the service reps were working in an agile manner on a web product, they would need to report your complaint to their boss, who would then compile a list of all complaints and once a month report to the VP of Engineering. The VP of Engineering would then prioritize the complaints and pass the highest priority items on to the developers. In this case there are several steps or filters that your complaint must pass through to go from your lips to the ears of the guys actually developing the project. Although the developers try to be agile, there are too many steps in the process. This is what happens in most businesses. Getting Real, however recognizes this problem and recommends doing everything as a very small team. For example a team consisting of myself acting both as a core developer and customer support staff at the same time so as to avoid unnecessary steps in between input and action.

So my company OneAgileTeam remains small, and applies the Getting Real approach wherever applicable. We strive to fully understand both identified and unidentified business needs and fulfill them in the most agile, simple and timely manner possible. And by timely, I mean a few hours to a few weeks at the most. This is the main objective at OneAgileTeam.