ChangeLog – Jon Chase's blog

I didn’t mean to learn anything about customer support – I was just researching the competition.

More precisely, I was researching some indirect competitors for Every Single Shot and I found myself at SmugMug. Although I was looking to learn about the specific features of SmugMug, what I found myself really impressed with was their customer support. I mean, it was good enough that it actually jumped out at me. How often do you find a site and your first thought is, "Wow, they must have great customer support!"? Almost never.

Customer support tips

SmugMug’s approach to support made an impression on me. Here are the observations that I took away from my ‘mugging. I’ll be looking for ways to integrate these into Every Single Shot in the future.

• Be friendly – This seems like commonsense, but for some inexplicable reason businesses feel a need to sound "professional" when talking with customers. Sure, make your website and literature professional. But when you’re talking one on one with customers, be friendly. People don’t want to talk to companies, they want to talk to people. Use down to earth, conversational English. How about this from the SmugMug welcome email: "Need a real person? We’re family-run and love to hear your gushes, gripes and questions so we know what to work on next." That tone sets me at ease and lets me know that these people are here to help. Little touches like these can make all the difference. SmugMug uses this tone throughout their site to great effect.
• Humanize your support team – I really like this touch. I found pictures of the SmugMug team in a couple of different places: the 5 minute getting started video and, my favorite, the super hero pictures shown when sending in a support request.
• Let customers know you enjoy helping them (and actually mean it) – This has to do with the general attitude taken toward customers and support. If you respect and value your customers, it will show. If not, customers will soon become ex-customers. I felt the SmugMug team was genuinely concerned about my experience on their site, and because of this I subconsciously started thinking "I like these guys".
• Let customers feel like part of a group – Watch the 5 minute getting started video. This is how intro videos should be done. It’s narrated by one of SmugMug’s owners in a very casual tone and it has photos of the entire SmugMug team. It made me feel like I knew these people a little, like I was part of their group.
• Set appropriate expectations – This one’s great too, and it’s easily overlooked. When you open a support request, SmugMug lets you know what time it is in "SmugMug land". This helps set appropriate expectations for when you’ll receive a response. "It’s 4:27am SmugMug time and our heros are snoozing…you’ll hear from them by early morning." They’re asleep – fair enough, I can live with that. They’re people, after all (see above points).
• Automate – Here’s another neat touch when sending in a support request: the user’s browser and OS are automatically detected and added to their email. My support query to them automatically had the following added: "Hey Support Heroes, I’m using Chrome on Mac OS." Auto-generating details like this (instead of asking the users to tell them to you, which is way less efficient) can eliminate an entire cycle of the support process, which results in quicker support and happier users. No more asking users what web browser they’re using only to have them reply "Dell" or "purple".
• Provide help documents – Another seemingly obvious one, but a lot of small companies don’t provide any sort of help documents for their product. I see this a lot in small webapps released by one or two people (usually programmers, because we all know programmers hate writing documentation – I’m guilty of this – SendAlong suffered from it). This is a fundamental first step that a lot of companies drop the ball on. SmugMug has a lot of nice help docs. They even go so far as to explain how to write some simple CSS rules.
• Make help easy to access – If you spend a lot of time making your help system awesome, make sure you do it justice by making it easy to find. Link to it on every page, and for added bonus points, make the links smart – don’t just dump them at the help homepage, show them topics related to the page they came from.
• Include a FAQ in your help – You should have the top 5 to 10 questions asked right there at the top of your help homepage. 80% of your users are going to need one of those questions answered, so why not make it easy on them? Bonus: now that you’ve got a FAQ, go through it and see if you can make any of the answers to the questions obsolete by making your product easier to use.
• Let them know if you’re special – It doesn’t hurt to let your users know that you’re better than average. In my welcome email I found out that "80% of customers who have purchased SmugMug accounts in the last 5 years are with us today. We hope you’ll join the family." I immediately thought "Hmmmmm…they must be really good at what they do." And I’m sure that’s exactly what they wanted me to think.

All of this, and I never actually contacted their support team! Based on what I found on SmugMug’s site, I can only assume that their team would live up to my expectations. And that, in a nutshell, is great customer support.

Being nice is good (duh!)

With SendAlong, I violated all of the ideas above with one exception: I was friendly when talking with customers. And I could tell that customers appreciated it. I slowly started to see a pattern in how customers communicated with me.

• Their first email would usually be neutral or somewhat passive aggresive/demanding. "Why doesn’t it have feature X? I need this now."
• I always tried to be as friendly and personable as possible in my replies. "Hey, thanks for using SendAlong! That’s a great question, and…"
• After extended the "there’s a human on the other end and he’s nice" olive branch, the next customer reply was usually pretty friendly. "Ahh, that makes sense. Thanks for letting me know, Jon!"

Come to think of it, maybe those first customer emails would have been a lot friendlier if SendAlong had done a better job in earning users trust before they emailed by taking note of some of the tips above…

What tips can you give for providing great customer service? I’d love to add some of your ideas to the list above and into Every Single Shot as well.

Total earnings as of February 11th, 2010: $0

This week was a lot slower than I had hoped it would be. I don’t think I made enough progress to be able to launch a beta (remember to sign up) on February 15th (4 days from now!) – but I’m still shooting for it.

Safe, secure photo storage

I’ve been working on hooking up Every Single Shot to Amazon’s S3 (Simple Storage Service). This is where all of the photos for Every Single Shot will be stored. According to Amazon, I’m using S3 because it’s secure, reliable, fault tolerant, flexible, competitively priced, and most importantly has something to do with "cloud". I use it because it’s easy to work with, stores data redundantly, cheap, and easy to get started with.

I’m using JetS3t (of course the JetS3t site is completely hosted in S3) to work with S3 from Grails. I love it and highly recommend it. That’s all I have to say about that.

I’ve been able to reuse a lot of code that I developed for SendAlong, which was a huge blessing and time saver (let alone a validation (at least in my mind) that I can write some reusable code – there’s a first time for everything).

If you build it…the build will fail

My continuous integration server is great, but it can be a time suck sometimes (when it rains, it pours). I’d much rather be working on features for Every Single Shot than futzing around with trying to fix an ArrayIndexOutOfBoundsException, but hey, you gotta keep the builds happy.

Once I release ESS and get it somewhat stable I’d love to build in some kind of continuous deployment to my development/release process. Having a build server is the first step towards that, I guess.

Next week’s goals

There’s only one goal I’m focusing on now:

• Release the Every Single Shot beta on February 15th (stretch)

Wish me luck. See you next week!

Total earnings as of February 1, 2010: $0

I’ve been busy the last few weeks working on many of the things it takes to turn Every Single Shot from an idea into an actual product.

The last few weeks of work have been really, really fun. Not only have I been coding Every Single Shot, I’ve also worked on branding and setting up hosting. Every day is a different job and I’m really digging the variety. Here’s what I’ve been working on lately…

Development

Where would a web app be without code, right? I’ve spent a fair amount of time in my IDE hacking away to get a basic app up and running (ESS is written in Groovy and Grails). Here’s what I’ve got so far:

• Public facing marketing site: home page, tour, sign up, contact us
• App pages: photo browser, photo uploader, account settings, and a few others

I’ve still got lots of functionality and features to add in – lots. Security is going to be a big one coming up. Another is integration with Amazon’s S3 (more on that below). Oh, and I also need to remember to add in actual features that users care about as well.

Here’s the current LOC (Lines of Code) count for ESS (from running grails stats):

+----------------------+-------+-------+
| Name                 | Files |  LOC  |
+----------------------+-------+-------+
| Controllers          |    14 |   803 |
| Domain Classes       |    15 |   266 |
| Jobs                 |     2 |    59 |
| Services             |     3 |   105 |
| Tag Libraries        |     4 |   205 |
| Groovy Helpers       |     3 |   116 |
| Java Helpers         |     3 |    81 |
| Unit Tests           |    29 |   374 |
| Integration Tests    |     1 |    40 |
+----------------------+-------+-------+
| Totals               |    74 |  2049 |
+----------------------+-------+-------+

ESS’s code base is surprisingly small right now – that’s part of the beauty of Grails.

Branding with a graphic designer

This marks the first time that I’ve paid someone to help me with my business, and I couldn’t be happier with the job Christine did (and is still doing). And it was fun. Really, really fun. To see an idea go from floating around in my head to something real was a very rewarding experience. I’m so glad I decided to pony up the money and pay a professional to help with the branding and UI – I can guarantee that any design I would have come up with would have scared away any potential customers. Given my target market (young fiancés), I knew the design for ESS needed to look good. Mission accomplished!

Here’s the final logo for ESS that Christine created:

See if you can figure out why I didn’t want to do the graphic design myself from the example below.

I needed to put up one page at www.everysingleshot.com just to collect email addresses for my mailing list. It needed to be simple, quick, and get the job done. Here’s my take (click images for full size screenshots):

And here’s the version I made after some help from Christine:

But Christine didn’t just whip up some nice graphics, she also did great work with helping me define and focus ESS’s brand and marketing message. As a developer first and a marketer last, I can’t understate how important it was to have a creative branding person helping me with this aspect of ESS. I’ve been doing a lot of reading on branding and marketing and I recognize their importance in creating a successful product, so I’m really thankful that Christine was able to help me so much with them.

Contact me (jon at juliesoft dot com) if you’re interested in having Christine do some work for you (I don’t want to plaster her email address on here) – I’ll forward your contact info to her.

Hosting on Amazon’s cloud

I used a combination of cloud (Amazon’s EC2) and traditional (eApps) hosting platforms for SendAlong. It worked well enough, but I didn’t like having to manage the two different environments. Plus, the apps on the different platforms needed to talk to each other, and getting them to communicate reliably all the time was kind of difficult.

This time I decided that I wanted to keep the hosting platform homogenous. I also decided that there were at least a couple of different “cloud” services that ESS was going to use such as storage (like Amazon’s S3) and a CDN (like Amazon’s CloudFront). I researched a few different cloud hosting providers including Amazon EC2, Slicehost, Rackspace, and Joyent. I also found a great performance comparison of some cloud hosting providers.

Amazon and Joyent were the front runners, but I decided to go with Amazon mainly because they’re stable, they’ve been around the block a few times, they’ve got good documentation, they’re fairly easy to use, the nice integration between all of their services…the list goes on. I’m not saying Amazon’s services are right for everyone, but they suit my needs for Every Single Shot really well.

After choosing a hosting provider, I needed to get a server set up. That’s where the real fun came in. (If you didn’t know I was a geek, the last two sentences are all the proof you need.)

I’ve dabbled in Linux and the bulk of my command line experience has been in MS-DOS. I’ve had a Mac for the last year and have gotten a little more comfortable with using a real command line, but all of that experience was nothing when stacked up to what I learned in the last two weeks while trying to build out a server with all the goodies ESS would need on EC2. I wouldn’t have said that I was a command line n00b before two weeks ago, but now I think I can back it up. Where have pipes, grep, and shell scripts been all of my life?

While I was working on configuring an Amazon EC2 AMI to my liking (Apache, Tomcat, MySQL, etc.) I came across a fantastic EC2 resource. If you’re running Ubuntu on EC2, or are trying to figure out what OS to use for your EC2 set up, have a long look at Eric Hammond’s alestic site. Not only has Eric provided some top notch Ubuntu server AMIs, but the Canonical team (the people behind Ubuntu) has really embraced Amazon EC2 and provides several “official” Ubuntu AMIs to get started with. I feel completely comfortable using these things in production – it’s obvious that the Canonical team has put in a lot of work on their Ubuntu AMIs.

The coolest thing about these Ubuntu images (I’m using ami-1515f67c on an EC2 small instance, btw) is that you don’t have to rebundle your own AMI on top of them (if you’ve worked with EC2 in the past you know what I’m talking about, and if you haven’t, then just trust me that this is a good thing). This is where I learned about the wonderful world of apt-get, which handles installing a lot of common software for you. Having used Windows most of my life, I’m still not used to this, but package managers are one of the best things about the Linux platform. Need to install Apache2? sudo apt-get install apache2. Need to install Tomcat6? sudo apt-get install tomcat6. Of course you’ll need to customize the installs sometimes, but that’s just a matter of writing a shell script.

Since there’s no need to rebundle your own AMI, there must be a way to configure the base AMI easily, right? Indeed, and of course Eric Hammond has already taken care of that for me. With literally one command, I can launch an EC2 instance (for test or prod), attach a static IP address to it, attach a persistent EBS volume to it (for storing MySQL data), install every software package I need (Apache, Tomcat, MySQL, etc), check out ESS from source control and build it, and have it up in running in about 5 to 10 minutes. This means that when I’m ready to test a new version of ESS, I can issue a command to do all of the above, plus run through all of my automated tests. As long as testing takes me less than 60 minutes, total cost out of pocket is 10 cents.

Yes, I’ve heard that Amazon’s EC2 isn’t as fast as some of its competitors. I’m willing to live with that for now, especially considering that I can run a new server with 10 times the RAM and CPU power with a single command if I need to.

(I’m going to write another post about EC2 and the other Amazon web services in the future that will have lots more helpful information – so remember to subscribe to my blog if you haven’t already.)

Timeline and goals

I need to get a beta out soon. I’ve been developing in a vacuum for too long. My goal is for a February 15th beta release, then rapid iterations based on user feedback (sign up if you want to help), and then a 1.0 release on April 1st. That should give ESS some time to get a bit of marketing traction before the heavy wedding season starts in May.

I’ve got big plans for ESS, so I’ve set some stretch goals.

• Goal #1: 10% of income will go straight to charitable causes (that’s pre-tax, pre-expense income)
• Goal #2: 100 new paying customers per month by July 1st, 2010

Do you have a suggestion on how I can improve these goals? Leave a comment and help me out!

See you next week!

The past

I’ve been blogging here since December, 2006. In that time, I’ve covered lots of random topics, including building my first product. I haven’t (yet) blogged about shutting it down, but that topic is on the short list to cover soon. The last three years have been good, but things are about to change.

During the 3+ years I’ve been blogging I’ve never had a plan for the blog. If something caught my attention, I wrote about it. There was no such thing as “off topic”, because there was also no such thing as “on topic”. Although it’s been fun for me to write the blog, the quality of the content has suffered for want of editorial direction.

That’s changing as of now, and here’s why.

The present

I’m working full time on a new web app. Every Single Shot isn’t a side project. Among other things, it’s my full time job. Some might call this kind of set up a microISV, some might call it a start up, some might even call it a mom and pop joint (ok, no one would ever call it that). I realize that I’m very, very lucky to have the luxury to be able to work on my business – my dream – full time. I also realize that this is just the kind of thing that a lot of other hackers dream about on a daily basis while they’re stuck at their dead end jobs. This is why I’ll be sharing the details of my adventures from now on.

The future

I’ll be chronicling my journey on a weekly basis, talking about what I’ve been working on, ideas I’ve had, and changes that have happened. That’s why I’ve renamed the blog to ChangeLog. (Actually, I’m not renaming it, I’m naming it. It hasn’t had a name until now because it hasn’t had any direction until now.) Just as a stereotypical changelog is to code, this blog is to me and my business: a place to record changes and happenings of interest.

It will be more than just a ChangeLog, though. I’ll still be talking about Groovy / Grails (Grails is hands down the best web framework out there IMO, and I’ll have words with anyone who says otherwise). I’ll be talking about small business, marketing (lots of marketing), branding, site optimization and testing, e-commerce…the list goes on. But instead of talking about this or that with no context, I’ll filter future posts through the lens of my business and its products. Less noise, more insight – that’s what I’m shooting for.

Since this post is meant to be a turning point in my blogging journey, I thought I’d finish by linking to one blog that has influenced me greatly up to this point. This blog is one of my absolute favorites – the kind I where I read every post from start to finish, regardless of content, because invariably I learn something. You should be reading this blog.

Balsamiq blog – READ THIS BLOG!

(I use Google Reader to manage all of my blog subscriptions. If you’re not using an RSS reader to keep updated on blogs, I suggest you check out Reader.)

If you haven’t already, please consider subscribing to the ChangeLog RSS feed and/or following me on Twitter (@jonchase).

Do you prefer blogs that have a specific focus, or those that are a bit more random? What do you think of the direction I’m going to take my blog? Leave a comment below and let me know.

Cocoon picture courtesy of Greyson Orlando via Wikimedia.

Someone just posted a question over on the Business of Software forum asking for recommendations on books and blogs related to sales. Since I’ve been doing a lot of reading on marketing (I know, marketing isn’t sales, but they go hand in hand), I figured I’d post my reading list so that others might benefit.

Here are the marketing books I’ve read recently:

• Inbound Marketing
• Duct Tape Marketing
• The 22 Immutable Laws of Branding (I recently wrote a summary of this book)

Here are a few books that I haven’t read yet but look good:

• The 22 Immutable Laws of Marketing
• The New Rules of Marketing and PR
• Word of Mouth Marketing
• Crossing the Chasm

Happy reading!

And no, the above are not affiliate links.

What about you? Read any good books (marketing/sales related or otherwise) lately? Leave a quick comment below and share them with everybody.

Starting a business is a lot of work, especially when you’re doing it all yourself. I need all the hours I can get in a day, so I came up with a handy little practice that’s really increased my productivity. Yes, I’d even say it’s doubled it (hmmm…does that mean it was abnormally low to begin with?). Your mileage may vary, of course, but if you follow this advice and stick to it, it’s just about impossible to not see your productivity go up.

The Trick

So what is it? What is the miracle of productivity tips that has naught been divined hence?

Simple: when you sit down to work, set a timer. Work your butt off until that timer buzzes, then take a break. Lather, rinse, repeat until it’s time to go home. Let me explain.

I find I can concentrate steadily for about 2 hours at a time. So I set the timer for 2 hours. Once the 2 hours is up, I take a 15 minute break (using the timer), during which time I’m checking blogs, twitter, Facebook, or most importantly – playing with the dog. Lunch time is a little different – I typically take 45 minutes to an hour. I get in four quality 2-hour work sessions every day with little to no distraction. This, in my opinion, is awesome.

How it Works

Why does this work so well? For me, it’s the assurance of knowing I’ll be able to goof off soon enough. That way, I feel compelled to concentrate for 2 hours because I know I’ll be immediately rewarded at the end of it. But during the breaks, anything goes, and since I’ve just worked for 2 hours, I don’t feel guilty goofing off a bit.

Timers to Try

If you want to give this a try, I can recommend a few timers. If you’ve got an iPhone or iPod touch, just use the Timer app that comes with it (make sure you turn the volume up so you can hear the timer go off). If you run OS X, give a timer dashboard widget a try. There are two that I like: Stop It! (my fav) and Tea Timer. If you run Windows, uhhhh…do you own an egg timer?

Bonus

Bonus tip: write your todo’s for the day down. Tackle the tough creative ones in the morning (especially the ones you’re dreading). You’ll feel a since of accomplishment and be motivated to do the boring stuff. Do the administrative stuff and email after lunch.

Bonus bonus tip: don’t do personal email at work!

What do you think? Do you have any easy productivity tips of your own you’d like to share? Comment below!

UPDATE Looking for more marketing books? Here’s a list of good ones that I’ve read recently (or am planning to read).

I just read The 22 Immutable Laws of Branding and was happy that I set aside a couple of hours to do so.

I’m currently working on a new product and a lot of the material was relevant to me. I’ve read a few books on marketing, but nothing specifically on branding. This book has whet my appetite for more.

Here are my notes:

• Generate publicity, not advertising. Best way to get publicity? Announce a new category, not a new product.
• Claim your product is a "leader", not "better". All products claim they are better, but you can’t argue with leader.
• Own a word. Like "luxury".
• Perception of quality is built by a narrowly focused brand, a high price, and a better name.
• Promote the category, not the brand, and be first in the category so that your brand is associated with the category.
• Expand a brand, reduce its power. Contract a brand, increase its power.
• Welcome other brands in order to build the category.
• Generic brand name = bad
• Select a brand color opposite of that of your main competitor’s.
• Consistency is key. Never change your brand, ever.
• What’s a brand? A proper noun that can be used in place of a word.

UPDATE There’s an excellent article on the Grails website that walks through installing and using STS with Grails support. I recommend you use that guide instead of the one below.

STS 2.2.0 was released today with support for Groovy and Grails development. If you’re new to STS, the route to getting everything working might not be clear. The following walks you through installing STS, the Groovy plugin, and finally, the Grails plugin.

1. First download and install STS. STS comes bundled with a full Eclipse installation, so you don’t need to download Eclipse first.
2. Now for the Groovy plugin (required for Grails). Open STS, and go to Help -> Install New Software. Add the Groovy Codehaus site: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.5/. Now install the Groovy plugin from the site you just added. I installed 2 plugins actually, the Groovy Compilers and Groovy-Eclipse plugin options. Restart STS when the install is complete.
3. Now you can install the Grails plugin. In STS, go to Help -> Install New Software again. This time choose the Spring Source Update Site for Eclipse 3.5. Under Extensions / STS, choose the SpringSource Tool Suite Grails Support. Install and restart STS.
4. Create a new Grails project by going to the new project wizard and selecting Grails Project under the Groovy folder.
5. The project creation screen will say that you don’t have a Grails installation configured. Just click the Configure Grails Installations… link, then Add, then Browse, and navigate to <YOUR_STS_INSTALL_DIR>/grails-<version> and choose that directory. Then give it a name and click OK.
6. Give the project a name and click OK to create a new Grails project. Give Eclipse a few seconds to finish creating your Grails project and you should be ready to go.

That’s as far as I’ve gotten so far. If you’ve got any tips or advice, please feel free to leave a comment. Here’s to hoping that the Groovy and Grails plugins are high quality!

With regard to my previous post, it looks like I pulled the Maven command from an old set of documentation. I believe the preferred way to create a new Grails app with Maven is a command like the following:

mvn grails:create-app appName

I can’t say I don’t have anything against Maven, because I don’t like it. Personally I’ve had much better luck with Ant, but then I’ve never worked in a highly distributed team environment with lots of dependencies and builds that couldn’t be managed with a simple Ant script.

Let the holy wars continue…

This just cracks me up.Here’s how to create a Grails app using the Grails command line:grails create-app demoAnd here’s how to create the app using the Maven command line:mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate -DarchetypeGroupId=org.grails -DarchetypeArtifactId=grails-maven-archetype -DarchetypeVersion=1.1 -DgroupId=example -DartifactId=demo