Thursday, November 21, 2024
HomeLead GenEnterprise Software Pilots in a Social Age

Enterprise Software Pilots in a Social Age

I’ve been thinking about sales processes and specifically how they should change as the types of solutions we are selling into enterprises change.  For example, the traditional first step to an enterprise software deployment (and the near to last step in the sales process) would be to do a controlled customer pilot.  Sometimes these are free and sometimes they are paid for but almost always they involve rolling the product out to a small set of users and tracking a set of pre-defined success metrics.  If the pilot meets the goals, the next stage is to move the product into broad production use.

Should enterprise software pilots change or stay the same as enterprise software makes use of more social or collaborative technologies?  Michael Idinopulos has a great post on the Social Text Blog that makes a very good argument that for Enterprise 2.0 applications, it makes sense to skip the pilot.  In that post he makes the point that the business tasks enabled by traditional enterprise software (transfer funds, purchase products, track inventory were his examples) do not vary with the number of users on the system.  He then makes the argument that Enterprise 2.0 applications are very different because they are more “interaction” based rather than “transaction” based.  He states:

Interactions and transactions have completely different scale
economics. When we use Enterprise 2.0, we’re not transacting with a
system; we’re interacting with other people. An interaction is a
connection between two or more nodes in a network. And as Metcalf’s Law
famously states, the more people there are in that network, the more
interactions each individual can have with his or her peers, and the
more value that individual derives from participation in the network.

Regardless of how you define an “Enterprise 2.0” application, I believe we are now moving into an age of collaboration and communications-enhanced business processes.  As our customer management and supply chain processes become more connected and start to really support collaboration, it would seem to me that our traditional model of doing a pilot has to change too.

I don’t believe that enterprises are ready to do major deployments without a pilot stage but maybe what we need is a new type of pilot that allows enterprises to contain the risks associated with a broad deployment while letting the user-base form organically enough to expose the range of ways that people will collaborate within a broad population. Ultimately this may result in doing pilots where the restriction is more around advanced functionaility and less around restrictions on numbers of users.

First time reader?  Subscribe or follow me on Twitter or Friendfeed

RELATED ARTICLES

14 COMMENTS

  1. Interesting post. I agree we’re probably moving in that direction.
    The problem is that the effort required on the part of the vendor to do an extremely broad deployment as a “pilot” is going to mean that either the customer pays big $$’s to do it or the vendor eats big $$’s to do it. Someone will have to take on the additional risk.
    Justin

  2. Hi Justin,
    Thanks for the comment. In a traditional deployment you’re right, the burden on either the customer or the vendor is going to go up. If it’s a SaaS deployment, I’m not sure the scale matters as much as long as you can turn on/off features.
    April

  3. Good post April. What’s worked for me in the past is to engage customers as early in the process as possible. This can be at the product level or at the feature level – whatever you feel requires customer engagement. If you can get them into the process at the concept stage and move them through storyboards, demos, hands-on, etc. then the odds of meeting the success metrics at the end of the project are pretty good – thus eliminating the pilot. The key is to have a network of customers willing to be engaged throughout the process and good two-way communication with them.
    Other benefits as a result of this are that (a) customers are familiar with the new/improved feature/product, thus reducing the training requirements, and (b) reference customers may be quicker to acquire because they’ve (hopefully) fallen in love with what you’re delivering to them.

  4. Hi Peter,
    That’s a good point – no vendor wants to do a pilot so if you can get them closed without one, more power to you. For certain kinds of enterprise software though, I don’t see it being avoided. CRM being the big example in my head.
    Thanks for the comment.
    April

  5. I actually think the great thing about a trial for an Enterprise 2.0 software product is that to be successful, it **needs** the involvement of the wider community that will contribute content.
    While time consuming to set up and get the community to be involved, if the product actually adds value to that community, the community will be up in arms when the trial ends and access to the software is removed- what more compelling reason is there to buy?

  6. LOL – yes that IS off-topic! I’d need to spend more time thinking about it and frankly, I haven’t spent enough time on Squidoo to have an opinion. On the surface it would seem like an interesting why for brands to get engaged but I agree with TechCrunch that the price point seems awfully high. I will add it to my list of possible future blog topics…;-)
    April

  7. I totally agree with you that from a customer point of view there is great value in doing a broad scale “pilot”. The question I keep coming back to is whether or not you can get away from skipping the pilot altogether. Maybe we just need a new word for “pilot” in that case and I really like your word for it – it really is a “trial” at that point more than a pilot. In my mind there’s a stronger commitment from the customer in a trial than there is in a pilot.
    Thanks for the comment!
    April

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments

Ashawndra Edwards on Choosing a New Vertical Market
marcelene28 on Startup Marketing Podcast
Name: Johanna on How to Name Your Startup
Samuel Riksfjord on A Value Proposition Worksheet
Vivian Dilberd on Startup Marketing 101
Krissie Thornton on A Value Proposition Worksheet
Krissie Thornton on A Value Proposition Worksheet
David Locke on Startup Marketing Vs. Art
Justin Graf on Startup Marketing Vs. Art
Randomarketer on Startup Marketing Vs. Art
i2i-management.com on 3 Startup Branding Mistakes
Tim Johnson on Startup Messaging
Paul Bevan on Vertical Marketing 101
Tim Johnson on Vertical Marketing 101
Tim Johnson on Vertical Marketing 101
Alex Nimson on Vertical Marketing 101
Tim Johnson on Influencers Suck
Tim Johnson on Influencers Suck
Tim Johnson on Influencers Suck
Faisal on Influencers Suck
Kerry on Influencers Suck
Jonathan Beech on Influencers Suck
Martin Stimp on A New Marketing Framework
Tim Johnson on A New Marketing Framework
Sam Title on Press/Media Pages 101
Jonathan Beech on How to Name Your Startup
Tim Johnson on How to Name Your Startup
Johnson Choy on Startup Marketing Podcast
Andy Donovan on Startup Marketing Podcast
Maggie Jones on Startup Marketing Podcast
Joseph Dill on Startup Launches RIP
mrsprpro on Startup Launches RIP
topsy_top20k on Startup Launches RIP
JonMaster on Startup Marketing 101
topsy_top20k on Startup Marketing 101
Tony Wilson on I’m the #1 PM Blogger!
Jason Serres on I’m the #1 PM Blogger!
My boss is a Flintstone on Collateral Damage: Building a Content Plan
Steve Matthews on Spam is not Marketing
Mara Krieps on Finding First Customers
Carole-Ann Matignon on ProductCamp NYC
Adam Bullied on ProductCamp NYC
Andreas on ProductCamp NYC
Stewart Rogers on ProductCamp NYC
Roger L. Cauvin on The Art of the Customer Quote
April Dunford on Making it Real
April Dunford on Marketing Penalty Cards
April Dunford on Unhappy Customers Complain