Michael Wong blogs here

Lessons from Eventplease

For almost two years, I’ve worked on an idea we called Eventplease, an online social event calendar for Harvard three friends and I built together. It’s been such a thrill to have worked on this project with an amazing group of individuals. I’ve wanted to write down the experience in some detail and perhaps our experience will be useful for someone who wants to start a company.

The Beginning and Launch

For me, Eventplease started as a hunch I had one morning during the fall semester in 2010. I was a college junior and had begun thinking about starting a business as my interest in computer science and entrepreneurship grew. The hunch was a result of my frustrations with event organization. After struggling with putting together an event for the cultural student group I belonged to, I wanted to solve the pain of advertising around the campus.

As I began think about event publicity, I found that there was also a parallel pain for students who wanted to attend events. I wanted to help them discover events that were interesting. I wanted to create some kind of directory for events on campus, which I believed would get a lot of traffic.

Soon I began to talk to a lot of people about my idea and began to sketch out what such a product might look like. My dorm room walls soon became covered with paper prototypes. Knowing very little about web development at the time, I looked around for people to help me. Two of my good friends – Stefan Muller and Spencer Chan – signed up, and by December 2010 we began to write code during our spare time. Stefan was in charge of building the backend. Spencer and I worked on the front end.

We did some things correctly from the beginning. For example, we decided to set up a code repository system Mercurial and hosted it on Bitbucket. This helped us keep track of our code throughout our time working on Eventplease. We also applied to and attended HackHarvard, a student-led incubator for campus apps. This incubator turned out to be one of our most productive periods. Fatefully, this incubator introduced us to the student government at Harvard, which immensely helped us publicize the website.

Some other decisions turned out poorly. We decided to write the site in PHP without a framework, simply because we all knew how to do that. In the end, our code became quite messy and difficult to manipulate. Also, we set out to build a pretty substantial product from the beginning, and I believe we completely over-engineered our first iteration of the product.

By March, we had built most of the functionality we had set out to build, which include user login, a form for users to create groups and submit events, and a feed that recommended personalized posted events. Around that time I invited Alisha Ramos to join our group, and she immediately began to help adding style and swag to the site. She edited all the wording on the site and changed our color scheme to what it is now.

We collaborated with the student government for our launch in early April. They passed a resolution to endorse us and then we worked with the student relations committee to publicize the website through emails to the houses as well as to student groups. Working with the UC also led to coverage by the Crimson, the student paper. The day we launched we got about 1000 thousand views. Student groups excitedly signed up. We soon had over 100 events up. We made an effort to publicize during prefrosh weekend as well the Arts First weekend, and our visitor count stayed strong and we got an average of 300 views per day until exams began in May. By the end of the semester we felt pretty good about our first launch and began to discuss how to keep going. We decided to begin our expansion to other schools and celebrated with champagne.

The Hiatus

We made some progress during the summer, but it was slow since we each went off to do our own things. I spent my summer in Chicago interning for Steve Levitt. Stefan and Spencer stayed on campus to do computer science research, while Alisha went to work for a VC firm. We dealt with server issues and making the site ready to be duplicated for other campuses.

I also talked to two people from other schools who were interested in what we were working on, and we began to set up sites for them. It was my first time trying to sell something and I failed terribly. I had no experience selling and marketing things, and being distracted by an internship and a side project I had started with a co-worker didn’t help either. We had the sites ready by August, but unfortunately by that time the interest from the two people had died.

Then September rolled around and school was back. We failed to relaunch Eventplease to the student body, however. We didn’t put in the same effort to publicize Eventplease the way we used to. The UC was busy tending to different business. Traffic was a fraction of last April’s. My attempt at getting the word out to student group leaders at the activities fair went quite poorly. Furthermore, we began to freak out about needing a job for when we graduated, since on-campus recruiting was beginning. For the next couple of months, I had practically let Eventplease languish.

In January, the UC approached us again with renewed enthusiasm for pushing Eventplease back to the students. By then our team hadn’t met in a long time, so basically I was the main person making changes to the site and communicating with the UC. We re-publicized the website, just as we did last time. There was a bump in traffic, but still the website didn’t quite catch fire like it did a year ago. As a team, we met again to decide to simply hand over the site to the UC to administer in the future. We made some cosmetic changes to the site before we did so. By summer, Eventplease belonged to the UC.

Some lessons

When you make mistakes, there’s always the danger of learning the wrong lessons. Here are my lessons learned as I see them:

###1. Keep your eyes on the ball. Keep the team focused and moving.

A successful team must have a leader. This person is the cheerleader, the convener, and the person who makes sure everything gets done. It is critical for a team to be led consistently, or else the team will begin to drift and disintegrate. The leader provides the anchor for the team. Being a leader is a large burden and is usually a big job. You have to decide things and put a lot of effort in.

Without a leader a project will not go on. When a leader fails to take charge, the only way for the project to survive is if his role taken over by another. For a very early stage startup, this rarely happens. What stopped our momentum was summer holiday and recruiting, which had caused me, the de-facto leader, to stop doing the things a leader should do. Eventplease became my second priority. We stopped meeting our short term goals. We stopped convening regularly.

To succeed your team must stay focused on goals you set. Set reachable goals and accumulate small successes. Once we stopped doing this, we never regained momentum.

###2. Never wait for the customer to come to you.

Technical founders tend to focus completely on building a great product. That’s usually a recipe for disaster.

We made the mistake of waiting for customers to come to us. Well, not quite. We knew that we can’t just wait for customers to come to us, but we never had a focused plan to get in front of our customers. We never made a list of customers to target and persist in trying to sell them our product.

Don’t underestimate the effort necessary to get people to use even a good product. Most of the time people aren’t creatures of reason, but creatures of habit. Most people don’t want to try new things even if they’re better. People don’t go out of the way to learn about the best products in the market. If you’re a developer, you’re probably in the category of most likely to be excited about new gadgets. Don’t expect others to behave like you.

Have a plan for getting your product out early on. Make a list of people you want to reach, and figure out how to reach them. Set actionable goals for sales.

Of course, the product should be friendly to new users too. Make sure the user takes the absolute minimal amount of effort to start using your product, and that you put the product out as prominently as you can! Have viral components.

Furthermore, you should always know what your most loyal customers love about your product. Don’t ever let that love go away. So talk to your users. Find out who they are and what they need. Show them love, and they will love you back.

###3. Test your product idea in baby steps until you find its essence.

Your first hunch is almost always somewhat wrong. Looking back, it is clear the initial idea was flawed.

At the time, connecting people with events online mainly happened in several ways: One was in a marketplace for event tickets, like Eventbrite or Ticketmaster. These sites made event organizers happy by saving them the pain of figuring out how to sell tickets online. The other was marketing, like Facebook Events. Marketing goes where the user is – which is why ads work in search engines and social media. There’s also Meetup, which helps event organizers organize and communicate. These products solve real pains.

When I had the idea of Eventplease, I was in a hurry to get it done. I wanted a complete product ASAP. I had embraced my first hunch too fast too thoroughly. People told hz they wanted something like Eventplease. On paper it sounded great to them. But it takes a lot of time to find the pain points. There is probably still lots pain involved in event publicity and discovery processes, but we just didn’t manage find exactly enough pain to sustain demand before we ran out of steam.

So what do you do? Say you have an idea. You should first test the idea, by which I mean you should work really hard to understand the market need that your product is supposed to address. To sell something, you must know exactly what it is that people really want. This demand is often surprising. Think of Facemash or the first Groupon product. These are extremely simply prototypes to build, but their viral growth indicated a demand for something. Billion dollar companies grew out once their founders identified the demand.

Sometimes it’s hard to find the exact market need and you really have to persist. Airbnb existed almost for two years before it began to gain steam. Once you find that demand, you’ve begun to uncover the essence of the idea.

Furthermore, there’s no doubt that we over-engineered our first product. We build too many webpages and we included too many features. When users came to our webpage, the workflow was too complicated. What would have been better is to have a very simple product that did one thing well. If it didn’t work, try a new thing. Iterate until something worked. By building it all at once actually distracted both us and the users from the product’s essence.

###4. Obsess about design and user workflow.

I believe we built a decent product with good design and style, but we did not obsess sufficiently about the user workflow. We simply were not sufficiently perfectionist or dedicated to make the user experience absolutely impeccable. It did not wow users to the extent that it needed to. I don’t mean that the website must be sexy, but it should give the sense that something revolutionary is happening at your company. Your product should inspire confidence and love. It should be mindless to use. Instead we kept piling on functionality, which was good but insufficient. Build this kind of company culture and you will appear different to others

###5. Take good care of your business partners.

Simple: these people are the essential to your success. Get to know them. Love them, until they love you back.

###6. Gimmicks work!

One realization we had along the way was simply how effective gimmicks and traditional advertising were. Postering, flyers, lotteries – these gimmicky marketing tactics proved immensely useful in getting the word out.

###7. Use good open source tools and seek advice

Don’t reinvent the wheel. There are fantastic tools out there, so look for them! I wish we didn’t code in pure PHP and roll our own abstraction framework. It was only a year later when I was introduced to micro-frameworks like Flask, and they really do make your life a lot easier. So do some research and seek good advice before you start writing code.

###8. Have fun

Seriously, I had so much fun trying to make Eventplease happen. It was tough. I was stressed out. And yes, it was probably a pretty perverted sense of fun. But the high you get from pushing something that is uniquely yours forward in the world is just amazing! So don’t be discouraged by the mistakes you’ll make along the way. Enjoy it.

Read more here. Or send me feedback and comments.