Staying In Touch

October 30th, 2010

Update: I originally cited the content of a customer’s email in this post, and although I didn’t reveal her identity, I don’t think this was appropriate or particularly constructive.

Mea culpa.

In the future I will never cite the contents of a customer’s private email, no matter how anonymously, unless they have expressly permitted me to do so.

I have edited the post to remove the contents of our correspondence with each other. I am leaving the post because I still think it expresses some interesting ideas.

Continuing the recent trend of posts about, essentially, “just doing it,” the purpose of this post is to underscore the wisdom of staying in touch with customers, while acknowledging that doing so brings its own challenges.

Since I established my own web store a few years ago, I have collected the emails of customers who buy my software and, for those who leave the pre-checked option selected, subscribe them to a company newsletter for infrequent announcements:

MailingListCheckbox.png

Infrequently is the operative word here. In more than three years I’ve neglected to send even one email to these folks. This is a problem, because permitting me to contact them set up the expectation that I would. When major releases such as MarsEdit 3 have come out, some people don’t find out until months later, and tend to be annoyed that they haven’t heard about it directly from me.

Yesterday, I finally got around to setting up a mailing list with Campaign Monitor, drafting a simple plain-text letter, and pressing the send button. I finally broke the ice.

For those of you who are not on the mailing list, here’s what I said:

News From Red Sweater Software

Hello from Red Sweater! This is Daniel Jalkut, its founder and, for now, its only employee.

When you purchased one of my products, you agreed to receive infrequent email updates that keep you up to do date with my latest products. Since that time you have received approximately zero emails! I sort of dropped the ball on direct communication, but I’m working to rectify that now.

Messages will still be infrequent and hopefully pertinent, but if you are no longer interested in receiving updates about Red Sweater, just visit this link to unsubscribe:

(unsubscribe link)

On to the news: what’s happening at Red Sweater?

1. MarsEdit 3 Released

Earlier this year I released a major update to MarsEdit, our desktop blog editing application. MarsEdit now sports a rich text “WYSIWYG” editor, support for WordPress pages, and a media browser that integrates with iPhoto, Aperture, and Lightroom. Read more about MarsEdit 3 on the web:

http://www.red-sweater.com/marsedit/new3.html

If you don’t already own MarsEdit 3 you can purchase it for $39.95, or update from a previous version for $14.95:

https://www.red-sweater.com/store/

2. iPhone and iPad Releases?

People often ask about my plans to release applications for the iPhone, iPad and iPod touch. It’s easy enough to convey my intentions, but a bit harder to make specific promises. I am very excited about building iPhone and iPad versions of my apps, especially MarsEdit and Black Ink. I have made significant progress on these apps but there is still fine-tuning that needs to be done before I’ll be prepared to release them publicly.

3. The Mac App Store

You may have heard the news that Apple is planning to launch a Mac version of the App Store, which will give Mac users the ability to easily browse, purchase, and install applications in a similar manner to the way it works for iPhones and iPads. I’m hoping to get most or all of my apps into the catalog so I can reach an even wider audience of users. The good news for you, my existing customers? More customers will hopefully lead to more revenue, which means more resources and impetus to continue adding great features to the applications you already love.

4. Keeping In Touch

As I said earlier, I am resolving to do a better job keeping in touch. Next time a major update like MarsEdit 3 is released, you’ll hear about it before 6 months have passed! But if you want to proactively stay tuned in on an even finer level, there are some resources available to help you monitor our progress:

Email support. You can contact Red Sweater with whatever’s on your mind, be it a bug report, feature request, or just to say hi.
Address: [email protected]

Red Sweater Blog. The official company blog is my platform for providing a combination of company news and business-related thoughts and analysis.
Link: http://www.red-sweater.com/blog

Twitter accounts. For short, conversational style updates I maintain a personal account, a company account, and a special account just for MarsEdit:
Link: http://twitter.com/danielpunkass
Link: http://twitter.com/redsweater
Link: http://twitter.com/marsedit

5. Thank You

I want to close by thanking you for your business. I have been working on Red Sweater for over 10 years now, and in the past few years it has reached a level of success that supports myself, my wife, and my son. This is so unfathomable to me that I can only assume the sky is the limit! Let’s keep working together: your feedback and support combined with my desire to build great products should lead to many more years of successful results.

Daniel Jalkut
Founder, Red Sweater Software

To unsubscribe from this email list, just visit this link:

(unsubscribe link)

Delivery Confirmation

Campaign Monitor made the mass delivery painless for me. Thanks to their sophisticated tools, I know a day later that the vast majority of recipients received the letter, and only a small percentage have unsubscribed. Out of the thousands (wow!) of messages that were sent:

97.1% appear to be delivered
2.9% bounced
1.48% unsubscribed after receiving
1 reported it as spam (1 person, not percent – can’t win them all!)

This kind of feedback is great, but nothing compared to the direct responses I got from customers. The semi-personal tone of my letter inspired customers to respond in kind with heartfelt support and encouragement.

I received dozens of responses, ranging from the brief, enthusiastic “Word!” to longer, philosophical letters about small business, following one’s dreams, and the meaning of work in life.

Then, early this morning, I received this:

[EDITED: In retrospect, I do not believe it was appropriate for me to share the content of a customer’s email here, even if information about her identity was removed.]

An upset or merely irritated customer always calls for a cautious response. The last thing I want is to escalate the situation. But this response is particular challenging, due to the number of provocative facets:

  1. The customer is not pleased by the email I sent.
  2. The customer is using a sarcastic, admonishing tone.
  3. The customer projects a lack of respect by omitting proper punctuation and sentence structure.
  4. The customer’s core criticisms are vague and subjective, making it hard for me to evaluate whether an apology or correction is called for.

These facets sort of multiply with each other and make it difficult not to respond defensively. My first reaction is to shout something into my email client like “What the hell?! Most people like a little humanity in a company, and furthermore, I did enumerate benefits where appropriate, and the content of this letter addresses the most common questions I have received over the past few months. And … and … who pissed in your Wheaties, anyway?

Instead I take a deep breath, vent a little to my friends on IRC, and respond:

[EDITED: As with the content of the email from the customer, I don’t believe it is appropriate for me to include the content of my response.]

I then proceeded to vent on Twitter about the response. I wasn’t particularly looking for comfort, but was glad to receive supportive responses from people who agreed there was cause to feel irritated by the customer’s tone. A sample of the dozens of reactions:

“That’s the kind of thing, when said in person, earns someone a kick in the teeth.” — @dssstrkl

“That guy is a jerk. Keep your personality in your work. if he doesn’t like it, let him use products from huge faceless corps” — @scottaw

“Personally, I couldn’t live with myself without adding a note about their tone. Why encourage an asshole.” — @mrgan

“Screw that guy. He’s just jealous that your Indie endeavors are successful enough to support you and your family. Good on ya!” — @fonix

“He presumes to speak for all your customers, co-opting “us.” He does not. Bravo on your measured and thoughtful response.” — @artgillespie

“That guy replied as if you were trying to sell him something. Your letter was more like a ‘state of the union’ communication.” — @morrick

Many of the responses refer to the customer as “him,” while none of them refer to “her.” In fact, this customer is either a woman, or a man with a very feminine name. Apropos of not much, but it’s interesting that we tend to assume somebody who is “being a jerk” is a man. I would have made the same assumption.

Do I feel a little disingenuous about responding to the customer politely and without indication of my annoyance, while essentially glorifying her message behind her back on Twitter and now here? Yes. This is not really my style, and I don’t think it’s very classy of me to share the private message of a customer, even if I am preserving her anonymity.

But, I think this experience is instructive both to customers and other small-business owners. And since I already vented on Twitter and essentially let the cat out of the bag, I thought I might as well go all the way.

Staying In Touch

What does it mean to stay in touch? It means building and preserving a relationship with customers. The stronger the relationship, the greater the empathy for the other’s circumstance. But as with other relationships, the increase in communication and contact leads to an increased risk of misunderstanding and offense.

My letter served a valuable purpose. It let my customers know that I’m thinking about them, that the checkbox they vaguely remember leaving selected wasn’t pointless. That I do have plans for the company and for the products they purchased, and that I am interested in turning a new leaf with regard to communicating directly with them.

The challenging customer and my reaction to her has also been helpful. It reminds me of the related importance of “staying in touch” with my own values and priorities. Over the course of Red Sweater’s growth, I have used a very rules-based approach to how I handle just about everything. Running my own business means biting my tongue and doing “the right thing” even when the instinct in my animal brain wants to do the opposite. This is true for coding habits, fiscal responsibility, and yes, customer support habits. A variety of informal rules help to keep me in line.

As I have gained confidence in my own decisions, I find myself more prepared to break these rules. I suppose that pragmatism slowly takes over. When I first started out, I informed my decisions by asking “what would a good business do?” Then I learned to admire other Mac software companies such as Bare Bones, Rogue Amoeba, Panic, and Omni, and asked myself “what would they do?” I still defer often to the wisdom of others, but sometimes I have the distinct pleasure of asking myself “What would I do?” and acting on it. Staying in touch with myself is as important as staying in touch with my customers.

Blog The First Draft

October 26th, 2010

MarsEdit users sometimes sheepishly admit that they aren’t blogging as much as they “should” be. Excuses vary, but it usually boils down to the classic issue afflicting all of us who try to stick to a productive routine: we simply fall out of the habit.

Long time readers of this blog will note that I’ve had my dry periods as well. But watch closely: I’m blogging now about a thought I had just earlier this evening, while reading Twitter updates and responding to them. Colin Barrett complained that his perfectionism is limiting his blogging:

I plan to write more; I think my @secondconf talk on freelancing would work well as a series of posts. Just gotta get past my perfectionism.

I’m incredibly familiar with this line of thinking. In fact, it’s a variant of the indefinitely postponed software releases that I just wrote about. I read Colin’s tweet and, before I had even noticed that the neurons in my brain were firing, I had responded with a bit of encouragement:

@cbarrett The modern business model for solo writing is to blog your first draft and sell your final.

I’m referring to the fact that very few blogs are edited to the level of professionalism you might find in literary or scientific journals. On the contrary, some of the web’s most celebrated bloggers have let their essays loose in a semi-rambling form, only to piece them together later into a more refined, salable volume. Rands in Repose and Joel on Software spring to mind in the techie world, while writers such as Heather Armstrong and Julie Powell turned their respective parenting and cooking blogs into million-dollar enterprises.

The ever-so-thinly veiled message? Don’t worry so much. Just blog it. If you are among the lucky few who achieves perfection effortlessly, then by all means carry forth. The rest of us are lucky if we coerce a unit of coherent thinking out our brains and onto the web. Perfectionism? Your editor will help you achieve it after you’re famous.

Suck It Up And Ship

October 19th, 2010

When I introduced the rich HTML editor in MarsEdit 3, I knew there would be some issues. WYSIWYG editing is freaking hard. I don’t pretend to have started out an expert, nor have I become one. I’m getting there, though!

I decided to release MarsEdit 3.0 when I did because of what I refer to lovingly as my “suck it up and ship” mantra. I tell other people all the time that you can’t hoard your work. Sure, putting off the ship date indefinitely will allow you to avoid the embarrassing critiques, the discovery by the public that you are in fact imperfect. But you know what? They never get to try out your app, either.

The customer-developer feedback loop is exceedingly important when it comes to prioritizing bug fixes. The months you spend “perfecting” your stuff will undoubtedly focus on parts of the app that your users don’t even, as it turns out, give a damn about. Get your 1.0 (or 2.0, or 3.1.2) to users as quickly and responsibly as possible, and evaluate the results.

On that note, MarsEdit 3.1.2 is available today, fixing an issue in the rich text editor that, suffice to say, is far more than a “minor glitch.” In a nutshell: if you did a “search and replace” where the replacement text included the search text, the app went into an infinite replacement loop, hung, and required a force-quit.

That is so not Red Sweater. Yuck! I discovered this thanks to my new (as of 3.0) crash reporter that, while providing precious few details about the reason for the force-quits, eventually included key feedback from a user who offered the hints as to what was happening.

I hope this release cuts down dramatically on the number of mysterious, context-free crash reports. There are some other goodies, too:

MarsEdit 3.1.2

  • Fixes for issues with Find/Replace in the rich editor
    • Fix a potential hang when doing replace all
    • Fix “Use Selection for Find” menu item
    • Fix behavior of “Replace All” when limiting to selected text
  • Fix a bug that prevented “None” from sticking as preview filter choice
  • Fix a bug that caused wrong alt text to be generated for some uploads
  • Prevent ugly clipping of font descenders e.g. on lower case “g” in Media Manager

Here’s to the next imperfect release!

Don’t Coddle Your Code

September 23rd, 2010

Jeff LaMarche presents a rundown on whether Objective-C dealloc implementations should bother nil’ing out an instance variable after releasing it.

LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing the variables in production code is wise, because it might mask crashing bugs that would obviously vex the user:

Generally speaking, this is only going to happen if you’ve got a bug elsewhere in your code, but let’s face it, you may very well. Anyone who codes on the assumption that all of their code is perfect is begging for a smackdown.

And speaking specifically about the approach I prefer, leaving the instance variable alone and not bothering to nil it out:

On the other hand, that approach is really, really bad in a shipping application because you really don’t want to crash on your users if you can avoid it.

I disagree with the assertion that avoiding crashes at all costs in shipping code is the right priority. The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways. Sure, we all make mistakes as programmers, but giving in to the chaos and putting up safety nets “just in case” is not the right approach, especially considering it has unwanted consequences.

Consider that by masking the crash from occurring in the wild, you may be putting off detection of and resolution of the underlying bug indefinitely. But if your application has a crash reporter, or if you take advantage of Apple’s iOS crash reports, you will learn quickly that there are issues needing to be resolved.

It is reasonable to take steps that mask mysterious crashes, but this should only be done after you know there are actually crashes to prevent. Masking the symptoms in a blanket manner is akin to cutting half the phone lines in the neighborhood and celebrating the reduced number of 911 calls.

It’s also worth noting that LaMarche’s defense of nil’ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways. Consider this incredibly contrived Cocoa-based nuclear arms controller:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
 	[[NuclearWarehouse nuclearMissile] launch];
}

By LaMarche’s reasoning, it’s a good idea to nil out the mDiplomat variable on release, so that it won’t crash when you message it. But in this case, messaging nil for a BOOL result causes a logical flaw in the program, with obviously dire consequences. If the instance variable were not set to nil, it would probably crash before the launch message could ever be sent.

We should aim to comprehend what our software actually does. Deliberately decreasing the symptoms of problematic code won’t lead us any closer to that understanding. Ship the best code you have to your customers, and if it crashes, try to fix the root cause of the crash as quickly as possible. Don’t get in the habit of writing “hope this fixes it” code, and by all means don’t adopt that philosophy as a boilerplate coding habit.