Chapter 14: Watch Out for Icebergs
“I have always found that plans are useless, but planning is indispensable.”
When I refer to “icebergs,” I’m talking about all the things that may seem benign on the surface but may actually be rather cumbersome. In some cases, you might overlook them because they’re not a core part of your application. And they aren’t always challenging or tricky, but it can be easy to underestimate the effort to complete them. Make sure to set aside time for these tasks so that they don’t ruin your schedule.
While you might not think of email notifications as a key part of your application’s interface, they are. It’s incredibly easy to identify companies that take care in crafting their emails.
I’d suggest starting out with plain text emails (rather than HTML) and focusing on the copywriting and content. Don’t just throw text into an email. Really put some thought into it. You may even want to have a copy editor to look over them — you might be surprised by how much that can help. Exhaustive testing of HTML emails isn’t something you probably want to make time for at this point. Whatever you do, just make sure to treat every email notification as if it were a page in the application. Set aside time to do it right.
You might not have even thought about it, but successful email delivery shouldn’t be an assumption: emails bounce, and this can bring with it a variety of problems. You want to make sure that you’re actively addressing any bounced emails. This may not need to be a launch-day feature, but it’s worth keeping in mind because bounced emails can create bigger problems if you don’t do anything about them.
We use Postmark for our transactional email delivery, and they have a web hook that automatically notifies us if an email bounces. (A web hook is a user-defined HTTP callback in which a service sends an POST request to a URL you specify.) This lets us take automated and proactive steps to ensure that each email address is correct.
Whenever we know that an email has bounced, we automatically notify all of the administrators on the account so that they can quickly correct the problem. If an account holder’s email bounces, in addition to notifying the administrators, we also automatically generate a support request to ourselves to look into contacting the account holder through other methods. Ultimately, this helps cut down on support requests and saves time for everyone.
Beta and Invite System
You’ll probably want to release a beta version of your app to a select group of people. So you’ll either need to manually set up accounts for these people — which is fine at smaller numbers — or set up a more automated system to send out invitations that allow participants to create their accounts on their own. Either way requires time and attention, and you’ll need to plan accordingly. It’s not something that’s incredibly complex, but it can be a distraction to have to write code that will only be used for a short time.
You can probably get by without administrative tools at first, but you’ll fairly quickly find that there are some support requests that need you to update data — these tasks can soon become tedious if you don’t have administrative tools. For instance, we readily extend customers’ trial periods. (This is our number one support request these days.) A customer may have created an account but didn’t get a chance to use it, or they may have decided that they liked Sifter but needed to pull a few more people into the trial period. Extending someone’s trial period is still a somewhat manual process, but I don’t like making people wait, so I built some tools so that I can take care of this from my phone with a couple of clicks.
Another great candidate for administrative tools is your background processing. How many jobs are queued up? Are there any failed jobs? We have an interface that lets us access this information so that we can quickly intervene and fix any problems — or manually re-run failed jobs — if we need to.
I’m not saying that you should build all this right away, but I hope I’ve offered some insight into the types of tools that you’ll need. You’ll want to start small so that you don’t invest too much time in the wrong things, but you’ll eventually need to build some administrative tools. I’d even suggest setting aside a separate dedicated application and server for these tools if you can. Assuming that you’re comfortable hacking this in a terminal, I wouldn’t build them for launch day, but I’d set aside some time for them shortly thereafter.
Pre-launch Landing Page
You need to start collecting email addresses for your launch announcement. There are quite a few services that make this fairly easy, but the key is to make sure that you set it up as soon as you have a domain and start actively promoting the service.
Remember, an empty text box asking for an email address isn’t all that compelling. You’ll need to put some effort into explaining what your application does and why someone would want to sign up. I’ve seen many landing pages gloss over this, but I don’t want you to make that same mistake: your landing page needs to call out the pain points that your application alleviates. Then explain why they should care and why they should trust you — keep it brief, but don’t skip this.
Your Company Blog
Building your blog can be a huge time sink. You want to steer clear of just tossing up a template site on a blogging service (although I suppose that would be better than nothing). Until your site goes live, your blog design and your content are the face of your business. It might even be the only communication that you’ll have with your early customers. This is not something where you want to cut corners; set aside time to make sure that your company’s blog lives up to your standards.
Finding time to write can quickly become tedious when you’re juggling dozens of other tasks, but it’s also one of the best ways to get your message out and to refine that message. My early blogging for Sifter was a great boon for our marketing, but more than anything, it forced me to think through my ideas. It’s sometimes easy to believe that something is a good idea until that very moment when you have to explain it to someone else. Without my early blogging, Sifter wouldn’t be what it is today — or it might not even exist at all.
↳ Continue to Chapter 15: Selecting Vendors