Why blogs are important – the video

I don’t know if you’ve ever come across a Commoncraft video, but they’re great 3 minute explanations of some part of the emerging digital world. Their latest: Why blogs are important is a hit.

If you know someone who doesn’t get this whole blogging thing, send them over here.

(Thanks to Tom Raftery)

read more
Why blogs are important – the video

Improving your microISV game for 2008

In just over two weeks, you’re going to take delivery of a brand spanking new year. Are you getting ready to seize the opportunity, or just muddle on?
I’d like to suggest four simple ways you can make 2008 the best year your microISV has ever had.

Without a plan, you are at mercy’s fate. At a conference of microISV recently, someone asked, “how many of you have business plans?” Only two hands went up – but if I had to bet a thousand dollars, those will be the two microISVs that succeed.

Business/marketing plans are one of those things we all know we should do, but don’t. 2008 can be the year you change that. Now, before the new year, while things are quiet, is the time to get ready. A business plan for a microISV should be short, focused on the year ahead, and not read by anyone else but you.

To be clear, I’m not talking about those fictional works generated to liberate money from VC’s; I’m talking about a no-nonsense real plan detailing how you are specifically going to grow your microISV over the next 12 months. If you’re not familiar with that kind of business/marketing plan, I’d strongly suggest you pick up a copy of Market Planning Guide by David H. Bangs: it’s the single best, action-orientated guide for planning your marketing/business development I’ve found to date.

Without tears, clean up old messes. Every business has it’s share of failed initiatives, projects that have run their course, bright ideas that have lost their luster.

For me, it’s letting my microISV product go way, way too long without updates and not applying what I learned about blogging to this blog. For you, what projects, products, and plans in your microISV need to be closed out and packed up so you can focus on the future?

You don’t have to blog about them as I just did, but you do need to acknowledge each failure and decide what to do about it. So take five minutes right now and make a list with two columns. In column one, each project or situation that needs to be wrapped up. In column two, what you are going to do about what’s in column one, and by when.

Sometimes, you have to let go to move forward.
Without fail, put a productivity system in place. Whether it’s David Allen’s Getting Things Done, or Leo Babata’s Zen to Done [non-affiliate link], or any other system that moves tasks from from to do to done, doesn’t leak and doesn’t drive you crazy, it’s high time you get your system together.

Note the emphasis on system: it’s all about the process, not the technology. But the plain and simple fact of the matter is if you’re going to run a successful micro company, you have got to have a system in place that captures each and every thing you need to do. Your brain is not a system – and getting all those to do’s out of your head will free your mind.

Without expectations, talk to your customers. Be it via blog, email, phone, skype or smoke signals, finding out what your customers like – and especially what they dislike – about your application or web site. This real world feedback is priceless for seeing your software the way the world sees it.

The mechanics will vary depending on your circumstances, but the intent is to find out, without pressure or marketing, what you’re customers think you need to do to take your microISV game to the next level for next year.

So, let me ask you: What would you like to see more of and less of here at 47hats?

[tags] microISVs, business plans [/tags]

read more
Improving your microISV game for 2008

Love thy users.

By Yuval Perlov

What do you feel toward your users? Take a second to think about it. Picture them, sitting in concentration, scratching their heads, trying to figure out how to use your latest creation. Make a mental note of your feelings. Keep reading.

My two and half year old daughter has recently decided she wanted to “work” with the computer, just like daddy. I figured painting would be a good place to start so we tried Photoshop for a while. She enjoyed the painting part (throwing the trackball about while colors fill up the screen) but would very quickly get into trouble – she would click outside the window, switch paint tools, hit the start key – the desktop is a hostile environment when you’re starting out. Each time I had to help her out, she grew more frustrated, until it became evident that for sanity’s sake, hers and mine, I better come up with something. Daddy took a day off and wrote BabyPaint.

The basic requirement was to have a safe painting environment where no accidental key stroke or mouse gesture can have unforeseen consequences. As I was coding along, picturing her trying to use it, new requirements came up: The cursor had to be BIG. She had to be able to select colors but the color palette had to be enormous and hidden until explicitly and easily called up. Mouse button optional. Heavy key strokes ignored. etc. etc.

The software was ready to ship on time (daycare makes for a hard deadline) and was a huge success. She immediately sat down to use the program and simply got it. Plain joy, no frustration (I could tell by the relative lack of high pitched screams). It was my proudest moment as a developer. The application had all the features and polish needed for her to have a positive experience on the first attempt. I also had a great time writing it.

So what (you ask)? Creating software for your kids, exciting as it sounds, is not the basis for a compelling business plan (unless you have enough of them for a long-tail strategy). Well, the point is this: the feeling wasn’t new. It was the same feeling I get every time I create an application. I want my users to have a good time and succeed at what they do while also taking pride in my creation (in an infantile “look what I did” sort of way).

Love thy users is a rare sentiment in the software business but it’s out there. Developing software is as much a creative process as it is an engineering discipline. Pen-to-paper, paint-to-canvas, button-to-form. All subject to the taste and personal preferences of your audience. The people that use your software do so because they like your style, respect the decisions and compromises you made and intuitively grasp your way of doing things. They deserve the same love music fans get from their idols (of course, when I say users I mean people who are actually using your software. The people from purchasing, legal, PM group, requirements committee, let them find someone else to love them).

Our users are not only our audience and fans but also the true connoisseurs. Your boss/friends/mother can all look impressed and give you a raise/pat on the shoulder/kiss on the cheek (respectively I hope) but they can’t truly appreciate your work – it doesn’t address their need. Our users are the only ones who have the time and depth to fully understand the subtleties of our applications. They are the only ones that have the particular itch we are trying to scratch.

This feeling, I believe, is at the heart of all great software. Done right, the actual design, coding and testing become mere details, technical activities that need to occur for a vision to take form. Scrum vs. Agile, Ruby vs. PHP, C# vs. Java are all important questions (well, questions) but are not central to the matter (also, let’s face it, you end up writing JavaScript most of the time anyway).

The love for our users, that’s where the real advantage of MicroISVs and startups lies (at least the ones that are in it for the right reasons). That is why the next time someone looks at your software and tells you that it would take an IBM or an HP five days to develop and two more weeks to throw you out of the market, you are allowed a humble smile.
When he’s not writing software for his kids, Yuval heads R-U-ON, a simple IT monitoring service. He occasionally writes about software at http://usqs.blogspot.com/.

read more
Love thy users.

links for 2007-12-12

read more
Bob Walshlinks for 2007-12-12

A good interview with a microISV

Clarke Ching just posted an interview he did with Text2Go’s Mark Gladding. What keeps Mark up at night?

Am I moving too slowly or more precisely, I am taking on enough risk? Should I borrow money to invest in the business or continue my current approach of bootstrapping the business? This is a decision that I review constantly. I’m afraid that a competitor will come along that is either well funded or willing to take on more risk and create a product that will blow mine out of the water. This fear does have the benefit of keeping you focused.

Good things for every microISV to think about…

read more
A good interview with a microISV

Fighting Death by Spam

By Bob Walsh

There’s a special place in hell for people who ignore spam getting into their life and I’m in it.

Let me explain. I’ve been working this summer on Project X and largely neglecting my microISV’s tech support/defect system: while bugs and inquiries have gotten processed, since I set up my VB6 app to email bugs in, there are two email addresses that have been getting spam stuffed.

The app I’ve been using for years for this is Fog Creek’s FogBugz, and normally it does a fantastic job of sending spam right to the trash. But it needs to be taught which messages are spam and which are not. It’s not enough to just respond/resolve real cases – you’re supposed to move them out Undecided as either Spam or Not Spam.

Oops. My bad. Very, very 15,000 spam messages in my database bad.

In preparation for what I hope will be a great 2008, I’m shamelessly taking advantage of Fog Creek by moving from the hosted FogBugz service I’ve been using for the last year to Fog Creek’s very own hosted service. Not only does Fog Creek have a free startup/microISV option if you have 1-2 users, they were kind enough to move my db over to their servers for free (thanks Jason!).

But that still leaves me with 15,000 spam to kill – and Fogbugz is not designed to make this kind of user error easy to correct. So it’s Click All to select the 200 cases that are actually spam emails, scan them quick to make sure I haven’t missed any real cases along the way, click again to move them to Spam which I should have done when this started to become a problem wait for the server, and repeat. And repeat….

Only about 8,500 to go.

How’s your day going?

read more
Fighting Death by Spam

Deciding what goes into your microISV product

by Jan Goyvaerts

Last month I had the pleasure of meeting Bob Walsh at the European Software Conference. The evening after the conference, a bunch of us had dinner at a Mexican-Italian eatery near the Dom in Cologne.

During our conversation, Bob mentioned that EditPad Pro has been his favorite text editor for quite some time. He said that he got the impression that for the version 6 upgrade, I seemed to have focused on “ticking all the boxes” when comparing EditPad Pro with other popular text editors. Fact is, I hardly ever look at competing products.

My vision is that if I spend too much time looking at other products, I’ll just end up with copy-cat design for my own. It’s easier to design something new when starting with a blank slate than with starting with how things have been done before. At least it is for me. Just like it’s easier to learn a new habit than to unlearn a bad habit.

So how did I decide what to put in EditPad Pro 6 and what not? Easy: customer feedback. Many years ago, I spent an afternoon or two to hack together a simple bug and feature tracking database. It’s just four tables for products, versions, and issues in a master-detail relationship. The fourth table is the reason I rolled my own instead of using an off-the-shelf product. At the time, I couldn’t find anything that could keep a list of customers for each issue being tracked. So if Joe requests feature X, I email Joe a boilerplate “thank you for your feedback”, enter issue X into the database, and paste his email as a vote for issue X. That gives me a good idea of how many people care about X. That in turn allows me to estimate a cost/benefit ratio of implementing X.

It’s not a democratic system where issues with most votes get implemented. Reproducible bugs always get fixed, even if nobody complained, or “Just Great Software” wouldn’t be what it says on the box. Major new features or UI redesigns always get pushed ahead to the next major upgrade. While new features sell, product stability sells too. But when deciding what we have time for, and what needs to wait, customer feedback is a very useful metric.

Of course, Bob wasn’t completely off the mark. EditPad Pro 6 did add a lot of features that are, in some form, available in other text editors. Our customers have seen or even used those editors. “Product Z has X. When will EditPad have it?” is a very common request. But instead of just downloading product Z and plagiarizing the whole feature, I look at why the customer wants the feature. Most customers motivate their requests. Entering the relevant details into the feature tracking database helps to improve the feature’s design. E.g. when people were requesting built-in FTP for EditPad, it was obvious that the need was speed and convenience. The power of a stand-alone client wasn’t needed, because everybody already has one. Hence EditPad 6 got FTP as a sidebar that can stay connected to multiple servers for quick online editing. While that certainly ticks “FTP” on the feature matrix, such comparisons don’t show how happy people are with the feature’s implementation. E.g. had EditPad Pro 6 implemented FTP in a modal dialog, it would have been even less convenient than an external client. (Not that I ever considered such horrible design.)

The cherry on the cake is that collecting email addresses as votes gives you a very valuable means to contact your customers. When a new release fixes a bug or adds a feature that Joe emailed us about, Joe will get an automatic email saying the latest release implements X. Even though the message isn’t very polished (and it apologizes for being so), customers really appreciate this bit of attention.

My recommendation is to worry about making your customers happy rather than ticking all the boxes. Word-of-mouth is far more powerful than a doctored comparison from your marketing department hat.

Jan has been running his own microISV Just Great Software every since unsuspectingly releasing a hobby project called HelpScribble to the world in 1996. Shareware Beach is his personal hangout in the blogosphere.

read more
Deciding what goes into your microISV product

links for 2007-11-22

read more
Bob Walshlinks for 2007-11-22

A checklist for your microISV site.

Here’s a good starter list for making sure your microISV web site has the basics down in terms of ease of use: Scientific Web Design: 23 Actionable Lessons from Eye-Tracking Studies

Again, nothing startling in this list, but if your site is breaking any of these best-practices, you’d better have a good reason why.

Here’s the gist – see the post for why these are things you should be paying attention to.

1. Text attracts attention before graphics.
2. Initial eye movement focuses on the upper left corner of the page.
3. Users initially look at the top left and upper portion of the page before moving down and to the right.
4. Readers ignore banners.
5. Fancy formatting and fonts are ignored.
6. Show numbers as numerals.
7. Type size influences viewing behavior.
8. Users only look at a sub headline if it interests them.
9. People generally scan lower portions of the page.
10. Shorter paragraphs perform better than long ones.
11. One-column formats perform better in eye-fixation than multi-column formats.
12. Ads in the top and left portions of a page will receive the most eye fixation.
13. Ads placed next to the best content are seen more often.
14. Text ads were viewed mostly intently of all types tested.
15. Bigger images get more attention.
16. Clean, clear faces in images attract more eye fixation.
17. Headings draw the eye.
18. Users spend a lot of time looking at buttons and menus.
19. Lists hold reader attention longer.
20. Large blocks of text are avoided.
21. Formatting can draw attention.
22. White space is good.
23. Navigation tools work better when placed at the top of the page.


read more
A checklist for your microISV site.

links for 2007-11-13

read more
Bob Walshlinks for 2007-11-13