If you’re a programmer building software, or a SaaS (Software as a Service), this post should help you answer the question: “What would make someone buy my app?”
This is the story of why I bought software from a guy named Peter.
(Note: if you like this post, you’ll probably like my book.)
Imagine the following scenes in my customer journey:
Scene 1: “f*ck it, we’ll do it live!”
Over the past few years, I’ve been developing a WordPress theme called Brutal. It’s a simple site design based on the brutalist aesthetic.
Initially, I made all my theme changes inside WordPress. It’s not a client project, so I wasn’t too worried about making changes on my live site. I’d just log in to WordPress admin, edit my theme, and click “update.”
Eventually, I started making mistakes. I’d change some code, screw something up, and have no way of reverting to a previous version.
I needed some version control. So I created a git repository and hosted it on GitHub.
My new process looked like this:
- Open the theme files locally in Atom, my text editor.
- Make my changes.
- Push the changes up to GitHub.
- Transfer my files to my web server via FTP.
Scene 2: the frustration
As I worked with this new process, I kept muttering things under my breath:
“Argh! There’s got to be a better way to do this.”
Having to push my changes through git and FTP every time was frustrating. Sometimes I forgot to sync my changes to GitHub. I never knew where my latest version was.
Every time I went through that process, I got frustrated:
“I’VE HAD ENOUGH! There’s got to be a plugin that does this.”
That day I added a card to my Trello board that said: “GitHub workflow for WordPress themes. (Plugin that exists).”
Scene 3: the search for software
I created that to-do on July 1st.
But it wasn’t until July 10th, at 4:31 pm that I said:
“Damn it; it’s time to find a solution for this problem.”
To start, I went to Google and typed in: “deploy WordPress theme changes with git.”
A bunch of results came up; mostly blog posts.
I clicked on “How to deploy WordPress themes with Git” first. It seemed too technical for me. I don’t use git from the command line (I use GitHub’s desktop app), and the workflow they described didn’t match up with mine. I clicked back to the search results.
The next result I found was for a SaaS called Buddy. It promised, “Continuous Delivery, simplified.” But again, it didn’t seem right for me. I was looking for something specifically built for WordPress. Furthermore, the screenshot showed a terminal-based workflow (which didn’t appeal to me). I went back to search.
I kept clicking and searching, but none of the search results promised a solution that was right for me.
Almost immediately, I knew I’d found my match.
Scene 3: “I think I’ve found the solution!”
Here is what appealed to me about WP Pusher:
- It had “WP” in the name, indicating that it was built specifically with WordPress in mind.
- There were no screenshots of the terminal, signalling that this product wouldn’t be too technical for me.
- The headline “From Git to WordPress” caught my attention, but it was the sub-header that grabbed me: “Deploy your plugins and themes directly from GitHub and never again copy files over FTP.”
- The screenshot on the right showed what the plugin setup would look like in WordPress. I could instantly envision myself using it on my site.
- There was a large “Download” button. This told me I’d be able to try the plugin right away, without having to pay first.
This landing page is doing a bunch of things right.
First, the page immediately answers the questions: “Who is this for?” and “What are they struggling with?” It’s apparent that WP Pusher is for WordPress users trying to figure out their git workflow.
Next, he paints a vision of a better life: “Deploy your theme directly from GitHub and never again copy files over FTP.”
Important: you can’t just talk about the pain the visitor is experiencing, you need to show them how you’re going to make their life better!
Finally, Peter gives potential users a quick way to download and try the plugin.
Scene 4: “Let’s try this out”
Now it’s time to install the plugin and see if it works for me. I uploaded the plugin and got started.
A user’s first interaction with software will determine if they’re going to invest the time in using it.
I was asking questions like:
- Does it feel well made?
- Is this going to be easy to configure?
- Does it work?
After installing, WP Pusher shows you this welcome screen:
I skipped over the “License” tab and clicked on the GitHub tab. It asks you to generate a GitHub token, and auth with GitHub. Done.
After that, I chose the GitHub repository I wanted to use and connected it to the theme on my WordPress site.
Everything’s in place. Now it’s time for the moment of truth.
Scene 5: the moment of truth
Does it work?
I make some edits on
index.php, and sync to GitHub.
Then I log into WordPress. Did it work? I can’t tell.
I go into the WP Pusher settings and see an “Update theme” button. I click it.
It works. It pulls my changes from GitHub into WordPress.
It’s here I notice that “Push-to-Deploy” is disabled. After digging into the documentation, I figure out how to enable that.
Ok, let’s try it again:
- Make an edit on my machine.
- Push changes to GitHub.
- Look at the template on my WordPress site.
- HOLY SHIT IT UPDATED AUTOMATICALLY.
It’s important for me to note that at this moment I feel like an absolute badass.
I want to share my discovery with the world! I write this tweet:
I wish I'd done this ages ago.
Just got @petersuhm's WP Pusher plugin.
New deploy process:
Edit → Push to GitHub → Auto update WP theme 🙌
— Justin Jackson (@mijustin) July 11, 2017
Scene 6: Close the deal
I’ve just had my eureka moment. My life has been made better because of this plugin.
I’m ready to give Peter my money… but then I ran into a snag.
Here’s the problem: there’s no compelling reason for me to upgrade. There’s a single line on the settings page that reads:
You haven’t registered any license key for this installation. Buy one here.
I want to support Peter, so I click buy.
I see these options:
Immediately, I have a few objections:
- Do I even need to pay? I’m only using it on one site, with a public repository.
- None of these categories fit me. I’m not a freelancer, agency, or big agency. Is there no personal license?
- Why is this a yearly subscription? Does Peter have ongoing server costs? If I don’t want email support, can I just pay once? What reoccurring value do I get with the subscription?
I almost clicked away, but I decide to click “Buy now.” Next, I see:
I can now see that there is a personal license. At $39 it feels reasonable (although I’m still feeling a bit miffed about the subscription part). I can’t see what I get for that $39, but I’m assuming it means one site and the use of a private repository.
My next objection: there’s no PayPal option!
I know PayPal is evil, and a pain in the ass. But for many of us, PayPal is where we keep our play money. It’s a guilt-free spending account.
Using my credit card feels like a bigger commitment. First, many of us outside of the US don’t have a USD credit card, so we have to pay high conversion rates. Second, the more recurring subscriptions I see on my credit card statement, the more anxiety I have. I don’t get the same stress from PayPal subscriptions.
I am 99.999% more likely to order from an online shop if they allow payment through PayPal.
— Bri Lamkin (@brnnlmkn) April 1, 2017
Summary: getting me to spend my PayPal money is easier than getting my credit card.
How to get people to buy your software (or SaaS)
If you’re like me, you might get notifications every time someone buys your product.
But these payments don’t tell the whole story. You see only one event in a series of events. What are you missing?
- Everything that happened before the sale (what circumstances lead to the sale?)
- Everything that happened after the sale (did the customer use the product? Were they satisfied? Did they tell anyone about it?)
Understanding your customer’s journey is the key to unlocking more sales. Once you see the progress they’re trying to make you can optimize for every step: from initial discovery to purchase to satisfied customer.
Here’s what your marketing strategy should look like:
- Optimize discovery – you want to reach people who’ve had their “f*ck this, I’ve got to solve this” moment. For most software products, this is going to mean targeting the right search keywords on Google. (Meeting people where they’re at)
- Create a landing page that makes visitors say “Yes! This is for me!” – I discounted the first four search results because I didn’t feel like they understood my problem or my context. Have a clear understanding of who your product is for, and the struggle the face.
- Give users a quick win – I was sold on Peter’s plugin as soon as I pushed to GitHub and saw my theme update automatically.
- Give users a reason to pay you – Peter could ask users to pay once they pass a certain usage threshold. For example, users get five deploys free. After that, they need to buy a license. If I’m getting recurring value from a product, I’m highly incentivized to buy it.
- Make it easy for users to pay you – optimize your checkout process continuously. Figure out where users get stuck, and what objections they have. Reduce the friction!
Need help defining your ideal user, getting more traffic and leads to your site, and converting those users to paying customers? Check out Marketing for Developers.
PS: this journey is based heavily on the Jobs to be Done framework.
If you liked this post, please check out:
Notes from Justin Jackson
Startup stories, lessons, and tips.
Sent on Saturday mornings.
(Read it while you drink your coffee)