Development cycles are spinning out of control

Software development used to be measured in months——now it is measured in weeks, days, even hours. This rapid acceleration has sparked some real tension between five different constituents with five different sets of objectives and expectations that no longer work in sync: software developers, customers, prospects, customer service and marketing. Note: I always leave sales out of these discussions. Why? Sales ALWAYS wants more functionality; they always have a white whale out there, one that would buy a million dollars worth of product TODAY if only we had "X" feature. 

(Not that there’s anything wrong with that. It's Sales. And, like the scorpion that stung the frog carrying him across the river, this is something they can’t help themselves from doing. It’s their nature.)

Software developers are essentially a conservative lot that have been turned on their collective heads by market forces and ready access to massive compute power. Even as recently as the days of client/server computing, most software developers were reasonably conservative. They stuck with an operating system that they knew and understood (I'm looking at you, Windows XP) and they tried to pace out software releases along an annual release schedule. 

They could do so because 1) the market did not demand a faster pace; and 2) they lacked the resources to move any faster. Sure, your large commercial software houses (Microsoft, Oracle, SAP) had access to test and Q/A platforms, as well as gobs and gobs of development computers. However, most in-house development teams lacked these specialized resources. So, they'd often be testing on their desktop computers and deploying directly to production. In such a world you had to be really careful about your software releases. 

So, by necessity, you simply deployed less often.  

Customers tended to be comfortable with this slower paced process.  They had a devil of a time getting to a stable, working system, so they were more than happy to delay the pain of upgrading. The real enemy was the duopoly of Marketing and prospects. 

Part of Marketing's job is to stay ahead of the competition and to carve out a comfortable market segment for the company, as well as to create unique partnerships with the important vendors in your overall market. This means that Marketing is constantly on the hunt for new features and new platforms.  

You are probably hearing this right now, as your marketing team insists that you need to get onto iOS 8 as fast as humanly possible in light of Apple’s newly announced iPhone 6.    

Prospects operate in a similar fashion. Since they have not yet purchased your product, or gone through the pain of an implementation, they tend to be biased towards new features. Thus, in order to close the deal, they want developers to add a bunch of features, or make customizations that are unique to them. Unfortunately, if they are bringing enough dollars to the table, their voice is going to carry a lot of weight. 

If you are software company in this spot, I'd suggest that you re-read "Crossing the Chasm" for a fulsome understanding of the long term risks of building new features across market segments.  

So where does that leave us today? Marketing and prospects, the world is your oyster. Engineering, Customer Service and customers, well…  

On the one hand, we now have ready access to tons of computing power, storage and networking. There is simply no excuse for an engineering team, no matter how small, not to have separate development, test, and production platforms at their disposal. This point probably deserves a discussion all its own. For now, let's just all agree that it is much easier to get access to all of the computing power that you need at a relatively modest cost. This easy access to hardware has come at a great cost: the proliferation of platforms, databases, browsers, mobile operating systems, frameworks, libraries and languages. This causes massive instability for developers and customers. Developers have their hands full, juggling feature development for their own software with the demands generated by marketing, prospects and, to a lesser extent, customers.    

Adding to this problem, every change by one of THEIR suppliers, as per the list above, requires code changes and feature changes (at least potentially). And those suppliers have their OWN pressures from marketing, prospects and customers.    

So who suffers? 

Developers, customers and Customer Service are the biggest losers in this game. The market is conspiring against them. 

Platform instability can put massive pressure on developers. Customers get frustrated because things simply "stop working". Sure, you can post a big sign on your web site that says that your software isn't compatible with iOS 8. That's not stopping your customers from updating. In fact, some OTHER product that they rely on might just REQUIRE them to upgrade. So they get angry and call Customer Service, who soon gets overwhelmed with similarly frustrated customers. And just how is customer service supposed to keep up? It’s a given that they need to thoroughly understand their own product, but just how many third-party components do they need to master in order to stay on top of customer problems? There simply aren't enough hours in the day. 

So what can we do? 

Well, it take two to tango. And your dance card just filled up. 

CEO:  

You need to be running the show. Bite the bullet and scale back the number of different platforms and features. Be realistic about your timelines. If you want to add something, then you've got to cut something from the project plan over a given block of time. Understand that you can't just hire additional resources in the short-term and "jam it in."  

Engineering:  

I know that you want use the latest and greatest NoSQL database for the new product. Take a deep breath and think about how you are going to support this from a platform and operations perspective. Simplify, boys and girls, simplify.  

Marketing:  

Take a hard look at the features and functions that you really need to be competitive. A/B testing works great with marketing campaigns, but it is a living hell for developers to add functionality that does not move the needle.  

Prospects:  

When you are pushing hard for that custom feature, remember: soon YOU will be the customer that is getting frustrated by changes that you didn't ask for. Think hard about whether you REALLY need that customization.  

Customers:  

The following piece of advice is going to irk you like mad: I don't care. 

Yes, you paid good money for a product that isn't working. Yes, you are frustrated that customer service can't magically diagnose and fix your problem. I get it. Now stop crying and get to work. If you want your problem solved then you are going to have to act like you are part of the team and do as much digging as you can to HELP customer service diagnose and fix your problem. Google it, for heaven's sake. Take meaningful screen shots. And, if it's all too much for you, then consider dropping the product and going with another vendor.  

Customer Service:  

You have the toughest job. But if I can give you one simple piece of advice, this would be it: Try to understand your customer’s sophistication level. Don't ask them if they tried rebooting if they come armed with screen shots and database traces when they call.  

This is going to get worse before it gets better folks.

We need pigs not chickens

The PE Funcast is a team of readers. We fly through books. Lots of books.  Not just business books and technical books, but novels and short stories, newspapers, even some comic books—-We highly recommend Usagi YoJimbo.  Urban legend has it that Warren Buffet and his longtime business partner, Charlie Munger, try to read an hour each day and that’s as good a reason as any to pick up a book.  We read because we love to and we read because there are tons of people out there that know more than we do about lots of different things.  It's the same reason that we listen to lots of podcasts too.  We read on planes and trains, and we listen to podcasts in cars.  We get lots of interesting ideas from reading, and this post is one of them.   

I recently finished Duff McDonald's The Firm: The Story of McKinsey.  The book got mostly positive reviews on Amazon--3.9 stars out of 5 as of this writing—-but it was the subject that caught my eye.  McKinsey is considered to be "the" name in strategic consulting, an industry that is very intertwined with private equity. Whether every vignette in McDonald's book is true or not isn't relative to this piece.  It was enjoyable to read and provided me some fascinating insight into McKinsey and their ilk, and into the strategic consulting business.     

McKinsey is famous for a particular discipline: "Never taking credit" and "Never taking the blame".  They provide strategic advice upon which the client can choose to act or not.  Sometimes their advice was good and sometimes it was bad. (Read the chapter on Enron for more details on the bad advice.) For those of us that live and die in working with smaller companies, the McKinseyites and their kind are, as Phil Connors would say, "a colossal waste of time".  Smaller companies need partners that are as committed to the solution as we are. As the saying goes, "when it comes to breakfast the chicken is involved but the pig is committed".  

We need pigs not chickens.  

I am not saying that smaller companies don't EVER need help with strategic decisions. I'm saying that more often than not they need help EXECUTING on strategic decisions, not getting consultants to MAKE their strategic decisions for them.  

If you read the McKinsey book you will certainly get an appreciation for where they can (and have) added value. Historically it has been very large companies that were hamstrung by indecision or political issues in the "C" suite.  McDonald's book provided a balanced view of McKinsey and their value in this regard. However, at our end of the market we just don't see these same types of problems -- and we certainly don't have the EBITDA to absorb the massive fees that these consultants charge for their services.  McKinsey famously doesn't keep track of hours, and merely presents an invoice that they deem to be "fair" for the work performed.   

We get cold calls from the high-end strategic consulting firms all the time. Some of the biggest, most successful, private equity shops are big users of the McKinseys of the world; some even have their own in-house mini-McKinseys at their disposal. Most strategic consulting groups view private equity groups as a terrific target market: You sell me on how smart you are and I turn around and jam you and your $2500+ per day down the throat of my portfolio companies.  Portfolio company managers will figure it's the cost of having a private equity partner involved in their business, shrug their shoulders and deal with it.   Then your strategic consulting firm bills a bunch of hours, makes a bunch of non-binding recommendations and takes the private equity partners out for a nice golf outing once a year.  

I don't golf. 

C-Suite executives at our companies are rarely at a loss to determine strategy. They are often at a loss for good, effective, tactical consulting resources that can help them to implement their strategy.   And that isn't to say that all strategy consulting is bad.  We get tons of value within our portfolio from Gartner Group technology research, at a price well below the standard daily rate of McKinsey-style consulting.  

Larger corporations have different problems; problems that may be better solved via independent third-party consults like McKinsey.  What makes a problem strategic?  Let's take some examples straight from McDonald's book: CEO succession planning, matrix management of staff, large-scale acquisitions or divestitures, designing sophisticated financial structures or entering entirely new markets.  

We don't have these kinds of problems in our market.  CEO succession planning?  We don't have dozens of divisions with trusted lieutenants that are vying to move up into the big chair.  When we buy a company we are most often buying it from a founder who already has a COO ready to step into the big chair. If they don't, and they don't want to run the day-to-day business anymore, then we are coming to the table partnered with a CEO to run the business post-close.  

Matrix management? We never have a management bench large enough that a single employee is reporting to multiple managers. In fact we are often tasked with recruiting new managers to fill key holes in the team. We need head-hunters, not consultants.  

Our companies make tuck-in acquisitions.  Small competitors or tangential technology pieces that fit into the grander scheme of things.  We aren't looking at large-scale mergers with other billion dollar companies and trying to figure out integration and redundancy plans.  Likewise, we don't have billion dollar divisions that we'd like to spin-off into their own publicly traded entity.    

We do make use of state-of-the-practice financial structures to minimize the tax burden for our selling founders. But we aren't designing sophisticated holding structures and off-balance sheet subsidiaries à la Enron and their ilk.  

If we are entering a new market, we are following a Geoffrey Moore model and moving to a parallel "bowling alley". We don't need help identifying these markets or understanding the concept of "the bowling alley".  

Our companies often need consultant/contractor hybrids.  Folks that are both capable of providing some experienced advice but are also capable of getting their hands dirty; folks who are committed instead of just involved.  We are happy to give you the credit; we just want to get the work done.   

Contractors are people too

If you are a lower middle market company that is implementing a new customer relationship management system (CRM) or enterprise resource planning (ERP) system, chances are pretty good that you are using some third-party consultants.

This holds true beyond the realm of CRM and ERP implementations as you might be using consultants or contractors for some custom software development as well. But it is almost a necessity when you are implementing somebody else's software stack. 

Anytime that you are working with third-party technical contractors there is always room for disagreement.  You can be buried in a sea of change orders; the consultants may lack all of the necessary skills or have communication problems.  Your team's personalities might clash with their personalities.  Each project brings its own sets of unique challenges. 

In my experience, however, there is one problem that ALWAYS crops up in these projects and it's the one problem that most CEOs and Founders least expect.  It's a problem of expectations, specifically the expectation that your consultants are going to work like dogs to get your project done. 

Let me explain. 

In the normal cycle of things your internal technical team probably puts up a fair amount of unpaid overtime.   I've seen the question asked on Quora: "How do I MAKE technical people work overtime?"  It's an idiotic question.  You can't MAKE them.  However, technical people, like me, often work overtime because we truly love what we do.  To us, solving complex technical problems is interesting work.  For example:  I've been up since 3:30 am today working with one of my teams on a software launch. We made the decision to delay the launch until tomorrow at 3:30 am after we uncovered some things in the launch process that we didn't like.  I was working until 11 pm last night along with team, we took a short catnap and then hit it 3:30 am.   I'm cooling my heels, drinking Starbucks and getting ready for our 10 am status call -- so I decided to crank out this post. Is it overtime? Definitely. Do I mind? Definitely not.   

The team and I have been burning the midnight oil for a few weeks now to get past a big launch date.  However, once we get through this process I'll need to make sure that the team dials it back for a few weeks—Go home early, play with the kids, hit the gym, get your car washed, whatever.  The point is that it is vitally important that the team gets some mental rest or they won't be prepared for the next little window of scrambling.  Even if they want to keep scrambling I need to help them help themselves by forcing them to "shift it to glide" for a while. 

So what's the problem here?  The problem, folks, is that you CAN'T work your short-term consultants and contractors like this.  Why you ask?  Because, while your team is catching their breath, your consultants are likely off working at the next company.  This is particularly true for "specialists" that are working on a rotating cycle for several customers at once.   If every one of their customers expects them to go the extra mile each and every day these folks are NEVER going to catch a break.  This leads to contractor burnout, which is why consultants turn over so often.  This in turn means that the next consultant that you get does not have as much experience and you need them to work harder -- it's a vicious circle.  Never mind that these poor folks are staying in a hotel every night, away from their families and pets.  

Side note.  The next person that tells me that traveling for work is glamorous is going to get punched in the schnozz.  End of side note. 

It's a matter of setting expectations—your OWN expectations—and this is a very, very hard thing for most CEOs and Founders to do.  You have a passion for your business and you expect EVERYONE around you to share that passion.  Unfortunately it does not work that way.   

So, what can you do?   

Set your expectations lower.  Your consultants are not going work full tilt week in and week out.  And it does not matter how much their company is charging you a day for their services.  

Plan for the project to cost 30% - 50% more than you've budgeted from a services perspective.  That does not mean that you have to spend that money, but you don't want to run out in the middle of a project.  

Don't focus on the "edge cases".  Edge cases are one-off pieces of functionality or workflow that happen a very small percent of the time, but often require the most effort.  This is a meaty topic; one I'll talk more about in a future post.  For now, think of it this way:  Don't try to cover every single scenario the first time through. Focus on the 80%.  Leave the edge cases in the parking lot.  This is probably the most important suggestion I can make.

Beware of the time/functionality continuum.   You can either commit to a hard and fast date on a technical project, or a specific set of functionality, but never both.   If you HAVE to live with a certain go-live date, then you have to be willing to throw luggage from the plane.  On the other hand, if you HAVE to have a given set of functionality in place for the go-live, then you will likely have to be flexible on the date.  I call this a continuum, because it's never a simple case of black and white.  In particular, this often means being flexible on EDGE CASES. 

Having said all this, we work with plenty of consultants and contractors that go above and beyond the call of duty every day. In fact, we are partnered with Virtusa on a web application porting project right now and the very person that kept me up late last night was the one that got me up early this morning.  Ravi, our onsite resource from Virtusa was the last one to bed and the first one back at his computer today. The moral of the story is,  expect your consultants to be great, just don’t expect them to be you.

Just say "No" to sending out an RFP

In my many years working as a Pre-sales engineer for a variety of enterprise software companies the single biggest waste of my time and effort was answering a request-for-proposal (Yes, the dreaded RFP). I am so jaded from my past experiences with RFPs that I strongly encourage my portfolio companies to refrain from the practice of issuing them entirely.  “Why?” you ask.  Because your garden variety RFP is an unnecessary step comprised of useless information.  

On the one side of things you have an enormous list of unprioritized questions put forth by the buyer. It represents a complete superset of every possible feature and function by every single solitary employee of the company from the CEO on down to the second shift janitor. Everyone wants to have their say in the process, but in most cases their feedback is a waste of time.  You end up asking a bunch of questions that having no actual bearing on your business.  For example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”  

Really?  Do you really need to run the software on all of those platforms?  I SERIOUSLY doubt it. A subset of skilled professionals can whittle down a set of products to very short list of best-fit solutions with nothing more than a very concise list of requirements put down in order of priority.  If you must ask, do it that way. Period.   

On the other side of the equation you have the vendor.  As a former representative for a number of vendors I am uniquely qualified to let you in on a little secret.  And here it is.   As a pre-sales engineer for EVERY vendor that I ever worked for, my job was to figure out a way to answer "YES" to every single question on an RFP — regardless of how much I had to stretch the truth to do so.  Here's an example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”

“Yes, by running Parallels or VMWare you can run our software on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, and IBM eSeries.”  

What this means is that you can install Parallels and a copy of Windows and then run the software under Windows 7.  So the real answer is "No, we do not run on all of these platforms, we only run on Windows 7.” I wasn't lying in my answer, but I was certainly massaging the truth.  Every single RPF is RIDDLED with weasly answers just like this.  

And why is that, you ask?  It's because the RFP itself is riddled with a million questions that may or may not be critical to the success of the product in your environment.   If you are going to ask me a bunch of inane questions that may or may not mean anything then I am going to turn around and give you back a bunch of vaguely worded answers that allow me to answer "YES" to every question.  As a rep, my goal is to get past the RFP stage and into the face-to-face meeting stage where the REAL selling can begin. Government agencies and purchasing agents at large companies are the kings of issuing RFPs.  And this is EXACTLY why I like working with middle-market companies on the buy side of the equation.   

Let's say that you are a company with $55 million in sales and $10 million of EBITDA looking to move off of QuickBooks and onto a bigger and new accounting platform.  Do you really think that you are going to make a better buying decision by putting together a 500-question RFP and sending it out to every accounting software vendor that comes up when you Google "accounting software"?  You won't.   

Get a small team of people led by your CFO in a room and put together a short list of requirements in priority order:   

- What platform do you want to run it on? (SAAS?  On premises?  Windows? Linux?) 
- What Accounting functions do you need to support (G/L, A/R, A/P, Purchasing, Invoicing)? 
- Budget — how much do you have to spend on licenses and implementation? 
- Lists of any unique functions/features.  

For example, maybe you need to support both English and simplified Chinese for data entry.  You can get the whole thing down to a few simple sheets of paper.  With some simple Googling and conversation amongst your team you'll come up with a list of 3-4 likely candidates in no time.  Call up the vendors, get a demo, and ask to SEE them demonstrate the few unique requirements that are specific to your situation. Get multiple quotes and talk to some references.  Pick one and negotiate a deal.  I guarantee you that these steps will work better and faster than any RFP-based process — and you will save yourself a TON of time.

The "Out-Of-Box Experience" and the Mobile Market

In the old days, companies used to ship you their software in a big square box.  Actually, when I started, the software delivery guys from Digital Equipment would hand-carry the magnetic tapes to you. By the time we reached the PC/Server era, your software would arrive in a massive mailer.  Inside that Costco-sized box was a manual and a compact disk (…okay, okay, it was mostly floppy disks). It wasn't always easy to get a trial version of software because the company actually incurred some real costs in packing and shipping the materials to you. As a consumer, you had to put in work too. You had to march through a phalanx of sales reps and sales engineers in order to get your trial copy.  It was a far cry from today's world, in which you just download the ZIP/EXE/DMG/TAR file from the web site and away you go.    

Once your trial arrived, you'd open the box, install the software and fire it up. We called the period from the opening of the box through the installation, all the way to the first hour (or so) of using the software, by the phrase the "out-of-box experience".  Yes, I know it SOUNDS like some hippy-trippy saying about you becoming one with the cosmos—or an overused company retreat exercise—but that's not what it meant.  When you mentioned the "OBE" you were talking about your initial impressions of the product and the likelihood that you would purchase it.  

If the product put a smile on your face during the installation and first-use, it had a "positive" OBE. Products that were difficult to install, were difficult to use at first, or were just plain ugly to look at (bad colors, bad fonts, busy screens) were said to have a "negative" OBE.  After all the work that went into just getting the trial software into a customer’s hands, a bad OBE could be a real killer.

Having a bad OBE can kill you in today's universe too.  

These days, expectations are higher particularly in the mobile apps sphere. Serving up a lousy web page is a bad idea, but it's not necessarily fatal. It does not cost you much to surf to a lousy web page; you don’t actually have to download or install anything. Will you go back to a bad web site? Maybe. 

Mobile apps are a different beast altogether. I tend to get mightily perturbed when I go to the trouble of downloading and installing a mobile app and it's terrible. I get particularly angry if I also have to create some sort of web account to go along with it on the back end. A bad OBE means that I might delete the app in question and never try it again. 

So the question becomes, do you risk putting out a mobile product with a clunky OBE in the middle market? Despite my previous remarks, my answer is a guarded YES.  If you are technology company in the middle market with solid customers in a defined niche, it is a bigger risk to get to the market late.  Go early and iterate, rather than wait until your app is “perfect”. Your customers are with you anyway and, while they might not love a clunky OBE, they will live with it. They are likely to be more unsettled by the lack of a product on your part, particularly if your competitors have a mobile product in play.  

However, if your FIRST product is a mobile product then my advice is the opposite.  Your OBE had better be killer or you'll get deleted and never re-added.  

Hire developers that understand mobile (iOS, Android) and your first product will be more likely to have a decent OBE, even if the software lacks a ton of functionality. Shoot for a minimum of features, make it run fast and keep it as error-free as possible. Apps with tons of features tend to have lots more errors that jump out at the user. Since you aren't likely producing a game app, your mobile software will need to connect to your backend systems--upping the potential for errors (limited signal coverage, data synchronization issues, etc). A fairly simple app, with clean graphics, that runs fast and relatively error-free is a good start.

We may be years removed from the literal box, but the OBE is still very relevant. The appearance and ease of use of your mobile product (or website, for that matter) communicates its quality to your customer. You are asking them to expend their time and effort to acquire and install your app--or worse, to discover that it doesn’t exist--so it’s up to you to make that effort worthwhile.