A recently posted comment questioned the wisdom of our policy of not talking about what may or may not be under development here. I thought I had discussed that policy here but apparently I haven’t.
As you know, before we started Laridian 11 years ago (October 1998) we spent ten years working at Parsons Technology. It was great to be able to make our mistakes at someone else’s expense before launching our own company. One of the things we learned was not to talk about our release dates before we were ready to ship a product.
There are two main reasons we’ve kept this policy over all these years and through two different companies. First, we don’t want to signal our plans to our competitors. We all compete for a limited number of customers. If we signal our intentions it helps other Bible software companies know how to allocate their limited resources to better compete with us.
The second reason we keep quiet about what we may or may not be working on is to avoid the extra work it creates. If we announce a product, we start getting calls and emails from people who want to know when it’s going to ship. If we announce a date and miss it (which is about a 100% probability in our business) then we have to deal with the customers who call or write to ask what’s going on. They always want to know an updated ship date, though if we missed it the first time I’m not sure why they think we’d get it right the second, third, or fourth time.
If we ignore those requests we’re perceived as unfriendly to our customers. So we have to take time to respond. You might argue that we have the same problem when we choose not to comment on what we’re doing. I can tell you, though, that it’s significantly different. When I can say, “We don’t talk about what may or may not be under development, but we appreciate your suggestions” it brings the discussion to a close. In fact in Tech Support that’s a predefined response that we can just paste into our reply and move on quickly. On the other hand, once we’ve opened the box and projected a ship date, we can’t easily close the box.
We have tried lifting this policy at various times. We did it for iPhone and it was OK for a while but when we ran into some technical issues that delayed the project by six months we ended up having to just shut off the flow of information for a while until we could figure out how to handle the issues. The combination of not really having anything helpful to say and having to answer a few customers who were downright nasty was difficult to deal with.
This raises the point that plans often change or are disrupted. I can’t tell you how many times we’ve completely changed our direction in an afternoon. Our decision to develop the original Web-based app for the iPhone (back when that was the only way you could do iPhone apps) was made on July 3, 2007 and a large amount of development on it happened on the July 4 holiday. Projects we had previously been working on were abandoned or delayed while we dedicated people to iPhone development. However, because none of this was public information, there was no time wasted explaining this massive change of direction to anyone. We didn’t have to apologize for missing a ship date, or reveal our plans for this new platform until we were completely ready to do so. (We actually hinted at it on July 5, but we didn’t really formally announce it until about three weeks later, when most of the work was done.)
I think part of our problem is that we want to be friendly and accessible. I think we’re way more accessible than most other software companies. I reply to every email sent to me, and we reply to all our tech support email in a timely fashion. (Just don’t call me at home. I mean, seriously, some people have no boundaries.) I reply to comments here on the blog. So the more information we have available and out there to talk about, the more time it takes. If we limit the information it helps us also limit the amount of communicating we have to do.
For example, I haven’t been tempted to give a long dissertation on the Android. It’s sufficient to say we may or may not be working on it. If you want to argue that it’s the Next Big Thing and that Google is obviously taking over the world and that we should just get over it and develop for Android, I can end the conversation by saying “we may or may not already be working on it”. I don’t have to get into a discussion of the relative size of the Android market vs. other platforms, the technical challenges of porting to Java, the state and maturity of the SDK, etc. I may or may not already agree with you. There’s no need for me to go into more detail. If I disagree with you, saying so might reveal our plans for the platform. If I agree with you, that also might reveal our plans. And I might be working on it while disagreeing with you on how great the platform is. Or I might not be working on it now, but agree with you and have plans to do it in the future. No matter what the situation is, commenting on it could lead you to the right or wrong conclusion, and now we’re back to the problem of signaling our intent to competitors and having to take time to communicate about it.
The obvious problem with this policy is that it may cost us some customers in the short term. However, if we’re not developing for a particular platform, then we plan to lose those customers anyway. If we are developing for the platform, we could still lose them in the time it takes for us to get our product out the door. So no matter what we do or plan to do, and no matter what we say, we still risk losing customers at any time. So if the other factors outweigh the benefits of talking about projects in advance, it’s worth not talking about them.
This isn’t always an easy rule to maintain, but every time we’ve broken it we’ve been stung by it sooner or later. We’re currently on a pretty tight-lipped phase after having been bit earlier this year. I’m sure we’ll loosen up again in the future and who knows, maybe our experience will be better. At least now you have some idea of our thought process on this policy and I hope that helps.
In the meantime, we may or may not be working on whatever it is you want us to be working on.