Surround Your World

As a Macintosh user it’s easy to feel left out by cross platform application vendors. Microsoft is too easy a target (though I can’t miss the chance to say I use Entourage every day and it never ceases to make me angry), so I’ll pick on someone my own size. Seapine. Although we have a fully native (that means not Java, you cheaters. You know who you are) client and servers on Linux, Solaris, Mac and Windows we don’t always make them, well, native enough. Make all the command keys match common conventions on that platform. Take advantage of platform specific technology, or the latest UI craze.

Now, it’s easier on Linux and Solaris since the only GUI standard is to have one. Everything after that is gravy. And as a long time Windows user and developer I can say that not even Microsoft can always agree on how to do things. But Mac users often have a different expectation. Hitting command W always closes a window. Always. That isn’t to say that all Mac programs religiously follow UI guidelines, and Apple is often offender number 1, but I think that in general things are more uniform and conventions are more commonly adhered to.

So what about Surround? Did I mention we have a fully native client? Although we’re pretty good in a number of areas, we can do better. Some of our command keys don’t map to the generally agreed to convention. We don’t always follow the latest user interface guidelines (for example, there are a number of places we should be using sheets rather than dialogs on the Mac). I’d probably give us a grade of B minus, but I’m looking to make that an A as soon as possible.

That’s were you come in. Since I bounce around between platforms, I sometimes miss places where we aren’t native enough. If something in Surround seems less than Windows/Mac/Linux/Solaris native, drop us a comment either here or at the feature request forum. Since we go through all the effort to create native clients (and servers) on all those platforms, there’s no reason they shouldn’t go completely native.

Like everyone else, the state of the economy is something I watch. And lately its felt like watching a slow motion car crash. I can’t look away and yet I can’t really do anything either. Some days I feel like I’m watching from the curb, and other days I’m strapped to the hood.

Despite that, Seapine Software in general and Surround SCM sales in particular are doing well. We’ve had good growth each month this year, and good growth from last year. I’d like to believe that this is due exclusively to outstanding product management. A steady and seasoned hand at the wheel, guiding Surround through the rocky shoals of a troubled economic sea. I’d like to believe that, but I’ve been told in no uncertain terms by everyone around me that it just isn’t so. There even seems to be small but vocal minority that believes we’re succeeding despite product management, not because of it. Apostates.

More likely is that it has something to do with the concepts discussed in this white paper “Quality-Centric Application Lifecycle Management in a Down Economy.” I think many companies have gotten savvy to the fact that when the economy is tight, people want to make sure the things they spend money are worth the cost. And that means people raise their quality expectations.

I have a friend who is a CFO, and one of his sayings (besides “Cash is King”) is “Revenue covers a multitude of sins”. When revenues are down, companies demand the highest quality. I think people understand this, and want to make sure that the products they produce have as few problems with them as possible, to ensure that every sales goes well and every customer is a happy one.

That’s where Seapine comes in. Our products are all about making you more productive, producing higher quality products so you can survive and grow during tough periods. I’d really encourage you to take a look at the white paper I referenced above. This is especially true if your company is looking at some belt tightening and every project and activity is under scrutiny. This is a time when you need to increase quality, because you can’t afford a frustrated customer. You can’t afford inefficient processes that lack repeatability and reliability.

I can’t directly change the state of the world wide economy, but I can try and make sure that our customers have the kind of sales growth that we are experiencing. Because the only thing worse that being in a slow motion crash, is knowing that you could have avoided it.

One thing I think about is release frequency. How often should we release new, non-maintenance releases of our software? As often as possible? Bi-annually? Yearly?

On the one hand, I like to give user continual improvements. When people come up with great suggestions, especially when they are straightforward, you want to get them out into peoples hands. Customers will sometimes say “How hard can it be to add XYZ” and often they are right (though just as often they aren’t.) Sales and marketing folks often like something new to talk about, but making them happy isn’t always high on my list.

On the other hand, frequent releases can be a hassle for large (and small) companies. You might need to validate that the software doesn’t break something else you use. You might need to push the update out to lots of desktops. And the constant “noise” of releases can be annoying to decide if this release is worth the time of installing.

This is, of course, separate from your development process and “internal” releases. You can still follow an agile style process, and just release externally on a slower calendar.

So what’s the answer for Surround? I tend to lean more toward major releases every 12-18 months, with a minor release somewhere in the middle. The minor release should include few or no substantive user interface changes to existing functionality. Maintenance releases (with bug fixes only) as needed, of course. Hopefully that’s often enough for users to see the product incorporate their ideas while not forcing them to constantly look at new releases to see what 3 new features are in it.

One of the challenges with any product is how to handle “bad” feature requests. Not every user idea is a diamond in the rough. Sometimes it’s as simple as being very specific to that company/department/users use of the product. Sometimes what they want is counter to what the product is really designed to do. It may just be really, really hard. Or it just may be, in your opinion, a wrong-headed idea.

In any of these cases, what do you do with that idea and how do you convey that back to the user? The typical approach is to respond with something along the lines of “Your input really matters. Thanks for the idea. We’ll definitely consider it.” And that makes everyone feel good, but it’s not entirely truthful to anyone.

In the book Nuts!, by Kevin and Jackie Freiberg, about the success of the Southwest airline, the authors tell the story of a frequent complainer. At some point one of the person’s letters found its way onto Herb Kelleher’s desk, who was CEO at the time. He wrote a letter in reply of: “Dear Mrs. Crabapple, We will miss you. Love, Herb.”

That works somewhat best when you are the president of the company, but none the less I think letting people know that their suggestion is not likely to be incorporated is a reasonable way to treat people. The real downside is it invites a debate.

User “You’re missing the point, this feature would rock.”

Developer “I’m not sure you appreciate the level of effort and small return on investment in supporting the TRS-80 with a Surround Client.”

User “Oh, I see. You’re just lazy.”

Another common response is, “Well then, just make it user configurable”. The issue with that is, it takes even more work. You have to code the feature, the interface to turn it on and off, test everything under both scenarios, and then document all of it.

In the end, I think it depends. Sometimes the right thing to do is say you’ll consider it. Sometimes you should say no, and explain why. The important thing is to have a clear vision for the product and make sure your’re tracking user requests (in TestTrack, of course) so that you can make sure the product is moving forward in a reasonable way. Feel free to comment, because you’re input really matters. Thanks for the idea. I’ll definitely consider it.