The idea for ImThere was born in July ‘05 out of necessity—it was a chore finding fun stuff to do around town. Fifteen months and many pots of tea later, we launched a service that we had hardly even tried to use. Soon after, we began questioning if it was what we even wanted.
Last June we finally launched the ImThere we had envisioned over two years ago. We are now finally able to find stuff to do that we wouldn’t have known about otherwise.
And So it Began…
Development of ImThere seemed clear-cut. The functionality was outlined and broken up into the site’s distinct pages. We let our designer and two developers figure out how best to design and architect the site. Once we prioritized the functionality to be developed and the pages to be designed, we created a weekly schedule providing a roadmap to launch. We appeared to be off to a smooth start.
What Our Team Began With
Our first glimpse of ImThere came three weeks later, when our designer uploaded his first pass at the main page. It looked great. That, combined with our excitement seeing ImThere for the first time, resulted in joyous expletives. Once we calmed down and compiled actual feedback, we had a list of items like:
- “The green arrow submit buttons are too bright and distract a little”
- “Let’s change Weekly to Daily on the featured venue/artist”
- “It looks like the View More links for Important Events and Hot Events have different font weights”
Valid feedback, but completely focused on aesthetics and nitpick-y details.
Revisions of the Main Page
As the design progressed, the developers were hard at work on the back-end. From content targeting to popularity algorithms to exotic data handling, we had very lofty goals—all to be included in version 1.0. Even seemingly simple things turned into intricate projects requiring custom code, rather than using what Ruby on Rails, the ImThere platform of choice, provided.
With three months of the back-end work complete, designs began to be applied to the website. Despite the immense back-end functionality, the front-end appeared extremely basic. The event, venue, artist, and user pages were pulling data from the database, and data could be entered through crude forms. But it was a start, and we were thrilled to finally have the developers working on something we could see. However, given the back-end functionality still needed for the launch, the front-end work moved sluggishly.
Logged In Users Saw a Different Main Page
Another three months later, even though the website was shaping up, our position was similar. Entering data was a chore, and there were too few ways to interact with the website. Even so, we felt the time had come to release something. We rushed to flesh out the remaining pages and smooth things out as well as we could. As time ran short, we began cutting the visual elements that were not yet coded. Finally, after a 30-hour marathon coding session, we launched.
Kicking it Out the Door
When a launch finally arrives, an indefinable feeling runs through everyone involved. It’s a mix of excitement, relief, and anxiety over what happens next. In our case, the anxiety turned to eerie silence as we saw people leaving the website soon after arriving. Truthfully, we couldn’t blame them. Since many of the planned interactive features were scrapped to get ImThere out the door, there wasn’t actually much to do. And since we couldn’t add content until right before the launch, there wasn’t much to see either. Our team even struggled to use it and found little value or enjoyment.
Warning Users About What They Were Getting Into
Over the next two months we slaved over the code to add missing features, develop new ideas, and fix up the remaining bugs. The website became unquestionably better, but people still weren’t latching on. Not only that, we were even still forcing ourselves to use it. It was a bad situation; no one was falling in love with it no matter what we tried.
There comes a time when you have to accept things just aren’t working, and you need to take a step back to figure out what’s really wrong. After just a few months, we had reached that point.
Taking a Step Back
At first, we were confused as to what the problem was. We had successfully implemented the functionality we had originally defined, and the few remaining missing elements couldn’t explain the state we were in. The website looked great, so that couldn’t be the problem either. After dragging ourselves away from development for the first time in nearly nine months, it dawned on us what had happened—we had taken a feature list and developed it into a website.
What we built had very little flow to it and felt forced. Each page seemed so disparate from the others that users couldn’t get the big picture, let alone find reasons to use it. It felt like a bunch of random features bundled into the form of a social event-themed service. The problem became even more apparent when we struggled to recall what the original vision was. The feature list not only dictated the design and development, but also became our guide to describing ImThere to others. We were in trouble.
The good news was that it was easy to see everything we had done wrong:
- ImThere was built and designed around a feature list
- Aesthetics were the focus of the design, with little thought put into actual usability
- Coding the high-concept back-end consumed nearly all of developer time
- We tried to do too much for a version 1.0 website, and didn’t have the focus to pull it off
- We never really tried using the website before launch, due in part to its incompleteness
Taking those missteps resulted in a myriad of problems:
- ImThere felt one-dimensional and lacked continuity, preventing it from being useful or fun
- The purpose of ImThere was unclear to users
- Users would have to adapt to using the website since few things were intuitive
- Much of the advanced back-end was left unexposed in the front-end
Our brand new website was fatally flawed. It just felt wrong and no amount of Band-Aids could fix it. Furthermore, in the meantime, a number of other social event services launched. When ImThere was originally envisioned, none existed. Now, in addition to problems with the website, much of our originality was lost. Our next move was obvious.
We had to scrap it.
That was remarkably hard to do after putting so much effort into something that had barely seen the light of day. We knew we would have to reinvent and completely rebuild ImThere, while being cautious not to repeat the same mistakes. Of course all websites iterate and iterate, but we had to do it in an extreme way. And do it we did.
Getting it Right
Before telling the team to scrap everything they had coded and designed, we first wanted a plan that was solid, realistic, and fully thought out. We began by focusing on the useful and fun qualities, which fortunately came together quickly. Our efforts also focused on overcoming the limitations of launching city-by-city, which our initial plan called for. A solution did come to us, and ended up being the cornerstone for the new ImThere. We would support “locationless” events in addition to local ones, which could include things like movie premieres, the release of the iPhone, Talk Like a Pirate Day, and even virtual events. These events could be relevant to anyone, allowing a ‘net-wide launch and providing ImThere an identity distinct from our new competitors.
Feeling confident about our refined and solidified vision, we set out to really plan it. This time we were determined to avoid the same traps. We locked ourselves in 24-hour coffee shops for a couple of weeks and extensively planned out every page. We would keep sketching out each page until we had it just right, and flesh out wireframes in the fantastic OmniGraffle application.
The First ImThere Wireframe
A big theme for the new website was reusability. Many elements like feeds, content streams, listings, and timelines were shared on pages throughout the website. Our event, venue, artist, and user pages shared the same base which was then tweaked for their individual needs. Other pages worked similarly; determine the necessary elements, and then tweak the page for its specific purpose. This process allowed the developers to perfect common elements and rapidly build out pages. It also allowed us to reduce the number of interfaces a user had to become familiar with.
Throughout development, we anticipated the various ways a user might use ImThere. For each page and feature, we thought about how a user would discover it, use it, and continue on through the website. When we were done, ImThere felt fluid, open, purposeful, and fun! We went from thinking “we want to use a service like ImThere” to “we want to use ImThere.” It provided reassurance that we were doing things right this time.
The differences were obvious; this time we had:
- Developed a complete idea, not just a list of features
- Wireframed every page of the website, forcing us to work through the flow and usability
- Took development time into consideration and found ways to avoid spending months on just the back-end
- Took a step back before development started to make sure this we had what we really wanted
We had to build the first version of ImThere to know to do these things. The lessons we learned were worth every second spent and the new ImThere could not exist without them. Looking back can be tough, but you later realize you had to take the steps you did. Fortunately, we realized our mistakes quickly enough to have the time to take our next step.
Take Two
Next came getting the team onboard with the new vision and getting their feedback. Their opinions were extremely valuable, especially since it was completely fresh to them. Everyone on the team was on the same page and embraced the opportunity to have a second shot at making ImThere the service we all wanted.
Both design and development went dramatically smoother the second time around. It was more clear what needed to be built which sped everything up and made for more realistic scheduling. Wireframes allowed for more design time to be spent on usability and less time on what needed to go where. Once the look and feel of the website was nailed down, the remaining pages went through relatively few revisions compared to pages for the first website. We were able to do this not only due to the wireframes, but also to sharing elements across pages. Towards the end of development, we even had the luxury of tweaking the design, which we had no time for even after launching the first ImThere.
Revisions of the New Main Page
Visual results began shortly after coding. We were able to carry over some back-end code, reducing the time it took to start on the front-end. This allowed us to start using the website very early on, which had been one of the biggest problems before. For the first time we could find out what worked and revise what didn’t. On the first version of ImThere we weren’t even able to add events until the last week of development, but now we could begin adding, modifying, and interacting with content months before launching the new ImThere. Around this time a bug tracking service called Lighthouse was released, which made reporting bugs enjoyable and manageable. It allowed us to report, prioritize, and track every little thing that wasn’t quite right.
From 0 to 3 Weeks
We ended up launching this past June, which was later than we had hoped. However, it was to allow us to add little features we wanted and polish the website, not to develop rudimentary functionality. About a month prior to launch, we let a variety of people in for a private beta. This was something we hadn’t even dreamt of doing with the first version. During the final month, we fixed all known bugs, finished the last of the features planned for launch, and tweaked and tweaked everything.
Once Lighthouse reported 0 remaining pre-launch tickets, we launched the new ImThere—the ImThere we all wanted.
Easing it Out the Door
After pushing the elusive launch button and drinking the obligatory champagne, we found ourselves on our laptops, sitting around a table at one of our developer’s houses. We weren’t frantically fixing bugs to keep the website from crashing, nor were we trying to code last-minute features. We were simply using ImThere and enjoying it.
As the first batch of users rolled in, we interacted with them and watched how they were using the website. They filled out their profiles, commented on events, sent messages, just explored around. No one left right away. From a statistical standpoint, our pageview to unique ratio was very favorable. That is a good sign, because even without stellar uniques, having people stick around means you are doing something right. All in all, our launch went as well as we could have hoped, and it seemed that we were finally on track.
Getting the User Page Right (old -> wireframe -> new)
We quickly got off our post-launch high and went back to work. For the first time, we had a solid base to build upon and could begin making forward progress. Our work over the next few months consisted of:
- Gauging initial user response and improving the areas that needed it
- Building the features we had put off until after launch
- Evolving our existing features to make them more useful
- Getting the word out to start building up our userbase
As we worked we would frequently take a step back to ensure we were on track and sticking to our vision. After our first time around, it was very important to make sure we didn’t waste a second working on the wrong thing. We were now focusing our work on strengthening the identity of ImThere, something we had failed to accomplish before. Since ImThere was designed in an open way to support a broad scope of content, it was challenging to make the value of the service immediately apparent to users. That concern drove our early focus on building utility-based features, like an invitation system, so prospective users could quickly find value. The hope is that once they sign up and begin using ImThere, they will see the big picture.
With a few post-launch months under our belt, ImThere was ready for the masses, and our next set of big ideas.
Where We Are Now
Over two years later we finally have the fundamentals in place and can enjoy making ImThere great. We are now faced with a new set of obstacles: reaching more users and demonstrating the value of the service to them. We also must keep looking into the future for ideas to maintain ImThere’s uniqueness and rapidly develop those ideas into realities. No matter how satisfied we are, standing still can never be an option.
Redesigned Signup System Based on User Feedback
The team is already working hard to evolve the very essence of ImThere. At the center of this evolution is the one key idea still missing from the original vision. Implementing this idea couldn’t have happened or even re-entered our minds without building the open, community-driven service we have now. With those fundamentals in place, the idea that began our journey returned, and proved to be a solution for our current obstacles.
ImThere Today
This further demonstrates that if something isn’t working, you need to look back and figure out what got you excited in the first place. That is how we put ImThere back on track and why we have full confidence that it will soon be a success.
Great article, David … thanks a lot!
It’s always enlightening in general to read about the process of creating a web app. In particular, the bits in this article about how you failed and what you did to fix it. Thanks.
Your new site looks great and is really engaging… There was a couple events that were very interesting to me, and I was really drawn to the “click to say I’m there” buttons…. so it looks like your flow is starting well… but I must say that the big orange sign up page really hurts my eyes. That’s where I gave up.
I’d keep the color scheme consistent with the homepage and/or simplify the sign up form (remove anything distracting on that page, and do you really need a username, full name and email address?)
[…] This article documents the startup and stopping and restart of a web-app-based startup. […]
Thanks for all of the comments! The feedback is very appreciated.
Regarding the signup color scheme shift, you’re absolutely right. We’re working right now to have it load inline with the color scheme of the page you’re on. This change should be up on the site within the next few hours. Let me know if you find this more appealing.
Very interesting article!
OmniGraffle looks like the tool I need, but do you know of a similar program, that runs under either XP, Vista or Ubuntu 7.04?
Honestly, I’m not too familiar with similar programs on other platforms. I think Microsoft Visio may do what you want, but I’m sure there are other options that I’m not aware of.
Oh, and by the way - there’s no response, when I click the “SIGN UP NOW”-button in Firefox 2.0.0.6 on Vista…
It looks like we’re having a slight problem right now with locations that have special characters in their name. We’re working quickly to fix it, and I’ll respond as soon as it’s resolved. I apologize for the inconvenience!
Michael, the problem should now be resolved. Let me know if you experience any other issues!
hey dave! this is dave from Rolla. im liking the article, good stuff!
site is looking great too.
Getting a startup right the second time…
ImThere is a startup that started and stopped, and David Gorman documents their eventual success….
David
Your explanation of the whole process is interesting.
My problem is I do not see what ImThere can be useful for.
No offense meant.
Serge
‘The French Guy from New Jersey’
Oooh. The site is so… pretty. I love the registration process, the delicious contrasts, very nice.
Might I suggest making the “I’m there” button change color once you’ve clicked it? I like to get that feeling that I’ve done something when I click a button - the subtle shift of blue gradients and text isn’t quite enough I think.
I also think the “add content” box is much to small for how important it is. It took me a couple of minutes of clicking around to notice it buried in the sea of black on the right. I’d suggest putting it front and center, maybe where the message to “text nowthere…” is right now.
Good article, nice work.
[…] Vitamin Features » Getting a startup right the second time (tags: startup design webdesign business inspiration development startups web2.0 ** entrepreneur) […]
Fantastic article, I’m emailing it to all of the project managers at my company :)
Nice article with nice thoughts for this very morning. The take-a-step-back method is something to hold on to. I took lots of steps back yesterday, and it feels really well. Everything seems more clear today, and I’m looking foreword to go to work.
Just one small question. Was it the same people creating the new version of ImThere? Just curious if you did any organizational changes.
Great article, and a relief to know we are not the only ones. I’d say we are around the end of “Taking a Step Back” - even though we are doing well and already have started to receive bookings, especially on our maldives network, there are just so many things to do, sometimes it is overwhelming.
Anyway, thanks so much for sharing David, and wish you all the luck in the world. I will sign up and try your service.
Chris
Thank you all for the great comments. Let me take a chance to respond to each:
Serge, you’ve nailed what our current biggest challenge is: conveying the value of ImThere. We’re working on a way to do that through the use of specific scenarios, which we hope will make all of the possible uses for ImThere immediately recognizable. We’re also working on a tour, which will walk users through the different components of the site, including our strong mobile side. Hopefully this combination will do the trick, and you and many others will find a reason to sign up and make use of ImThere.
Marcus, glad you like the look of it! Jeff, our designer, is amazing. You’re right about the ImThere button too — it should feel really gratifying to click it, and the shade shift isn’t quite doing that. I also agree about making the “Add Content” box more visible. In fact, I’ve had a number of emails from people asking how they can add events, so this is clearly something we need to tackle quickly. I think we’ll have a solution in place within a few days.
Jarin, thanks for the compliments! It’s great to hear that you found so much value in it.
Martin, taking a step back is an approach I’ve worked into everything I do as well. Whenever I face a tough situation and don’t see an immediate solution, I take a step back and look for some creative solutions. It’s easy to get into the go-go-go mindset, especially in the startup world, but as we found the first time, that can be detrimental. To answer your question, the new ImThere was built by the same team. I was fortunate enough to know the guys on the team for years before we started ImThere, and I brought them on because I knew how talented they were. The failures of the first site weren’t due to a lack of talent, just lack of a clear game plan. Once we had that game plan, their skills were able to shine, and I continue to be very proud of everyone on the team. Since launch, we have brought on a new developer, and he’s been just as awesome. We’re very lucky to have such great people that truly care about making ImThere a success.
Chris, as I mentioned above, the taking a step back approach is especially fitting when starting a company. It may seem frustrating to stop moving forward for a short while, but in retrospect, I’ve always found it worth every second. Good look with your company as well, and I look forward to having you as part of the ImThere community!
It looks like the rss feed has the wrong URL and the images are all broken :(
(I mean the Vitamin feed, btw)
Thanks Chad. Google Reader seems to not have updated the feed URL after the title change. Sorry you had to come all the way to the site and read it the old fashioned way ;) I’ve updated the post again, so maybe that will fix it.
thanks! entrepreneurial anecdotes are by far the most illustrative.
on a similar note, kevin merritt from blist has been writing a bunch of good long ones lately. for example, host an inception mixer:
http://www.blist.com/blog/index.php/2007/09/13/startup-advice-host-an-inception-mixer/
Thanks, Dave. A truly informative and candid article…I appreciate your bravery. Our new quote of the week thanks to you, “we had taken a feature list and developed it into a website”.
Best of luck with ImThere.
Interesting article, David. Thanks for sharing! Sorry if I’ve missed it, but have you shared any info on the costs of Imthere?
Excuse me if I’m being a bit dim… but what is that one key idea ?
[…] Vitamin Features " Getting a startup right the second time […]
Matthew: That is a really great piece. Thanks for passing along the link!
Novian: Glad that you found it quote-worthy — that’s very cool :)
Neil: I haven’t stated any cost information. It’s one of those things where I accept the money was spent, but I’d rather not remind myself :) We are fortunate to have a team that feels very strongly about ImThere and remain involved so long as they can keep their own bills paid. That has allowed us to keep the company afloat despite it being largely self-funded. We are looking to raise a small investment so that we can expand our team though.
Gavin: I do apologize for the annoying secrecy, but we’re keeping that under wraps until we launch it. That will happen within a month. It will have a huge impact on the site though, so keep an eye out if you’re interested!
[…] Vitamin IMThere.com blog entry http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
*phew* I’m not going mad after all :) Yes, secrecy is important and not annoying at all. I am definitely keeping an eye out.
[…] I ran across this good article over on vitamin and it is definitely a good read. The article covers the efforts from start to finish for a site called ImThere and the issues the team ran into in and how at one point they had to scrap it and basically start over. If you haven’t checked it out vitamin has a ton of cool articles like this one. -James Published Friday, October 05, 2007 10:35 AM by .Avery Blog […]
[…] Vitamin Features » Getting a startup right the second time (tags: startup business inspiration design) […]
selamlar
seksi
farz
sevgili
[…] Getting a startup right the second timeThe road to success is hard. We all know this, but still hope for the quick success of a Twitter instead of the starting and stopping of a flickr (started as a game). ImThere is a startup that started and stopped, and David Gorman documents their eventual success. […]
[…] Getting a startup right the second time Falsche Entscheidungen zu treffen ist einfach. Dieser Beitrag beschreibt die Geschichte eines Startups, das zuerst einen falschen Designansatz verfolgte, dann aber zum Überdenken gezwungen wurde und nun in einer "zweiten Fassung" erschienen ist. […]
[…] Getting a startup right the second timeThe road to success is hard. We all know this, but still hope for the quick success of a Twitter instead of the starting and stopping of a flickr (started as a game). ImThere is a startup that started and stopped, and David Gorman documents their eventual success. […]
Vitamin Features » Getting a startup right the second time…
[…][…]…
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
Thanks so very much for taking your time to create this very useful and informative site. I have learned a lot from your site. Thanks!!
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] Getting a startup right the second time Le témoignage d’un entrepreneur qui raconte l’histoire de sa startup web et comment il a dû s’y prendre pour corriger les erreurs de la première version. […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] Getting a startup right the second time is a rather extensive look at the redesign process for one particular web application. […]
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
Look this site
http://www.ooyes.net
really an interesting article… thanks for the insight! nice to be able to learn from the mistakes of others, and to see the process for such a big project from behind the curtains :)
[…] http://www.thinkvitamin.com/features/design/getting-a-startup-right-the-second-time […]
[…] Un article qui date un peu mais qui est vraiment intéressant. Il paraît qu’on a une deuxième chance de faire une première impression finalement… […]
[…] Getting a startup right the second time The road to success is hard. We all know this, but still hope for the quick success of a Twitter instead of the starting and stopping of a flickr (started as a game). ImThere is a startup that started and stopped, and David Gorman documents their eventual success. […]
Very nice article, thanks!
You said one of your errors was: ImThere was built and designed around a feature list
I think this isn’t bad as long as the feature list is well designed.
Hi!..
Great looking site! and thanx for sharing..
I’ve got a couple questions, which I hope you can answer…
.. How do you make a profit from this
.. where’d the initial funding come from,
.. do u run your own servers from day 1 or hosting company?
.. Hope you don’t mind the questions!
Merry Christmas :!
Thanks again for all of the new, great comments!
Chris: Thanks for the compliments, here are the answers to your questions:
1) Right now, we’re just trying to build a strong user base. We do have very defined revenue models prepared, but we’re not at a point to unveil those just yet.
2) Friends, family, and our own money. We haven’t taken a larger angel or VC investment yet.
3) We started off with our own dedicated boxes, but quickly realized there were better options. We’re currently with Slicehost and we adore them.
Merry Christmas to you too!
[…] Of course you may think that you do not need this exercise because you are so sure that your app will be successful. You may be right but know this - so many others thought the same before you and yet experienced failure. You should check out this post from the guys over at the Vitamin blog about a web app that had to be redesigned after the initial design caused the site to fail. It just goes to show how seemingly little things can matter a great deal. I know it is can be really hard to project into the future like I am suggesting but it is certainly worth trying. It is perhaps easier if you have experienced failure before. I was lucky enough to experience a relatively inexpensive failure that taught me to always carry out this exercise. Having little programming knowledge or money I created a small ad-supported site that users could use to notify their utility service providers when they moved house. On the face of it, this looked like a really good idea that solved a problem for users. Of course I built it and they didn’t come - at least not in the numbers I had hoped for. Why didn’t they come? Because I didn’t have a good user acquisition strategy. I was relying on Google Adwords, which of course was too expensive to sustain a site that wasn’t making much money. […]