Managing your time can be a tricky task when you don’t pay attention to the clock and find yourself working well past quitting time. Luckily, there’s RescueTime, which monitors how much time you spend browsing certain websites and using certain programs, and once you see how inefficiently you might have used your time, you can use that data to reclaim your day. We chatted with Robby Macdonell, the creator of RescueTime, to learn how it came to be.
Where did the idea for the app come from? Were you trying to solve a problem you’d experienced, or did the inspiration come from somewhere else?
Do you ever have those days where you know you’ve been working hard all day, but then can’t remember what you did by the time 5pm rolls around? We found ourselves in that position way too often and it was really frustrating. It felt like hours of our day were falling into a black hole. I could usually remember some things I did, but trying to account for a full eight hours always ended up with a bunch of blank spots in it. I ended up feeling really guilty about it, figuring that the missing time must have been spent screwing around on Twitter or reading blogs or something.
I’m a bit of a workaholic anyway, so this guilt lead to lots of working late on nights and weekends until I felt like I had put in a “good day’s work.” It was an unfortunately easy pattern to fall into. It was a pretty common situation around the office I was working in, so the other co-founders and I hacked together a script that would keep a log of the applications we were using. We then rolled that time up so we could see an accurate breakdown of how we were actually spending our time.
Right away we started learning some amazing things. For example, I found that I spent more time on email than anything else, and that went a long way towards explaining the gaps in my time that I couldn’t remember. It wan’t that I was screwing around, it was a company communications problem (a common one, at that).
We found that by having an accurate record of our time, we were able to be more realistic about how we were spending it. I felt less guilty, and stopped pressuring myself into working 60 hour weeks all the time. Having that data gave us a platform for experimenting with other productivity hacks and measuring the changes. We started telling people about the little nerdy analytics toy that we had built, and to our surprise a lot of people said it sounded really cool and they’d like to try it themselves. That was the point when we realised it might be an interesting product to build for others.
After you came up with the idea, what was the next step?
A lot of iteration and testing out new ideas. There weren’t many products like RescueTime when we were first working on it, so we had to learn a lot by trial and error. We tried a lot of things to figure out what useful information we could uncover, what types of things to track, and how to display it. It was a layered experience. Once we understood what applications we were using all day, we realised that most of our work was happening in a browser, so we started tracking websites just like applications.
Once we had a good picture of our time on the computer, the negative space that gets filled in by meetings, phone calls, etc became really obvious, so we added the ability to keep a log of time away from the computer. Then smartphones became part of the picture, and we had to support those as well, since people are spending more and more of their days glued to their phone. We spent a lot of cycles expanding and focusing until we felt like we were getting close to a balance that was interesting without being too overwhelming.
How did you choose which platforms to target and which to ignore or wait on?
Well, we all had a much stronger skill set for building web apps than desktop applications, so we did the smallest amount of work possible on the part of the application that actually ran on our computers (the first version of the Mac app was just an AppleScript!), and then pushed everything else to a server to handle the processing and display. At the time, it felt a little lazy because we were simply getting the data into an environment that we were more comfortable in. But as soon as we started supporting other platforms, it became really obvious that it was the smart way to go. Now when we roll out a new platform, we save a lot of extra cycles by not having to rewrite everything from scratch.
What was your biggest roadblock and how did you overcome it?
I think the conversation around privacy has been really interesting. When you’re building a self tracking tool for yourself, privacy isn’t that much of an issue. You’re in more or less complete control of your data. Once other people started using RescueTime, however, things took on a different dynamic. ResuceTime gives people a record of every second they spend sitting in front of a computer, so naturally people were concerned about the data.
We’ve gotten some awesome feedback from our users and worked really hard to create a platform that people feel comfortable and secure using. That involved putting in a lot of privacy controls, making some things opt-in rather than default, and generally making an effort to only track things that are going to be really valuable to the user. It’s still an issue that gets brought up, but with the amount of privacy and control we give our users, people generally feel pretty good about it.
What was launch like for you?
It was good, and we’ve seen steady growth over the years. We recently rolled out a top-to-bottom rethinking of the app, and that was personally a lot more exciting. With the initial launch, at worst you’ll get indifference. It’s unlikely you’re going to actively upset anyone. Dropping a total redesign in the laps of an existing user base, on the other hand, can be downright terrifying! Some of the changes we were making were pretty foundational, so we sort of had to take a less incremental approach than we would have liked. I’m glad we did it the way we did, but it was insanely nerve-wracking.
RescueTime has tens of thousands of users visiting the site each week, and we spent a LOT of time thinking through as much as possible so we wouldn’t screw up their experience. We did a lot of work with our users leading up to the launch to validate the changes we were making, and ironed out as many rough spots as possible before flipping the switch. The preparation paid off, though, and so far the new version has been really well received.
Above: The RescueTime team at work.
How do you handle user requests and criticisms effectively?
We try to be really responsive with support requests. Roger, our head of support, is an absolute superhero in that regard. We all take part in support, though. That’s partly because we’re a small team and everyone needs to play different roles from time to time. But it’s also an amazing way to understand our customers’ most pressing needs. Interacting directly with people using RescueTime keeps us honest and helps us avoid making bad assumptions.
As far as criticisms go, we try to deal with them as constructively as possible. Many things are totally legit, and are a good nudge for us to improve something that’s either missing or implemented poorly. At the same time, we want to keep the application simple, so we can’t implement every feature that gets requested. But part of the fun of building an application like this is figuring out ways to synthesize all of that feedback and make improvements that help cover the majority of requests.
Now, how do you split time between developing new features and managing existing ones?
We try to roll out new features in several rounds of small changes, usually building from an existing foundation feature. This makes the line between improvements and brand new features a little fuzzy. It’s nice though, because it allows us to quickly figure out what’s working and what’s not, and it doesn’t tie us up in long release cycles so we can switch gears if we need to. The exception to this approach would be our recent redesign, which was more of an intense effort to build out a lot of new functionality.
What advice would you give to others that want to take on a similar project?
It’s pretty important is to be able to empathise with your users, so I’d say try to cultivate that skill. Trying to design for a market or a trend instead of for the user is a really easy trap to fall into. It helps if you’re scratching your own itch. Unless you’re an absolute weirdo there are probably others like you out there. The flip side of that is to not get too caught up in your own vision that you don’t validate your assumptions. If you’ve got an idea that resonates with people, it’s usually pretty easy to get them to tell you whether or not you’re staying on track. Support channels will tell you a lot, but also look for additional opportunities to be where your users are, and talk to everyone you can about it. We’re pretty active in local Quantified Self meetups for example. That’s a great group of people to be around when you’re exploring the analytical side of productivity.
Finally, you’re probably going to be figuring out a lot of things as you go along, so having a blog is a great way to have an ongoing conversation with people thinking about what you’re doing. We’ve introduced several features as a “what if we did _____?” blog post, and it’s a great way to get some early validation before putting in design and engineering effort.
Lifehacker’s Behind the App series gives an inside look at how some of our favourite apps came to be — from idea to launch (and beyond).