How these objections work depend very strongly on the nature of the startup. It's something I'm very concerned about. My own work is going to be chock full of sensitive customer data about their system configurations (it could be described as a DevOps analytics tool). Privacy and security will be huge concerns for customers. I'm starting with SaaS, but I fully expect pressure from some customers to provide a COTS version for internal deployment, due to "security".<p>I don't want to do COTS at first because I want the ability to iterate quickly for new features and bug fixing. I can do that with SaaS, but enterprise COTS is the land of programs that haven't been updated in <i>years</i>. I don't want to put myself in a position of supporting antique versions of the code, even if it comes with lucrative support contracts, because it's a drag in other ways. So my answer to customers who can't deal with SaaS security in the short run is probably going to be "Sorry", and my efforts focused on pleasing the customers who are comfortable with a SaaS solution.<p>On the other hand, I'm not even in beta yet. I may well have to eat those words in fairly short order, if that's what it takes for survival and growth a year from now.<p>That all said, I've put a lot of thought into addressing customer objections about their data, and a lot of it is baked right into the architecture.
I've also heard, "How do we know you won't sell the company and have the product wither on the vine."<p>This is why startups tend to deal with startups, and Crossing the Chasm [0] is so difficult.<p>[0] <a href="http://en.wikipedia.org/wiki/Crossing_the_Chasm" rel="nofollow">http://en.wikipedia.org/wiki/Crossing_the_Chasm</a>
It's a great set of questions, and a set we hear constantly.<p>To slightly extend, there's also the question of "Will you raise your pricing for the same offering at any point?".<p>Plus, in addition to can I get my data back, "will it be of any use to me when I do get it back?". i.e. is it exported to some standard format, will I get enough source code to run it long enough to build (either myself or collectively) some way to get the information (as opposed to the data) out?<p>"Can I get my data back" actually figured in our architecture prior to building, that's why we went for bring-your-own-storage. Google Drive and Dropbox both now provide direct JavaScript on the client to their servers functionality, the data doesn't need to go your servers any more for storage (only for processing, should you need that).<p>Our SaaS isn't our main, or even a pay-for, product, we heard this constantly. We do now have a set of answers, but it's taken a good couple of years to put them together in a way that satisfies people.
I'm unsure what to make of this post.<p>> Your data stays with you: It is scary enough to hand over your company’s most precious data - your customer database - to a large company with all the data break-ins today. But with a start-up, the risks magnify, as there is the added worry that the start-up will fail, or will be acquired. What happens to your data then?<p>> We never ask our customers to provide us with their data. We ask our customers for descriptions of their products and descriptions of their customer’s pain points. That information is enough to provide a continuous stream of targeted leads to our customers.<p>Considering that the "data" being collected & sold by Compile doesn't belong to its "customers", where is the question of trust? Also, why would any customers who are <i>buying</i> leads from you ever share <i>their</i> customer data with you?<p>Or maybe I'm missing something here?<p>[0]: <a href="https://www.compile.com/technology/" rel="nofollow">https://www.compile.com/technology/</a>
Clicking on your logo in the blog should go to your main site. If not, please add a link to your main site. It's very difficult to navigate as most in-app browsers don't have a url bar.
As a startup, you should also use this information to help decide your company's own risk/reward ratio of pursuing a customer. I worked in a B2B startup, and when we tried to engage larger businesses we ran up against this "trust" issue. Every time, we spent lots of time and money talking with them and came away with nothing.
The questions are setup for a generic situation which I like, but the answer for #2 seems to be a single solution. What do you do in the case that you need customer data as part of your product (Say the product was more traditional CRM).<p>Could have been a good post but they cut to the commercial message too soon.