The group about Cloud Computing Services and it’s components: Software-Development-Platform-Infrastructure-Anything as a Service
June 4, 2010 at 2:56 pm #102234
Make sure, if you have an interest in this commentary you read the rather extensive comments
Software as a Service (SaaS) – Using Conjoint Analysis to Make Tough Product Decisions
Making Tough Product Decisions – Gut Feel v. Quantitative Analysis
May 9th, 2010 § 6
Since I started in venture capital four years ago, I have met with a lot of software entrepreneurs in early stage start ups. One consistent theme across all those meetings is that I have found entrepreneurs tend to rely fairly heavily upon qualitative v. quantitative analysis to determine features, markets, pricing and positioning for their initial offerings.
I can certainly understand why this might be; most early stage entrepreneurs are subject matter experts in their domain and have a strong point of view with respect to what their application/product should do. In addition, quantitative analysis can take time and money – something that is in short supply at an early stage startup.
That said, even the best product team can get it wrong — delivering a product that may not be exactly what the market wants, or is priced and/or positioned incorrectly. And, unlike larger software companies, a mistake in an early stage software company can be fatal – or at least cause the company to have to take in more capital and require more time to get into market.
So, I am surprised that more start up software companies (and big software companies, for that matter) don’t incorporate more quantative analysis to help them make critical product, market, features, pricing, and positioning decisions.
In my opinion, the best methodology for making such trade-offs is conjoint analysis. A definition of conjoint analysis from Survey Analytics follows:
Conjoint analysis is a popular marketing research technique that marketers use to determine what features a new product should have and how it should be priced. It requires research participants to make a series of trade-offs. Analysis of these trade-offs will reveal the relative importance of component attributes.
I will give you an example of how I used conjoint analysis to help me with the CRMOnDemand division at Siebel Systems.
I took over the CRMOnDemand division in early 2004 after returning to the company after a 20 month hiatus. The CRMOnDemand division had been created by Tom Siebel to go after Salesforce.com and the SMB market – a market Siebel hadn’t really participated in until that point.
The CRMOnDemand division had two products to offer: UpShot’s “on demand” CRM products as well as our own internally-developed ”on demand” CRM products (Note: Upshot was a SaaS-based CRM provider that Siebel acquired to gain access to its personnel who had demonstrated they knew how to compete against Salesforce in the “on demand” market).
Unfortunately, the CRMOnDemand division had been struggling since its initial launch 6 months prior to my return and had achieved very little traction with customers and Siebel’s own internal sales organization.
In my first weeks, I sat down with the product, marketing and sales organizations and listened to what the teams thought about UpShot v our internally-developed on demand product, key product features, market positioning, sales strategy, etc. As a result, it didn’t surprise me why we were getting our clock cleaned; we were competing against a strong competitor in its market of strength with a confusing 2-product, ”me, too” message and we were primarily using Siebel’s enterprise sales organization to go after small (SMB) accounts.
I decided to engage a small research firm (Incyte Group) to help us reach out to prospects and customers to better understand how they perceived our “on demand” products, pricing and messages.
From these surveys, we captured a significant amount of data that drove our conjoint analysis. We were able to identify many different issues that were not necessarily obvious going into the study. This data enabled us to quantitatively understand specifically what our engineers should be building, what our marketers should be saying and what our sales organization should be selling.
Consequently, the long and heated debates inside Siebel changed from subjective opinons regarding what should we build, how should we price it, how we should sell it, etc. to instead focusing on solving all the issues surfaced from the surveys. Engineering and Products were now working in alignment. Sales was confident we were building the right product and could sell with confidence. Marketing had a solid messaging platform to work from. And, I personally felt I had the data to show Siebel’s senior executive staff and the Board what we needed to do in order to win in the market.
The result: in 18 months, from relatively little revenues, we were able to grow the organization into an $80M annual bookings business.
While the study certainly wasn’t cheap (it took about 4 months and $100,000+ ), I think about how much it would have cost us had we not done it at all. And, today, with my own early stage start ups, I consider the risk associated with not doing conjoint analysis; how much time/capital will we spend if we get the product, market, pricing, go to market model wrong?
I recently read an interesting article on conjoint analysis by Brett Jarvis at Sawtooth Consulting. I think he makes a powerful case for why each of us involved in developing and/or investing in new product offerings – SaaS or otherwise – would be well served by using conjoint analysis to verify and/or refute our plans.
So, the next time you are faced with a critical product, pricing, messaging, go to market decision, rather than relying solely upon ”gut feel”, I would suggest you initiate a little conjoint analysis. It doesn’t have to be perfect, take a long time, or a lot of money – and, there are a lot of small consulting firms that can help you do it. I think you will find it illuminating, clarifying, uniting and it might well be one of the single most important decisions you can make as a start up.
You must be logged in to reply to this topic.