So we had a product (Omega.MSSQL) which can be used to manage SQL Server databases through a browser based interface. Around the time I came back to India, Microsoft announced Windows Azure and one of the component there was SQL Data Services (SDS, code named Sitka). It was presented as SQL Server in the Cloud (BIG mistake, IMO).
Initial Development
This was one time (and I think the only time) when I applied some forethought into building a product. What I thought that since we already have a product which can be used to manage on-premise databases and sooner or later users will start using this cloud database so in order to have complete coverage we should have a management product for this SDS. Only with that reasoning, we started building the product.
The problem was Sitka was still into beta mode and you would need an invitation to try it out. I tried to get invitation a number of times but nothing happened. I was also subscribed to their newsletter as well and through one of the emails, we got our break. One fine day, I received an email about Sitka and it was from one of the program managers on that team. I wrote him back telling him what we want to do and are unable to do so because we are not in the beta program.
He was extremely kind and got us into the beta program. I think we started working on this product somewhere around November of 2008. We read through documentation and built the tool based on what we understood. It took us 30 – 45 days to build this application. It was not complete by any means but did some basic management tasks and we were happy with what we had built so far. So we thought let’s release it.
(Image Courtesy: Jamie’s Blog about this product. Link below)
Now I had no idea about how to go about releasing it 
. I set up a meeting with the same guy from Microsoft and showed him the tool. It was available online but nobody knew about Cerebrata at that time so nobody was using it. He tried it out and loved it. This was the first of its kind of tool. He recommended that I should post it on MSDN Forums. You can judge my ignorance by the fact that I was not even aware of MSDN Forums (I’m really serious). I signed up for MSDN forums and posted a link to our application with some basic description: http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/a4ce8e32-358a-4836-84cf-0d7344a12c15.
Look Ma, We Got Blogged!!!
To our surprise, Jamie Thomson (@jamiet), a SQL Server MVP and now a good friend found the application so useful that he wrote a blog about it: http://consultingblogs.emc.com/jamiethomson/archive/2009/01/08/cerebreta-release-omega-sdsclient-built-in-silverlight.aspx.
It was really a big deal for us that somebody wrote a blog post about our product and that somebody happened to be Jamie who is very well respected in the community. We were elated and felt proud beyond comprehension. This was our moment of glory .
Treat this as my Oscar acceptance speech , but I would also like to take this opportunity to thank Mike Amundsen (@mamund), Kapil Muni Gupta, Anil Reddy and other folks. They helped and encouraged us a lot during the course of development of this product.
Tapping The Power of Community
When it comes to building products, either you know what you’re doing or you don’t. We fell in the latter category .
A lot of successful products are built out of necessity. Take the guys from 37signals (http://37signals.com) for example. If you have read their books, one thing they mentioned is that they built the products because they felt the need for such products and couldn’t find any product meeting their requirements so they built them instead. Later on they started commercializing their products.
As far as we were concerned, we just went in blindly (Stupid & risky thing to do, I would not recommend it to anybody who’s starting out now). We were not using SDS at all to realize what needs to be built there (Requirements in Software Lingo). Heck, we were not even aware of all the features offered by SDS to decide which features should we incorporate and which ones should we leave out. This is where awesomeness of community kicks in.
When you don’t know what you’re doing, best place would be to go ask somebody who knows (typically your existing or potential customers). In the initial days, our go-to-destination was MSDN forums simply because we didn’t know where else to go to. If you look at the thread I posted above on MSDN forums, you will notice that folks gave us feedback, suggestions, guidance without expecting anything personal in return. The feedback we received on the forums was extremely important to us in two aspects:
- Since folks are giving feedback to us, what it told us that they see some value in our product which is always a good sign.
- The users who gave us feedback were not users like us (who went in blindly). They were seriously using SDS day-in-day-out and the feedback they sent us included the things they would like to see in the product, bugs they found and any half-baked or missing implementation in our product. That gave us the “Requirements” for our next versions.
I’ll talk again about these community forums again when I talk about the kind of marketing we did with our products in another post.
That was the day I personally got hooked up in the community. Initially my interaction/contribution was only around the threads I created (mostly about our product) but as we started learning more about SDS, I started contributing more to these forums. I’m still very much involved in Azure community and try to answer some questions to the best of my abilities. In fact, my active involvement with the community rewarded us quite handsomely. People genuinely appreciate if a tool vendor comes out and helps them on these community forums. [I think only because of this, I was awarded MVP in 2010].
So with community support and blessing, we started working on the next version of our product.
Next Version
When I look at the code of the first version now, I don’t really know should I laugh about it or cry about it. Though I am (and always will be) proud of what we have done, the fact of the matter is that the code we wrote was bad. No, let me correct it: It was real bad!!! We didn’t follow any design principles or coding guidelines and coded the way we pleased (we corrected this problem actually a lot later when we rewrote Cloud Storage Studio).
One thing that worked in our favor was that we were agile. We discarded the old code completely and started writing it from scratch (It was still bad code but better than the previous one ). We implemented new features, changed the UI completely. Our first version was out in 1st week of January 2008 and by the end of January, we were out with our next version (and our last version as well, more on this below)
And We Go Bust
One of the problems with SDS is the way it was pitched to the developers. Initially it was named as “SQL Server Data Services” which was later changed to “SQL Data Services”. Both of these names include “SQL” word in it which led developers to believe that they are getting relational database capabilities with this service which they were clearly not and that lead to a lot of discontent from the developer community. Fortunately, Microsoft heard loud and clear and decided to dump SDS in its current form. During Mix conference in 2009, they announced the availability of what is now known as SQL Azure.
Fortunately we were told way in advance about this change and we stopped doing any active development on this product I believe since February of 2009. We just kept the site alive and did minor modifications but made no major changes after that. Because of the early warning, we were already on to our next product (in next blog post) when this news broke out.
Lessons Learnt
So in a brief period of 4 months, we conceived the product, went through a few iterations and shut down the product. We learnt a lot both from technology and product perspective. Some of the things we learnt at least from the product development perspective are which we applied in our subsequent products as well:
- IT IS OK NOT TO HAVE A PERFECT PRODUCT. In fact, I have come to the conclusion that you can never build a perfect product!
- IT IS OK NOT TO HAVE A COMPLETE PRODUCT. However please ensure that the functionality you have released work flawlessly.
- SEEK HELP IF YOU DON’T KNOW WHAT YOU’RE DOING. There’s Apple (Steve Jobs’ one) and then there are rest of us .
- RELEASE EARLY RELEASE SOON. Especially if you don’t know what you’re doing, it’s in your best interest to keep the guys engaged who are helping you out. That way you’ll be able to fix defects faster.
- HARNESS THE POWER OF COMMUNITY. It will do wonders for you!
Summary
So, this was the story of our first product (that we released) which went from boom-to-bust in just 4 months. However this product laid foundation for our next set of products. I will talk about that journey in subsequent posts.
So Long and Stay Tuned!!!
