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?
I’d literally end up emailing myself links and files just to get them from one to the other.
I know almost everyone still does, too, which is funny in a depressing kind of way.
Pushbullet started as an easier and faster way to move links and files between devices.
The way Pushbullet could actually achieve this hit me when Jelly Bean (Android 4.1) came out.
Near the same time, I’d tried Google’sChrome to Phoneextension and thought it was really cool.
The extension lets you instantly send a webpage into the notification tray on your phone.
The fact that I got an email isn’t meant for just my phoneit’s meant for me.
This seems obvious, but before we built it, this didn’t exist.
After you came up with the idea, what was the next step?
I started working on Pushbullet as a side project while working full time atHipmunk.
How did you choose which platforms to target and which to ignore or wait on?
What was your biggest roadblock and how did you overcome it?
My biggest roadblock was probably just getting all of the pieces working together and into a shippable state.
This was difficult since, as I said, Pushbullet started as a side project.
And when I had, it was on top of an existing system.
What was launch like for you?
Pushbullet’s launch was actually quite successful.
I think we got lucky in that, but I’m certainly not complaining.
Launching consisted of just submittingthe launch blog postto Reddit’sAndroid communityand toHacker News.
Both of the submissions are linked to at the bottom of the post.
While Hacker News was somewhat receptive, Reddit’s Android community reacted extremely enthusiastically, which was awesome.
Based on their feedback,I rushed out a Chrome extensionto Pushbullet the next week.
From there,Pushbullet hit 15,000 usersin just those two weeks.
you could imagine how excited I was, and we’ve basically been at it since.
How do you handle user requests and criticisms effectively?
We get a lot of our feedback in public, so we respond in public as well.
Now, how do you split time between developing new features and managing existing ones?
I believe there are few things more annoying than software that isn’t reliable.
This means we focus on squishing bugs as soon as we hear about them.
Developing new features is what we spend most of our time working on.
New features, however, isn’t quite how I’d describe it.
Instead, Pushbullet is always actually getting better.
Are fast iterations something you prioritize?
Iterating on ideas and getting things out fast is a sort of classic piece of advice given these days.
I believe it is definitely correct as well.
These can be seriously demotivating.
Not getting locked into a giant release also means we can respond to feedback or fix bugs fast.
When things slow down, basically everything gets worse.
What do you picture Pushbullet being like a few years from now?
Everyone is only going to have more devices in their lives over the next few years.
Phones, tablets, and computers continue to become more ubiquitous.
What advice would you give to others that want to take on a similar project?
Pushbullet has grown into a quite large piece of software that, in many ways, seems deceptively simple.
There is always some single element you might distill your app or service down to.
It’s great to grow from there.
Have someone you’d like to see featured?
