New software products - how open should you be?

My day job is at Red Gate. Although we focus on tools for SQL Server and .NET, I'm currently concentrating on making a fledgling Microsoft Exchange tool we're working on a commercial success. Here's a bit of background on what we're doing.

I think most business software sucks. It's buggy, poorly designed, unusable and expensive. It's sold by complacent companies who do not care about their customers. If you've got an iMac at home, and use Google, Flickr and iPhoto recreationally, why should you put up with crap at work?

I think we've found a potential niche for a tool for Microsoft Exchange. I can't tell you much about it, but if you're an Exchange admin then your life is going to get better. This tool will you make you smile.

This creates a dilemma, and I'd like your advice:

How much should we tell people about what we're doing? On the one hand, the more we talk about it, the more likely it is to succeed. On the other hand, we're months away from even a beta and we don't want to tip off the competition.

So what would you do? Post here.

Also, we're looking for people to join the beta program and participate in user research. If you're an Exchange admin and are interested then drop me a line. If you've never taken part in a usability trial then it's an experience worth having. Plus we pay $100 (amazon vouchers) for an hour of your time. My e-mail address is neil.davidson@red-gate.com.

Subscribe to the RSS feed

Comments

[Leo]

Don’t be afraid of competition. Lack of it would be a yellow flag and should make you wonder if you are solving the right problem. I could go and buy a copy of any tool, but knowing how it works doesn’t mean I can make a better product, and even if I could, maybe I’d take a different approach.

[Flint Lane]

There's telling people and telling the world. Having conversations with a select individuals, especially those you expect to target, is a must. It would stink to get several months down the road and have built a product nobody wants (obvious).

I wouldn't post anything on the web unless it's ready for prime time / general availability. No upside to tip anybody off, especially the competition.

[John S.]

There's a difference between revealing an idea and an implementation of that idea. You could even go the route of explaining the problem you're going to solve, without any specifics of how. Ideas are cheap, implementation is expensive. If your implementation is better than the competition, it won't matter how much lead time they have to work on it.

[Roman]

I guess it makes no sense for your potential competitors if you won't publish your functional spec here. Just saying that you have some admin tool for Exchange, and probably discussing some particular topics - like Eric Sink does on Source Control - will definitely not harm you.

At the end of the day, who will stop copiers from making clones form your product after you have released it?

It might also be very interesting if you would simply share your major steps - like how the development goes, what kind of license strategy you have chosen, how and when you start marketing, etc. You might have a code name for your product, like Smileface or something - so you might already start pre-launch activities telling the story of your product.

[Neil Davidson]

Thank you for the advice. I'm going to think about this some more now.

- Neil

[Omni]

Agreed. Somehow, I happenned on your blog. I have not developed since the DB2 days (Ok, I'm 50), but the *crap, solutions that are being put out; do not solve the problems, and do not have the passion of businees problem solving, and mgmt report results.

Omni