This comes to us from Italy: “Is it possible to keep a penis on a saved maps?”
Gaia GPS
A proper business should guarantee their products. My idea of a good return policy is that you can return a product for any reason at all, and that you shouldn’t have to state the reason if you don’t care to do so. That’s how we operate, and you can boil it down into three tenets:
- We will never turn down a request for a refund
- We go out of our way to make it easy and painless to get refunded
- We make sure any customer in distress knows that a refund is there for the asking
I always loved the story I heard in business school about Nordstrom, a high-end department store that many of you have probably at least walked by in a mall. The story story goes like this… a man walked into Nordstrom to return a tire without a receipt. While Nordstrom does not carry tires, and while the receipt for the tire did not say Nordstrom, the customer service desk processed the refund without argument.
Now that’s my idea of good customer service – it’s a policy that guarantees that shoppers walk away happy, no matter what, and you get a big karmic kickback too. Sure, customer service could have told the man that they don’t sell tires, or maybe they could have tried to help him figure out where to return it, but instead they focused on satisfying the customer, above all else. I want more businesses like that.
Whenever it comes up in our business, we instruct people that they can request a refund through the App Store, but we also know that is a pain in the neck. So, in addition we offer to immediately process a refund via PayPal, and our only hope is that the user will keep the app and find it useful someday. It doesn’t matter to us whether you found a bug in one of our apps, you are just having a bad day, or your fortune teller told you iPhone apps are cursed. There is no invalid reason for a refund.
Maybe someday when my business is really big, I’ll find that people try and game us out of money, and we’ll need more onerous policies. But as long as we’re not going broke, that’s how we’re going to do it. I am always shocked by the goodness of our users in the face of this policy. Maybe that’s what Paul Graham means when he writes, “Go out of your way to make people happy. They’ll be overwhelmed; you’ll see.”
The response to a refund offer is usually not “yes, right away.” Only about 1 in 10 people will take a refund when offered, probably less. The much more likely response is reciprocal support and encouragement – from people who didn’t have a good experience with our software, but nonetheless want us to succeed. Or it also often ends up that we offer the refund, but we solve their problem in parallel, and they are doubly happy to know that we both care and will go to the mat to make sure they are satisfied.
And let’s be real here – I’m not selling cars or cigarettes, I’m selling software. It costs me exactly zero dollars to make each additional copy of my app, so if I can’t make money while still offering a money back guarantee, my software surely must suck. There’s no reason why a dissatisfied user shouldn’t get a refund when the marginal production cost is zero.
If you are a customer of ours, you can take that to the bank. And if you are an entrepreneur, I hope you do what we do – it’s the right thing to do, it’s the smart thing to do, and the world will be a better place when all products, or software at least, works that way.
I started using FourSquare recently – I’m now the Mayor of San Pablo Park, and I check in there everyday. My wife and I just moved to a new neighborhood, and it’s strangely fun to log our daily walks. It’s also been neat to run into other FourSquare users, after recognizing pictures of their dogs.
After using FourSquare for a couple weeks, I was poking around their website, and I decided to connect with all of my various social utilities and import my contacts. I did them all – GMail, Twitter, and of course Facebook. Of all the services, I felt betrayed only by Facebook – that was the only one that took the excuse of me inviting my contacts to also sign me up for Wall Posts. I will almost never connect with a Facebook app for this reason – nearly all app makers will ask you for a slew of permissions, among them making public posts on your behalf.
So after the first wall post I nipped it in the bud, using the convenient way Facebook provides to remove the permission, available from the Wall Post itself. I think the Facebook employees would tell you that the system is working, and they would point out how easy it was for me to get what I wanted in the end. Each application explicitly asks you to post stuff, and you have to explicitly say yes. And then it’s easy to fix things on the back end.
I would argue that both this system and the attitude that fosters it are broken. In almost all cases, I simply say no, and decline to trade my privacy for the small bit of utility of an app. But is everyone like me? How many of these users facing these coercive choices are unable to understand the devil’s bargain they are making? How many are drunk, sad, or lonely? Heck, how many of these people are even old enough to be entering into binding agreements like this? Children who connect with their FourSquare friends on Facebook, and then end up posting automatically to their walls are being exploited in the same way as child actors – the only difference is that child actors are protected by contracts and labor law, and they get paid.
In the end, the Facebook API is a system of coercion. It preys on our weakness for being social, for being cool, and being part of the group. It preys on laziness. And it preys on our children. It’s not exactly a gun to the head, but then again the system isn’t trying to coerce you into handing over the money in the safe, so they don’t really need a gun. This light, social coercion is enough.
Facebook holds up the straw man of simplicity of UI. They claim that the interface makes it easy for you to share and control that sharing, but the simple truth is the interface makes it simple for programmers to coerce you into doing what they want.
The main problem is that applications use the carrot of things like “connect with your friends” to get you to also allow them to post on your wall. This simply should not be allowed – if FourSquare wants to connect me with my Facebook friends, they should not be allowed to ask for other permissions, most importantly they should not be allowed to ask for the Posting Publicly Permission. I can hardly blame FourSquare for this – they basically need to do it to keep up with other apps, but I can blame Facebook for making the rules of the game. This all starts higher up, in the form of a thought in Mark Zuckerberg’s head, that privacy is dead. But it does not manifest until it becomes this API.
The solution is apparent – the API should let you ask for just one permission at a time, for the thing that your app wants to do. At the very least, it should not allow developers to use the ultimate social tool – the contacts import – to erode your privacy. Until this changes, Facebook will never be a trustworthy system, and user ire will build and foment. The end result is unclear, but I think Facebook underestimates the growing tide, and there will be some consequences in the form of lawsuits, regulation, or platform change.
UI simplicity is a straw man – Facebook simply knows that favoring viral spamminess and coercion is a sure way to grow the network, and they will continue to develop the platform that way and hide behind a veil of good intentions and engineering issues. Until there is a change of heart at the highest level, or until people and our governments take action, Facebook’s attitude will continue to define social on the web.
Freelancers are like terrorists – you don’t negotiate with them, because it just doesn’t work. The proper way to handle a freelancer is to ask them how much money they would be delighted with, and then you give it to them. And if you can’t give it to them, you don’t hire them.
We work with about 6-8 people depending on the week, who helps us code, design, and write stuff. We pay them anywhere from $25-150/hour, and the common thread in how those rates came about is we just gave them whatever they asked for. And if it was too low, we even gave them more.
You may think that this is going to lead to high costs, and you should be negotiating down the rates. You may think – I should negotiate everything. But this is just wrong, because you may shave a few dollars off the cost in the short term, but you are doomed in the long. Here are the many likely failure cases you will hit:
-
You hire bad people – People who work for whatever you are willing to pay aren’t in demand, and therefore probably suck.
Any good programmer will tell you there are a vast array of cushy, high-paying jobs that they can have. In this terrible economy, it’s not the software developers that suffer (it’s insurance salesmen, parking lot attendants, toll-takers, and other irrelevant jobs that suffer if I were to guess).
It’s easy to suffer a delusion of grandeur here and think that you have such a killer project that you can get rockstars for less than they want or need, but who are you kidding? Unless you have as much caché as Kevin Rose or something (just to name a random famous guy), then your money is the only thing talking.
-
You lose good people – Congratulations, you have just hired the architect of Facebook’s photo sharing site for your Flickr-killer. Somehow, it just happened – maybe you had a connection, or he saw some spark in your company, or maybe he just needed some rent money because of strange circumstance.
Welcome to two months later – your start-up is thriving on the back of a rockstar engineer, and it’s looking like Series A is just around the corner. And hey, what do you know – things are looking up for your programmer too – he got his mojo back, sent a resume to Google now that the he’s forgotten the annoyances of Facebook – and your 60/hour (he wanted 100), with a max of 30 hours per week, is both not stacking up very fast and a little embarrassing.
One day, he comes to you and lets you know he’ll be going to Google soon, and he just didn’t want you to be surprised. At this point, you have your $2.2M in funding, and you offer to match his salary, plus stock (plus even more when he shoots you down). Maybe he would have left anyways, but it would have helped if you hadn’t over-negotiated in the first place… if you were as interested in his needs as you want him to be in yours.
-
You get billed anyways – Even if you negotiate down the project cost or hourly rate, let’s face it – you are liable to get billed whatever the freelancer cares to bill you. Your minor changes, which he would have accommodated with gusto at the rate he asked for, now become major changes in the spec. Outside of scope. Extra hours needed. Savings down the drain. Who is really to say whether certain behaviors are features or bugs? Well, I guess you, as the project lead should say, and he’ll be willing to listen for just a few more bucks.
-
The work sucks – Let’s say you even manage to hire a good person, but maybe you are the lowest paying gig of 2-3 he has. Do you think your deadlines, requirements, bugs, or user needs are going to rate? Think again. You’ll get your code, eventually… maybe.
So that gets me back to how I hire freelancers. We just give them whatever they want, sometimes more. The caveat is you have to pair this strategy with both a knowledge of what you are getting, and a willingness to fire people who are doing a good job, but not a good enough job. Not everyone we have ever tried to work with did not work out – some were not fast enough, some not good enough, some didn’t care enough. And each one of those people cost us a few hundred or a few thousand dollars to find out.
In the end, it’s not about getting a good rate, it’s about getting a good value. And you do not get a good value from underpaid, unhappy programmers working on other people’s dreams.
So, if you’re a founder, find someone who you have enough money to excite. And if you are a freelancer, we’re hiring.
When I noticed a company had named their new Android app “Gaia GPS to Your Email” I was at first a little excited. I thought someone had made an app that hooked our GPS app into email functionality. Wouldn’t that be flattering!
However, after I checked out the app, I realized it had nothing to do with Gaia GPS at all, and that the names just happened to be similar.
So, next I sent an email asking them to change the name, and that was that, because people are generally nice and cool. The company changed the named to Genie GPS to your Email right away, and they even apologized for the mixup.
I just thought I’d take a moment and thank these guys on my blog, because they really could have ignored me and I wouldn’t have done a thing, Instead, they took a little time and found a new name, just because I asked, and because it was the right thing to do.
My takeaway from this is if you are ever thinking about getting aggressive with someone over a trademark, you shouldn’t immediately pay a lawyer to write a letter. I would hope that sending a personal email, devoid of threats and legalize, doesn’t do anything to endanger a trademark down the road, but I guess it wouldn’t surprise me.
Since it seems apropos, let me also close by saying that we’ve signed The Patent Pledge, and we hope you will too. Not that we haver any plans to file any patents, but I’m told that we’ll feel differently after we grow a tad more.
Lately, we have been tweaking our apps to be compatible with iOS5.
One thing we noticed is that the UISegmentedControl, which shows a bar of menu options, no longer works exactly as it did under iOS4. Specifically, when you programatically set the selectedSegmentIndex property, it no longer calls the associated method. Under iOS4, when the user pressed the menu option, or you set the index, the method would run. But under iOS5, it only gets run if the user presses the button. You can see this bug popping up on the internet here.
Rather than put a bunch of logic throughout my code to deal with this, I developed this subclass of UISegmentedControl on the advice of Anna, which works as expected. Download it from GitHub here.
We are still working on getting iBurn 2011 for Android out there. The code from last year was very dependent on how the map was set up, and it ended up being a much bigger job to redo this year to accommodate the new map.
We’re very sorry! Given the gates have been open for a couple of days, we know time is of the essence, and we’ll try and get it out by Wednesday. Total SNAFU.
You can now download iBurn 2011 for Android at this link. If you have trouble installing, download tAttachApkInstaller from the Android Market, and use that option when touching the link to install.
We are going to test this out for a little while now, and then we will also post it to the Market this afternoon for easier downloading. Please email iburn@gaiagps.com with any bug reports.
It’s a little late for the Droid version, but now’s better than never we hope!