Today, I’m thrilled to unveil my first iPhone app: Negotiate It.
I’ve taken all of the most effective field-tested negotiation scripts from my book and this blog, and bundled them up for you to use on your iPhone.
The Negotiate It app shows you exactly what to say — word-for-word — to save hundreds on your car insurance, cable and cell phone bills, overdraft fees, and more. The tough part of negotiating (knowing what to say) has been taken care of for you. All you have to do is read the words on the screen right into your iPhone.
I added some cool features into this app (e.g. lists of company telephone numbers to dial, ability to record savings and take notes on each call, automatic reminders for when to call back and renegotiate, etc.), and we’re giving away bonus gifts to anyone who downloads it. Be sure to read the bottom of this post for more details.
This app has been in the works for a long time — nearly two years. In 2010, Charlie Hoehn reached out to me and proposed that we make it. Charlie and I had worked on a bunch of other projects together. He helped create the marketing strategy for my book, and he’d filmed a few comedy sketch videos for this blog (specifically The Suze Saga and EXTREME Frugality). He also released his Recession-Proof Graduate e-book on this blog, which has since been read more than 100,000 times.
At the time, I was in the middle of creating my Earn1K course, and Charlie was working on The 4-Hour Body with Tim Ferriss. So we put Negotiate It on the backburner and vowed to finish it once our schedules cleared up. And now, it’s ready for you to use.
I asked Charlie to share all the details on the making of this app, as he spearheaded most of its development. This guest post will give you a behind-the-scenes look into what the process is like for a first-time app developer. I hope you enjoy it.
* * *
A couple years ago, I noticed people were constantly writing to Ramit on Twitter, saying they’d saved money using the negotiation scripts from his book. He kept getting messages like these:
I’d saved hundreds using Ramit’s scripts, too. They really worked. But it made me think: “All of these people have to hold the phone against their ear while reading out loud from his book? That’s a little awkward. It would be more convenient to read the script right off the screen of their phone.”
I called up Ramit: “Hey man, why don’t we put all of your negotiation scripts into an app? People could just read from their phone while they’re talking to the reps on speaker.”
“Hmm, that’s an interesting idea. Let me give it some thought.”
A few days later, Ramit called me back.
“Charlie, I’ve got an idea. We should put all of the negotiation scripts into an iPhone app. People could read off the screen while they’re talking to the reps on speaker!”
I paused. “Ramit… am I losing my mind?”
“Didn’t we talk about this last week?”
“Oh… yea, that’s right. My bad. Well, we should go ahead and do it.”
And that’s how the idea was born. We decided to build an app that would eliminate the user’s need to think about anything while negotiating – all they’d have to do is tap a few buttons, recite the information on their screen, and they would magically save money.
But this seemingly simple concept was a lot more complex than I’d imagined…
Designing the experience
The first step was figuring out what scripts we wanted to offer. Ramit had a bunch of them, but we only wanted to include the ones that would typically be used over the phone. We ended up with the following list of bills and fees that could be negotiated:
Potential savings: $30+
Potential savings: $240+/year
Cell phone bill
Potential savings: $240+/year
Potential savings: $300+/year
Potential savings: $30+
Missed credit card payments
Potential savings: $30+
Opening a no fee account
Potential savings: $10
The next step was to determine how the app should function. When the user opens it, they would obviously have a list of negotiation scripts to choose from. But once they selected a script, what was next? Should it give them a list of companies to call, or drop them straight into the script? We decided the best solution was to show them a few instructions first, and give them two options: call now or practice first. Allowing them to see the script without making the call would give first-time users a chance to familiarize themselves with the app.
When the user was ready to negotiate, the app would display a list of all the major companies they might need to call. They could simply tap the company’s number, instead of having to look it up.
After the user initiated the call and was speaking with a rep, they could return to the app, which would drop them right into the appropriate script.
The next step was deciding how the scripts would be displayed. Should we simply cut-and-paste them from the book, and have the user scroll down as they’re reading along? That might be too confusing. Some of the scripts were pretty long, and had conditional lines when the rep rejected the initial negotiation attempt. In these cases, Ramit had “escalation scripts” – backup lines the user would read to counter rejections.
We wanted the scripts to stop as soon as the user successfully saved money. So we decided to break each script into smaller portions, and have the user control the sequence (like a Choose-Your-Own Adventure book). If the rep shut them down, the user would tap a button and continue negotiating. If the rep approved, the user would tap a different button and the script would end.
An early breakdown of the “Missed credit card payment” script.
After that, we needed to determine what would occur at the end of each script. It made sense to ask the user to record their savings if they succeeded. That would show them the progress they had made and would instantly validate the app’s value.
We also added a notes option, in case the user wanted to remember details from the call (e.g. “I talked with AT&T service rep for 10 minutes, then was transferred to Bill in customer retention, and he lowered my rate.”) This boosted the “lasting value” of the app and lowered the likelihood of someone deleting it, as users could reference those notes in future calls.
But what should happen if the user did NOT save money? When the negotiation failed, the user would feel frustrated, and may be questioning their decision to negotiate in the first place. If that was the case, what should the app display on the screen?
Initially, our solution was to simply set a reminder to call back and try again. But we realized that wasn’t enough. The user would still feel that they hadn’t made any real progress in that moment, and a reminder to call back would seem like a dead end. We decided to add a “consolation screen” for each script (in addition to the reminder), where the user could read helpful financial suggestions from Ramit. If the script failed, the user would still walk away with a tip to save money.
We also set default times for each reminder (e.g. 1 week later, 1 month later, etc.) so the user wouldn’t have to decide when to call back. Again, we wanted the app to eliminate as much “thinking” as possible.
Designing the icon
One of the most important elements of an app is the icon. Much like a book cover, the icon is the first visual people see, which determines their willingness to investigate the app’s description and screenshots, and ultimately leads to a download. Having a sexy icon that truly POPS can attract customers in droves.
We hired Tamiko Rast (who had designed a bunch of Ramit’s other products) to help us come up with a great icon. Ramit and I had no idea what we wanted, but we knew our icon had to stand out among all of the cliché symbols that other finance apps were using (dollars, coins, hand-shakes, wallets, etc.)
Iconography from some of the top financial apps.
Even though we weren’t committed to a name at this stage, we asked Tamiko to come up with a few ideas. She looked through 100+ pages of financial apps, then put together the first round of designs:
They were a great start, but we were looking for something edgier. This is where great designers understand clients who can’t articulate exactly what they want…but they keep working iteratively to find the right design.
Ramit suggested “a guy shaking his fist or beating something,” and I gently reminded him that most people don’t associate personal finance with “total domination.”
We still didn’t know what we were looking for, but we asked for another round of designs anyways:
No dice. Then Ramit suggested the concept of money shooting out of the phone’s earpiece. Tamiko sent us a third round of icon ideas:
Now we were getting closer. Ramit and I both liked the bottom icon, if it could just be cleaned up a bit. I slapped it on an iPhone screen in Photoshop to see how it might look:
Not bad. Tamiko sent over a better version of the app icon:
We had a winner.
What should we call it?
The app’s name needed to be memorable, descriptive, and consistent with IWTYTBR’s brand. Ramit wanted to call the app Negotiate Like an Indian (for obvious reasons), but that was too long. Plus, we were pretty sure Apple would reject a quasi-racist name. So we started with three choices: “Money Scripts,” “iNegotiate,” and “Call ‘n’ Save.”
Call ‘n’ Save was out. It screamed cheap and salesy. Money Scripts was a little better, but still didn’t feel quite right.
I was leaning toward iNegotiate. It was fairly descriptive, memorable, and when you searched for “negotiate” in the store, it only brought up six results. But that was also the problem with using “negotiate” in the name: no one was searching for it. There appeared to be little demand for that keyword.
When we polled Ramit’s Twitter followers on the names, the votes were split down the middle:
We also asked for alternative names from his followers, but none of the suggestions sounded very appealing:
Lets save money together
Ultimately, we decided to go with “Negotiate It.” Neither of us liked having an app that arbitrarily piggybacked off of Apple’s “i” naming device (we also discovered that Apple doesn’t like when developers do this). Nor did we like having “money” in the name. It sounded tacky.
Negotiate It’s name was a branding decision. Although the word “negotiate” didn’t have as much traffic, the name was consistent with IWTYTBR, conveyed the app’s purpose, and was easy to remember.
Working with Programmers
I hired my friend Adam Bossy (a former coder for IBM), who agreed to program the app at a lower rate since he’d never worked in iOS before. Sure, I could have hired a cheap overseas coder from oDesk or Elance, but I went with Adam because I’d known him for 10+ years and he lived close to me (being able to occasionally review our progress in-person was invaluable). Adam was the first long-term hire I’d made, and overall, the project went really well. We had a few bumps along the way, but looking back, the vast majority of our missteps were caused by my overly-confident yet mostly clueless direction.
For instance, I made a HUGE mistake in the beginning, which was to verbally describe the specifics of the app, rather than taking the time to visually map out how all the features would work. Because I had no idea what the hell I was building, I would say things like this in emails to Adam: “If the best place to put their personal savings number is on the main menu, so be it. You’re a smart guy — you’ll think of something.”
It seriously pains me to include that in this post, and I cringe every time I read it. Developers should never pass along the responsibility of their vision to the coder; bringing form to your ideas is YOUR job, not theirs. There are many cheap “app mockup” tools available (e.g. Balsamiq, Keynotopia, Photoshop), so there’s no excuse for developers to not build a prototype before hiring a programmer.
I’ll repeat it once more, for aspiring developers: The costliest mistake I made was failing to create a visual prototype before we started coding. Designing an app is like designing a house — you’re the architect, and you need to plan every component of what you want to build before handing your blueprints to a construction team. If you don’t know exactly what’s being assembled and how it will function, you are risking major delays. The number of times I added or changed the app’s functionality cost me time and money that could have been far better spent. Do the hard work upfront and you’ll avoid major headaches later on.
When the app was nearly finished, Adam ended up landing a full-time job. We had a tough time coordinating after that, so I ended up hiring Danil, a Russian coder on oDesk, to make my final changes. Working with Danil was more of a challenge. His English wasn’t perfect, which really forced me to focus on crafting crystal-clear messages. I learned that the best way to express changes I wanted to make was by creating visuals. I took screenshots of Negotiate It, marked them up using Skitch, packaged everything up in a PDF and sent it to him. This was somewhat cumbersome, but very worthwhile — it cut down on a lot of back-and-forth emails.
Here are a couple examples of notes I sent to Danil:
I am still shocked the app came out almost exactly as I’d described in my emails to Adam and Danil. If I were to do this entire project all over, I would have drawn out every single page of the app in Photoshop, handed the files to a designer to spruce up, and THEN sent the final designs to the coder to make them functional. Additionally, I would have hired an experienced iOS developer. Although Adam was able to work at a lower rate, development took him a bit longer because he was learning a lot on-the-fly. Experienced coders might be more expensive, but they are cheaper over the long run.
There are three great books every aspiring app maker should read before they get started. These will save you from making a lot of the mistakes I made:
Testing the app
Before we gathered our group of beta testers, we created a long survey to ensure that each person would thoroughly evaluate every single aspect of the app and provide detailed feedback. Our main goal was to ensure Negotiate It was bug-free, but we also wanted to confirm that it was useful and intuitive.
Ramit sent out an email to his list, asking people to sign up as testers. Within two hours, more than 100 people had filled out our application form. We whittled the 200+ total applicants down to 15 final testers. The finalists were chosen based on whoever was first to respond, agreeing to the following conditions:
1. They would be willing to commit two hours of their time to write an in-depth review of the app.
2. They would complete their review within 48 hours of downloading the app to their phone.
Once we had our testers picked, we sent them the app, along with our survey.[Note: The process of sending your app to testers was somewhat complicated back in the day, but now it’s much simpler. All you have to do is sign up for TestFlight, upload a build of your app, then invite testers.]
Here are the questions we asked each tester in our survey:
- Do you understand the purpose of this app?
- What do you like about the app so far?
- What do you NOT like about the app?
- How useful is [this script] to you? (scale of 1-5)
- Did you try [this script]?
- If you used [this script], how much did you save?
- Did you get stuck or were you confused at any point during [this script]? If so, when and why?
- Did you ever use the “Share my savings” feature?
- Is there anything you would change in this app’s features?
- How much money did you save in total?
- How many minutes did it take you to achieve these results?
- How much is this app worth to you?
- Would you recommend this app to others? If yes, why? If no, why not?
- Anything else you’d like to tell us?
Even though I knew the app worked, I couldn’t help but be nervous. It’s always a bit scary to unleash your work to an audience. The app was functional, but I knew it wasn’t brilliant. I was expecting some harsh criticism. Thankfully, nearly all of our testers were enthusiastic about helping us, and did an amazing job picking the app apart and finding its weaknesses. What’s more, several of them actually saved a bunch of money!
Here were their results:
Average savings per user: $147.52
Highest savings: $800/year
10 users saved $50 or more
4 users saved $0 (two users didn’t try the scripts)
After all the feedback was tallied, we called each of the testers to talk about their experience using the app. Calling testers after they’d already filled out a long survey might seem redundant, but those calls were hugely important. Many of them wanted to elaborate on certain elements of the app, but didn’t have enough time to type out all of their feedback. Giving each tester a personal call allowed many of them to open up even more, and resulted in us making a few critical improvements that would have otherwise been overlooked.
For instance, we discovered that the app was still fairly confusing to use — the instructions weren’t enough! So we put together a 3-minute demo video on how to use the app, which the user would be prompted to watch the first time they opened the app. The testers also gave us the idea for a call log feature, which kept a record of negotiations you’d completed, how much you’d saved, notes from the calls, and any reminders you’d set.
Redesigning the app
The evolution of our splash screen.
At first, I was intensely focused on releasing a bare bones app. Functionality and bug-free was everything; design was secondary. I thought the scripts would speak for themselves, and users would see that…
Not so much.
After the first round of feedback from our testers, the number one complaint was the app’s look. Everyone kept saying Negotiate It was really ugly – it lacked any sort of polish, distinctive coloring, iconography, or flare. It was so generic that it resembled the iPhone’s Settings folder.
I relented after hearing how much our testers hated the design. Once again, we solicited Tamiko to give Negotiate It a quick facelift. Improving the look of our app was worth every penny.
Negotiate It’s menu, before and after Tamiko stepped in.
Tamiko also put together a better version of our tutorial slides, which – until then — had been haphazardly slapped together. Once again, hiring a professional designer proved to be a wise investment…
Before and after shots of the tutorial’s first screen.
Designing a beautiful app is not a bonus; it’s required. Apple expects developers to strive for their level of quality and complement their products, so you need to plan on hiring a pro to make your app visually stunning. Here are a few sites where you can find quality designers: Freelancer, Scoutzie, They Make Apps, and 99 Designs.
Pricing is tricky for apps. For one, it’s costly to develop any type of software. You typically have to invest a substantial amount in order to build a great product, one that will hopefully reach a wide enough customer base to recoup costs and earn a profit. With a distribution channel that can reach millions of customers around the world, app makers can afford to give expensive software away for $0.99 or even free… but that’s not always a wise decision.
Low prices can result in more downloads…and poor reviews.
When deciding on a price point, the outcome should NOT simply be “maximize downloads.” Pricing communicates a perceived value for the app, it attracts a certain type of customer, and — whether the buyer is conscious of it or not — a higher price point can often lead to greater satisfaction with their purchase (resulting in better reviews).
We decided early on that we would set a higher-than-average price for Negotiate It. But we still weren’t sure what to charge. If a user saved $150 using the app, would a $19.99 price point seem reasonable? What about $14.99, or even $9.99?
Although we’d removed most of the thinking required in negotiations, the app wasn’t a magic button that instantly saved money. The user would still have to put in the effort to make the call and talk to a rep.
Still, we believed that Negotiate It was unique, and that it could save users hundreds of dollars that would have otherwise been left on the table. We wanted to keep the price reasonably low for a wider audience to enjoy, but relatively high to assert the app’s value. We decided $4.99 was the best price point: easily affordable, yet high enough to attract smart customers willing to invest in their finances. It was also steep enough to dissuade impulsive freeloaders.
We submitted the app on July 17th. On July 30th, I received notice that it had been rejected because of a sentence I put in the description: “Ramit Sethi has taught thousands of people how to save money and negotiate like an Indian.” Whoops. I promptly removed “like an Indian” and resubmitted. The app was approved two days later, and finally available for sale in the App Store.
Do you know your actual earning potential?
Get started with the Earning Potential quiz. Get a custom report based on your unique strengths, and discover how to start making extra money — in as little as an hour.
Takes 3 min