Archives for the month of: August, 2012

I am reposting this from my post at

In talking to a lot of startup focussed developers recently I hear the words “domain expert” and “idea guy” used almost interchangeably. There is enough confusion on the subject that I feel compelled to write a small piece on the difference between the two, particularly given that over the past decade I have been both – a domain expert, and an idea guy, and to me the difference is stark.

When I was the “idea guy”: During b-school, surprise, surprise :), I was in a class called “Launching New Ventures”, and I began researching the topic of using algae to create bio-fuels. A few weeks into it I was convinced that I knew the magic formula to take an idea, that at the time of my research was clearly not commercially viable, and create a commercially viable venture out of it. Now keep in mind this is a problem that some very smart people from the US DOE have been grappling with for at least a few decades, but here I was, a 29 year old b-school guy with nothing more than some superficial understanding of the subject matter and a business plan, trying to change the world. From a sophisticated investor perspective, this was a clear non-starter for various reasons, but most critically because it failed the founder-market fit test.

When I was the “domain expert”: While at Accenture I was thrown into the fire of taking over the CTI (Computer Telephony Integration) capabilities of the then nascent NYC 3-1-1 service. We had just launched, and 3-1-1 was still a few years away from becoming the de-facto city service for everything non-emergency related. Now in order to design, develop and manage NYC’s CTI capabilities, I had no choice but to gain a very deep understanding of everything ranging from network latency, to trunking, to automated call distribution systems, to the intricacies of CRM (Customer Relationship Management) application adapters and how all of these things behaved under heavy performance load, various exception scenarios etc. Can a developer working on building an enterprise-grade SaaS based contact center idea leveraging the Twilio API figure all of this out? I am sure they can, anyone intelligent and motivated enough can, but keep in mind there is an opportunity cost involved – someone has to pay for that learning curve, and a venture with very limited resources can rarely afford to do this.

In short, while it is possible for a developer, designer or even a smart b-school type idea guy to become a domain expert, it takes time, its not an overnight process – just as its not an overnight process to become a top notch Ruby or Java developer, or an expert UI designer. I think it is critical for us to stretch our capabilities by learning each others skillets more, as it will only make for a stronger, more well balanced team, and increase our chance of success. I also think it is equally important for us to respect what each of us brings to the table, and not devalue real expertise and the effort required to gain it.


As an enterprise focussed technology consultant, you generally wait until you have something close to the “perfect” product with all the bells and whistles a v1.0  is expected to have prior to launching the product into a production environment. Truth be told there are some big differences between an enterprise product and the soft launch of a new Internet based product or service, not the least of which includes concerns around security and performance. The truth is, given that you are launching a product into an environment that has a concrete business need for it, there could be some significant negative business impact if the product fails to behave as expected. In the Internet startup space however, other than some market validation and A/B testing that you might have done, you don’t even know if anyone cares about your product. Chances are on day 1 other than your core team and a few early supporters nobody does. Hence its critical for you to get the product out as quickly as possible, and begin getting some real world engagement and quality feedback. This step is countless times more important at this stage of the venture, than building out the new cute widget that you think your product needs.

On July 16th we launched our product and invited a handful of users to begin using the product. Boy, are we glad that we made that decision. Waiting a few more weeks, and building out a few more features might have helped a bit, but would probably have hurt us more. Lets provide some concrete insight into what I mean by this. Our product, Neulantis, currently is being built with the objective of enabling designers, developers and domain experts to incubate their ideas on the platform, and to help them find a team to kick start their vision. All version 1.0 of the product had to enable this was:

  • the ability to create a profile
  • the ability to initiate a project and add required skills
  • the ability to provide project updates
  • the ability to follow or join a project

Some of the key features that were not included in version 1.0 included:

  • the ability to communicate with other users either through a messaging system or through a discussion forum on the platform
  • the ability for updates to be broadcast to project followers and team members

Now, while some might consider this to be a broken product, particularly with the inability to initiate conversations with others on the platform or go back and forth with project initiators, we believe that the core functionality required to convey the idea to people and begin true market validation was already there. Up to this point we had no concrete way of knowing if people even cared to post their ideas on the platform, however following the release when people began posting their project ideas we knew that this could work. This was the ultimate purpose of R1.0, to test our most basic assumptions – that people would be willing to post their project ideas, and other were willing to join or follow these projects.

On the same token, some will argue that we could theoretically have tested this assumption with surveys, basic mockups and splash pages, but the truth is at that point people are still not using the product, and from our perspective the sweet spot to truly test your most basic product assumptions lies somewhere between a splash page, and a fully functioning robust product. You need people using the product in some concrete way before your assumptions can be really validated. Further without an actual product, it very difficult for people to provide any quality feedback, and at this stage of the venture engaging your early user base, and providing them a sense of ownership is as critical as having them take the first step of registering on the platform. Since we launched our product, almost our entire development process has been guided by early user feedback, and hypothesis validation vs. master planning, and the product is better off because of this.