Managing Consumer vs. Enterprise Products Part I

Written by Ariel Seidman on November 24th, 2008

After spending four years at Siebel and now approaching my 4.5 year anniversary at Yahoo I am asked relatively frequently how does managing enterprise vs. consumer software products differ.   It was a question I first asked myself when I decided to leave Siebel for Yahoo! and now it’s part of my arsenal of interview questions.  Beyond the obvious points – enterprise customers pay millions while consumers usually pay nothing – there are more interesting answers to this question that deserve exploration.

Let’s start with a simple question – how do you know what to build?

In the enterprise world if you want to know what to build jump on an airplane and visit five or six telecom companies of various sizes from British Telecom (BT) to Bezek Telecom and you will quickly see that the problems that BT and Bezek face in order management, billing, or ticketing are similar.  If you can solve it for Bezek and scale it then you have a product you can sell.  While there is a tremendous amount of work to build, sell, customize, deploy, and scale these enterprise solutions identifying the correct problem to solve should not be the risky part of the endeavor.

On the consumer side determining what to build is the risky. Even the best product managers and designers with adept consumer touch will get it wrong more often than not.  If each new project requires the resources of a reasonably well funded team and only one out of ten are successful then you are operating a business with VC model economics.  Most consumer software companies (even growth companies like a Google) are not in the VC business for good reason — they have shareholders that expect consistent returns. Therefore building out processes and platforms that enable you to experiment quickly and efficiently is vital. 

  • Build: Plant a few seeds with a some features at a reasonably low development cost.  
  • Test: Bucket test these features for a reasonable amount of time to allow a signal to form – patience pays as users often have to discover and learn new features.  
  • Analyze + Decide: Then decide to double-down or dump.  It make take a few iterations before you can make a definitive double-down or dump decision, but each iteration should provide signals that inform that ultimate decision.

The nuts of bolts of getting these experimental systems working is where much of the product magic will come from.  Assuming the product is gaining traction – what features should be prioritized.  As products in the Internet consumer space start gaining traction they generate goldmine data sets.  Coming from the enterprise software where the major software providers (Oracle and SAP) don’t see much of the data their customer generate (albeit this is changing with salesforce.com and NetSuite) there is a temptation to allow these data-sets to drive all product decisions. Falling to this temptation will ultimately lead you to a very stale product.   Incremental features designed to address specific metrics will impress when viewed via a narrow lens but the product will quickly become a series of tactics with no larger vision.

Leave a Comment