Is Simple Viable In Enterprise Land?

The tradeoff between simplicity and features has been around for ages, but it was hotly debated on the web by two of the most forward thinking software luminaries: Jason Fried and Joel Spolsky.  Their back and forth debate hit a crescendo last year around the time I attended the wonderful Business of Software conference put on by Spolsky.

The general notion is that the 37 Signals crew sees simple designs as not only better for users, but better for the product as well.  Doing less means less code, less bugs, less training and among other things, a more focused clear experience.  They advocate having a real point of view about your application and driving it from your own compass.  Customers can ask for things, and they may get em, but not just because they asked and the tie goes to 37 Signals.

There is a lot to like in this model and I have always been a huge 37 Signals fan.  Through their blog and book, I have learned many new things and validated some things I already figured out.  No doubt they have helped countless others as well.  Incidentally, the same can be said of Joel and his books.  These are smart, experienced people.

Joel and his product FogBugz would of course agree that simple is better.  The issue arises when customers actually want something you don’t provide and they have options.  See in the world of no competition life is easy.  If you are the only car maker and you don’t have cupholders, big deal.  People still need a car and you are the only game in town.  Life is substantially different if you are an email provider who doesn’t allow attachments.  You can be sure your customers are heading elsewhere.

But wait, adding attachments means another icon or label.   More code.  Perhaps a bit of training and potential confusion over how the feature works.  Over time the storage of big files may me performance hit or storage issues (for you or the customer).  What about maximum file sizes?  You have to document that limitation and probably have some code to check and provide error messages.  Should pricing change in this model?  Hmm, this gets complex fast.  Again, simple is so smart because software is so hard.

As you can see the rubber meets the road when you have two things: (1) unmet needs and (2) viable alternatives.  Where there is profit, competition soon shows up.  Whether you like it or not you are being compared.  Even if it doesn’t matter to you, it matters to them.  How do you decide what is a fair price to pay for a bar of soap or a burrito?   You compare.

The trick is to be aware of competition, but not to let it drive you.  I have written on this in the past.  There are always alternatives (sometimes custom coded) and there are always features asked for that you don’t have.

IHMO you cannot ignore either missing features or competition in enterprise software.  However, this does not mean you need to add every feature asked for or copy your competition.  There are better ways, but first, let’s look at the big three drivers of scope issues in big business software: (1) Analysts, (2) Complexity and (3) Stakeholders.

(1) Analysts are paid to add more, ever complex/advanced features to their latest must have list.  Customers read this and ask vendors if they do it.  Vendors need to be positioned well in the latest magic grapefruit so they build away.

(2) This stuff is just complex.  Approvals, workflow, audit trails, internationalization, integration, and more make it tough.  Dealing with all these situations causes complexity.

(3) Very rarely is there one “buyer”.  The “stakeholders”.  Many times cross functional with different ideas on features and priorities.  The less people involved, the easier the decision making, but it just isn’t reality most of the times.  It is why you have countless sales books written about this exact topic.

So what if you take a stand?  You listen to these ideas and politely state “we view payables or opportunity management or recruiting a bit differently”.  “We know what is best”.  “We understand your idea and see that you might think it is important, but we don’t think it fits with our perspective”.  “We like our product as it is and we are the experts.”

You can imagine how that would go with the sales team, or the analyst relations crew, or your own management.  Why?  Because saying “no” is the death of the sale. The secret is to make sure that saying “yes” isn’t the death of the product experience.

The reason this fascinates me is that I see both sides of the argument as valid having built and run an internal social network for a number of years and having run product teams in the past.  If you go ultra simple you inevitably limit your own business.  If you go for the checkbox approach you get a very difficult to use product that looks good on an RFP.

Additionally, you end up creating a place for small competition who does one thing really well to come in.  Incidentally, pride comes in as well.  No one is proud of a product they have to apologize for – this has to be avoided as well.

Like most things in life, black and white views are great for marketing, but nothing is ever that simple.  Here is where I ended up (doesn’t mean it is right, just my latest thought).

1. Cut Corners (cases): Make a feature work hard to be in a release.  It should be something customers really need and something you agree with as a product manager.  I have seen way too many things in products because someone, somewhere said something.  This cannot happen.  Any chance of simple ends with that type of process.  This is your first gate.

2. Think holistically. Once something makes it into scope you now need to think about both design of the feature and impact on the system (most ignore this part).  The real issue with new features is when it messes up something else.  You have to look at the whole product and be willing to change things dramatically if need be.  Otherwise you’ll have a confusing house of cards.  Done right, a new feature may even add simplicity if it replaces something that was not quite right beforehand.  Look for these opportunities.

3. Focus on Goals not Features. Users love to provide feedback in terms of features.  The key is to listen to the intent. The problem. What are they trying to do?  Users are not the best people to design your feature, you are.  They are however very important and you need to listen.  So listen, but when you understand the need see how you can best meet it.  It may be they nailed it, but there may also be a more appropriate answer.  Done well, this solves the sales issue.  Being a product manager does not mean you are collecting requests unvetted.

4. SKU v Over Bloat. I favor new skus over a bigger single product.  More features leads to more code that is harder to move and difficult to market.  Try explaining to a friend the features of outlook or excel.  Now explain the key features of a to do list or twitter.  Different conversations.

The art is finding the natural break points.  The joints.  When you do, make sure they work well together.  I like point solutions that naturally fit.  I think it is a model that scales both in simplicity and sales.  Incidentally, the iphone app model so popular now is playing this game.

The tough thing is that there are some really successful products (like Outlook) which do a ton of stuff.  Wouldn’t we all like to fail like that?  Then we look at Twitter and think how simple it is and how well they have done.  But I think pointing to these high water marks is less than helpful.  Correlation is not causation.  Microsoft wins for a lot of reasons and maybe those reasons just overpower the feature bloat via brute force.  In fact MSFT has recognized their challenges here with their UI revamp recently in Office.  And Twitter works, but in that “buying cycle” there is no rfp, no analyst, no stakeholders – just you.  You like it, use it.  If tomorrow you hate it, stop using it.  Life behind the firewall is just not that idyllic.

In the end, I find both arguments have valid points.  Simple is smart for a lot of reasons and should be seen as a design goal.  Making sales easy is also the right answer or else you won’t have much of a future.  Being able to say “yes” to customers is a wonderful feeling, but there is a balance here that should not be ignored over a certain dogma.  The art is in the middle and it is why being a product manager is so fun.

Enterprise software can stand for something.  It can have an appropriately simple and elegant user experience.  It can in fact have users who delight in its use and it can be explained clearly to the target users.  Too often we give ourselves a free pass in these areas and this is the biggest challenge – our own standards and a sense that good enough is definitely not good enough should be our guide.

Paul