Archive for May, 2006

Summer Hours

Wednesday, May 31st, 2006

Summer hours are something of a tradition in Chicago, our home base, and we’re adopting them as well.  The basic idea is simple: work a little more Monday through Thursday, work a little less on Friday.  So, from June 5, 2006, through Labor Day, our hours will be 8:30 to 6:00 M - Th and 8:30 to 12:30 on Friday.

Have a special need outside of those hours?  Let us know.  Email service@fastwebupdates.com or call 888-627-8888.

The Progressive Educational Consulting Group launches

Monday, May 22nd, 2006

PECG’s owners and consultants are highly-trained, degreed educators who have decades of combined professional experience and provided teacher training in special education, literacy skills, reading and writing across the content areas, and math. Find out more at www.pecgroup.org!

Email Marketing: Segment Your Audience

Monday, May 22nd, 2006

One of the questions at Crain’s recent Small Business Forum, Doing the Web Smartly, was how to keep in touch with users via email. Specifically, what is the right frequency for sending out emails?

I’m motivated to ponder this question because, just this morning, I have received my weekly market update from Perl Mortgage. Perl does a lot of business, and, at some point in my past, I worked with them to install a computer network in their office. Ken Perlmutter, the owner, is a good guy: high energy, positive and friendly; very can-do.

So what’s the problem?

I’m slightly irritated to get his email. To put the two opening paragraphs together, I’m irritated to get an email from a customer who has spent a few thousand dollars with me and whom I personally like and respect.

In other words, I’m predisposed to like Ken and to want to receive communication from him, and I’m still irritated.

Those who know me know I’m sometimes irritable, but that’s not the issue here. It’s that I’m not ready to receive the information that he’s ready to send out. Although he doesn’t know it, I’m not in the market for a new mortgage and, unless my situation changes radically, I won’t be in the market for one any time in the next few years (if I have my way, any time in the next couple of decades, but that’s another story).

So let’s get back to the root question: what is the right frequency for sending out emails? The answer given at the forum by the e-tailing rep, was more frequently is better than less frequently because you never know when someone will be ready to buy and you want to be there when they are.

That’s a very generic answer and I disagree with the assumption behind it. The assumption is that you don’t know your customers or, more precisely, that you can’t know your customers. Maybe the assumption is that it’s too expensive to get to know your customers. In any case, when you make the assumption and send out emails that people aren’t ready for, your emails inflict incremental relationship damage on at least some segment of your market.

You need to take the time to segment your messaging or you need to give recipients the tools to meaningfully self-segment. Your messages should go out with a frequency that matches your prospect’s interest level. If you produce a weekly newsletter, allow your recipients to set their delivery frequency to something that works for them. Quarterly is reasonable. Depending on your business, annually may be reasonable.

Going back to the example from Perl Mortgage (who, just to be clear, is far from alone on this issue), I’d gladly review a message from them on a quarterly basis. And if there was an option to select that frequency myself, I’d do it. As it is, the only option I have is to permanently opt out of his mailing list, which I’m not ready to do. (That feature mismatch causes some stress, but that’s also another topic.)

I don’t know that the emailing services (Constant Contact, Emma, MailerMailer, etc) have figured this out, but I’d be surprised if they aren’t working on something. If you send out email using one of these services, contact them (constantly!) until they do. It will help you keep a larger, more meaningful mailing list that gets better results over time.

Feedback? I’d love to hear it!

HopkinsPottery.com Launches

Monday, May 15th, 2006

Introducing HopkinsPottery.com.  Bryan Hopkins produces some very interesting and unique pieces.  Check him out!

Should You Create Custom Software?

Wednesday, May 10th, 2006

For this article, custom website software doesn’t mean the odd script emailing form results or a simple database interface. It means a relatively sophisiticated applicaiton with authentication and busienss logic requirements. So the question is: **should** you create it?

I’ve spent a lot of time thinking about custom software and whether or not it makes sense for non-technical businesses to go down that route. The answer is a very firm, “it depends” with a parenthetical, “usually, no”. Custom software is always an expensive choice. As the sole user, even though the initial cost may be roughly equivalent to buying a package and then implementing it, the ongoing costs of development and support can be prohibitive.

In software engineering (visit our custom software site for more info), we talk about the cost of change. The only thing that’s for sure about any software package is that it will need to change—probably pretty frequently. So what will that change cost? Most often the cost of change follows an exponential curve. (On an XY plot, that looks like a line that starts very low and rises sharply, like a backwards “L”.) As the product gets older, changing one small thing can require a host of other changes so that the time required to change a package is greater than the time required to recreate the package from scratch.

The goal of software engineering practice is to change that curve. Instead of rising exponentially, it can and should rise logarithmically. (On an XY plot, there’s a rise at the beginning, and then a gradual rise as time progresses.) How do we get to that shape? A lot of good ways: strongly typed languages, powerful integrated development environments, refactoring, extensive automated test suites, better practices and a whole lot more.

PHP, what a lot of web software is written in, has none of these things. Or, rather, it had none of these things back in the PHP3 and, to some extent, 4 days which is where most scripts started out. It’s getting some of them now but they’re still in their infancy and most PHP is written without them. What does that mean? That means changing PHP based programs can be expensive and error prone. Significant changes can be done, and they might be manageable, but they often become unmangeable. Many, not all, significant PHP packages stall out after a period of rapid development.

A side conversation: is PHP a valid language to work in? You bet. You can move fast and get a lot done. And you can build very focused, powerful applications in it. It’s not good for large, complex applications. Java is a better choice for that. You can also use Ruby or Ruby on Rails, but those are also subjects for a different day.

What about having to customize an existing package instead of creating a new one–won’t you still face custom maintenance costs? Yes, you will face battles with customization either way. Does this make business sense for you?

It depends on your strategy. If you are primarily a marketing or remarketing organization, I’d say no, you shouldn’t write custom software or heavily customize and existing package. Use the existing packages as is; let someone else worry about the features, and just sell as many of them as you can. If the value you provide is in customizing the packages to better suit a set of unique needs, I’d say, maybe or maybe not. It depends on what value you can help people realize with the customizations and what price the market will bear and the likelihood of someone else doing a better job meeting that requirement than you. Customizations are expensive and risky. Completely custom packages are more expensive and even riskier. And sometimes these very risky things are driven by “wants” rather than demonstrated market “need”. (People will spend a lot of money for a “want” that’s often not justified by strictly business concerns, but that’s another issue.)