It is often hard to know what sort of additional services customers will be interested in. Might they be interested in:
- a yearly subscription instead of a one-off payment?
- hosting their own server?
- paying extra for 24 hour support?
- a port of your product to Mac OS X?
You can implement the new service and then offer it to customers. But this can be a huge waste of time and money if it turns out nobody wants it. An alternative approach is to borrow the idea of “Lazy instantiation” from programming (also called RAII – Resource Acquisition Is Initialization).
Programs need to initialise various system resources, such as databases, files and hardware devices. It is generally considered good practice to only initialise these resources as they are needed. This is called “lazy instantiation” and results in faster start-up times and no wasteful initialisation of resources that turn out not to be needed. For example in C++ (glossing over various details of cost, smart pointers, copy constructors, error handling etc to keep the example code simple):
So we can only access the resource by calling MyClass:getResource(), it will get initialised on first use and it will be cleaned up when MyClass goes out of scope. This much more elegant, efficient and less error prone than always initialising the resource at start-up or adding lots of checks throughout the code to see if the resource is already initialised.
A similar approach can be applied to marketing. For example, instead of spending days sorting out the intricacies of subscription payments, you just add the following to your purchase page:
Please email support@acme.com if you are interested in purchasing an annual subscription instead of making a one-off payment.
This will take you a few minutes. If someone emails you that they would prefer a subscription you reply along the lines of:
Thank you for your interest in purchasing Acme server via an annual subscription. We are currently assessing the commercial viability of a subscription approach. We will contact you if and when we decide to make Acme server available through annual subscription. But, for now, you can only purchase Acme server through a one-off payment, as detailed on our purchase page. … etc
If you get enough interest you go ahead and do the work to implement subscription payments. If you don’t – well, you didn’t waste much time on it.
MyClass::MyClass()
{
myResource = NULL;
}
Successful Software 
And your customer gets annoyed. Everybody wins!
In theory this is pretty good.
How do you find out if you lost a sale over it? For instance, what if for every 1 person who actually e-mailed you, you lost 5 people at your ‘pricing’ page who wouldn’t?
Might it be a better idea to have a ‘Yearly Subscription’ button, that when clicked, hovered, whatever’d makes some track-able request that has the same message? Like fire a tool-tip that says “we’re looking into this, if you’re _really_ interested, send us an e-mail and we’ll keep you updated”; and also fire a call to your server that says “someone’s interested” and if that someone doesn’t also turn into a sale, you know you lost a client over that feature. To me that’s more valuable than the interest in options, because while many may prefer something that way, I need to know what they demand.
Shoot, why even build a software product at all? Just mock up a few screens, call it “version 3”, and then respond with “we’re thinking about it REALLY hard” when people click on the “buy now” link.
Reminds me of the trick to do google adwords for a software you think you might develop in future, just to see if people are interested.
Sorry Andy. I enjoy your posts and typically agree with your points of view and ideas. But I have to disagree with you on this one. I think the risk of upsetting customers is too great. Feels too much like “just kidding” prank:
hey you want this, e-mail us and its yours… nah, just kidding. But we might have it someday.”
If I was on the receiving end of such a marketing tactic, I wouldn’t be coming back and would move on to another vendor.
Plus you may now have a customer that does not purchase your product, instead decides to wait for the annual subscription… or at least waits to see if you ever offer it. Meanwhile, you’ve lost the sale.
Just my ever so humble opinion.
But I don’t think that RAII is at all the same thing as Lazy Instantiation.
If I’m understanding the MyClass example correctly, it lazily creates the resource it exposes through getResource(), but it may not follow RAII, since acquiring a MyClass object doesn’t fully initialize every resource it (could) need.
@vgable
I re-read Sutter and Alexandrescu’s ‘C++ coding standards’ and you are quite right. RAII often uses lazy instantiation, but they aren’t the same thing. If I added a call to getResource() in the example constructor then it would also be using RAII. Thanks for the correction.
I feel it would be better to say upfront that the subscription is not ready.
Instead “if you want a subscription email us” (at which point users would be sure they WILL get the subscription if they emailed) say “we’re also working on subscription model, feel free to email us your suggestions” (where it’s clear that the subscriptions are NOT ready yet, but input is valuable).
Also, I agree that email is an extra hop. Some kind of Ajax form would yield a higher rate of response, I think.
Why not just put a poll on the page that asks people if they are interested. Then you would get the same results, without making the customer annoyed.
Pingback: tekBlues » Blog Archive » The wonders of lazy instantiation marketing
Pingback: Lessons learned from 13 failed software products « Successful Software
The biggest issue is thread safety. Without a good system for synchronizing access to getResource(), you’re running the risk of developing the same product multiple times.
Pingback: links for 2010-05-27 « Daniel Harrison's Personal Blog
Pingback: Failed Software Launch – Lessons Learned | Software Marketing Secrets