SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for the ‘saas’ Category

It’s Time to Tax the Robots, Not the People

Posted by Bob Warfield on May 20, 2015

I read a fascinating piece on the economic impact self-driving cars and trucks will have and it’s not a pretty sight.  A quick glance at this map showing the most common job in each state makes it clear:

JobsByState

The most common job in each state in 2014…

You don’t have to study the map very long to conclude automating truck driving away as a way of life is going to have a profound effect on our economy.  When you consider that truck drivers make an average of $40,000 a year, which is more than almost half of all tax payers, and you add in all the jobs related to the truck driving industry, it may be one of the biggest impacts we see in our lifetimes.

Can this really happen?  When will it happen?

The article goes on to show that the world’s first driverless truck has already hit the road in Nevada, and was built by Mercedes Benz.  They present estimates from a variety of sources that suggest somewhere between 2020 and 2030 completely autonomous trucks will begin to take over by storm.  Google has demonstrated self-driving vehicles and Teslas have the capability already built in to cars already on the road.

All of the proponents of driverless vehicles are loudly trumpeting that the vehicles are safer, cheaper, and more fuel efficient.  But what they’re not considering is the impact on the economy.  What will all the truck drivers that lose their jobs do to earn a living?  Who will benefit?

As it stands, large organizations that can afford to buy driverless vehicles will be the beneficiaries and nobody has a plan for what will happen to the truck drivers.

This looks like the third tranche of job-destroying disruption.  The other two–the destruction of Retail jobs first by firms like Walmart and later by the Internet, and the Offshoring and Automation of Manufacturing jobs, are well underway.  The economy is still limping in the wake of the Great Recession, and it’s tough to say we’re out of the woods except for the most dyed in the wool political supporters who want to claim victory for their side.  Meanwhile, Main Street America is braced and wondering what the next big shock to the Middle Class will be.

The article argues its time to get some sort of Basic Income plan in place to provide a Safety Net.  Safety Nets are fine, but I want to know how the Middle Class can do better than a Safety Net.  A vibrant Middle Class does not sit at home waiting for its next Government Safety Net check to do something.  A vibrant Middle Class has hopes, dreams, and upward mobility. Those are all things a Safety Net can’t cover–only Opportunity can provide hope or fulfill dreams.

It’s time to start Taxing the Robots, Not the People.

If the Robots are going to take over more and more of the economy to the detriment of the People and the benefit of those few who can own thousands of Robots, why not tax the Robots?  In fact, why not look at any practice that wholesale destroys lots of jobs as being worthy of taxes to pay for programs to help those who’ve been displaced?

If we look at it that way, there are several areas to think about applying progressive taxes:

–  Taxes on automation and robots

–  Taxes on offshoring jobs

–  Taxes on monopolies that take over markets and then use their unfair influence to gut jobs by destroying all competition

These taxes will automatically be progressive.  They will help balance the playing field so that progress can still come, but there are costs that result in funds to help those displaced by progress.  We don’t want to eliminate the progress, we just want to even out some of the unfairness that comes when we let progress run completely roughshod.

So far, we’ve done very much the opposite, which is part of our problem.  Our system makes hiring more expensive not less.  However good its intentions, Obamacare is a net job reducer because businesses have to pay for it based on how many employees they have.  What if instead they paid based on how many robots, or on how many jobs they had offshored?

There’s been such a massive transfer of wealth that clearly there is money to pay for such programs.  Much more than enough.  While we’re at it, we should be exempting smaller businesses from such programs.  It’s been well proven that Small Businesses are the engines of job creation and growth.  As a nation, we’re sold on the idea of more and more progressive taxes for people, but we have left off progressive taxes for businesses.

We have a tax system that allows 43% of Americans to pay no Federal Income Tax.  Why not a system that allows the smallest 43% of businesses to pay no taxes?  That would dramatically level the playing field and re-ignite Small Business growth.

So, in a nutshell, what we could do to offset a continuing economic disaster for the Middle Class would be:

1.  Tax Robots, Offshoring, and Monopolies so that organizations involved with these practices have the highest tax rates

2.  Radically lower taxes for Small Business.  Some meaningful fraction of them shouldn’t have to pay taxes at all.  Perhaps not 43%, but certainly the 20% or so smallest business.  Make up that lost revenue by increased taxes on larger businesses.

3.  Make #1 and #2 net positive tax revenue generators to allow for new programs.

4.  Put a solid Safety Net in place.

5.  Stimulate the Small Business economy with what’s left.  In addition to Radically Lower Small Business Taxes, we should increase the availability of Small Business Loans and we should make Education cheaper.  The latter will make it easier for those whose jobs were automated away to retrain as well as ensuring an increasing pool of talented labor.

The biggest obstacle in all this thinking is that currently, the people calling the shots in terms of lobbying and poltiical contributions are precisely the ones we propose to have pay for these new programs with new taxes.

How will we ever break out of that cycle?

Posted in saas | 2 Comments »

Oh Dear, the Green Pundits Don’t Understand the Cloud or Multitenancy

Posted by Bob Warfield on January 16, 2015

forestRecently I was drawn into a discussion of how Green the Cloud is where I responded as follows:

SaaS is going to come out ahead of any reasonably calculation of carbon emissions versus on-prem. Multi-tenancy is just a lot more efficient. Look at the data centers of companies like Google, Amazon, and Facebook. Most corporates wish they could come close as they watch these companies dictate every detail right down to the exact design of servers in order to minimize their costs. As everyone agrees, most of that cost is energy.

So choose SaaS if you’re worried about carbon, and yes, it could become another axis of competition in terms of exactly which Cloud provider does it best.

Tom Raftery immediately responded:

The answer is that it depends, tbh. It depends entirely on the carbon intensity of the data centre (where it sources its energy), not the efficiency of the data centre.

If you have a data centre with a PUE of 1.2, and it is 50% coal powered (not atypical in North America, Germany, Poland, and others, for example), it will have a higher CO2 footprint than a data centre with a PUE of 3.0 powered primarily by renewables – again I have run the numbers on this and published them.

Similarly with on-prem. If I have an app that I’m running in-house, and I’m based in a country like Spain, France, Denmark, or any other country with where the electricity has a low carbon intensity; then moving to the cloud would likely increase the CO2 footprint of my application. Especially if the cloud provider is based in the US which has 45% of its electricity generated from coal.

Tom is the chief analyst for Greenmonk, which writes about this sort of thing for a living.  He’s been quoted by others who are in the same camp such as Brian Proffitt on ReadWriteWeb.  And who wouldn’t love a nice juicy story to put those darned Cloud vendors in their place?  Those guys have been riding high for too long and ought to be brought down a notch or two, harrumph.

I have a lot of problems with this kind of math–it just doesn’t tell the whole story.

First, I can’t imagine why Tom wants to be on record as saying that PUE (Power Usage Efficiency) just doesn’t matter.  Sure, he has found some examples where CO2 footprint overwhelmed PUE, but to say the answer depends entirely (his word) on the sources of the data center’s energy and not on the efficiency of the data center just seems silly to me.  Are there no data centers anywhere in the world at all where PUE matters?  Did all the Cloud data centers with great PUE just magically get situated where the carbon footprints are lousy enough that PUE can’t matter?

I’m very skeptical that could be the case.  You must consider both PUE and CO2 per Kilowatt Hour, how could we not when we’re talking per Kilowatt hour and PUE determines how many Kilowatts are required?

Here’s another one to think about.  If this whole PUE/CO2 thing matters enough to affect the economics of a Cloud Vendor, we should expect them to build data centers in regions with better CO2 energy.  Since they put up new data centers constantly, that’s not going to take them very long at all.  Some are talking about adding solar to existing facilities as well.  Now, do we want to lay odds that corporate data centers are going to be rebuilt and applications transferred as quickly for the same reasons?  If you’re running corporate IT and you have a choice of selecting a Cloud Data Center with better numbers or building out a new data center yourself, which one will get you the results faster?  And remember, once we are comparing Apples to Apples on CO2, those Cloud vendors’ unnaturally low PUE’s are going to start to haunt you even more as they run with fewer Kilowatt Hours.

Multitenancy Trumps all this PUE and CO2 Talk

But there’s a bigger problem here in that all data centers are not equal in another much more important way than either PUE or fuel source CO2 footprints.  That problem is multitenancy.  In fact, what we really want to know is CO2 emissions per seat served–that’s the solution everyone is buying.  Data centers get built in order to deliver seats of some application or another, they’re a means to an end, and delivering seats is that end.  The capacity they need to have, the number and type of servers, and hence the ultimate kilowatts consumed and carbon footprint produced is a function of seats.  Anyone looking purely at data centers and not seats served is not seeing the whole picture.  After all, if I run a corporation that has a datacenter, it’s fair to charge the carbon from that datacenter against my corporation.  But if I am subscribing to some number of seats of some Cloud application, I should only be charged the carbon footprint needed to deliver just those seats.  Why would I pay the carbon footprint needed to deliver seats to unrelated organizations?  I wouldn’t.

Corporate data centers have been doing better over time with virtualization at being more efficient.  They get a lot more seats onto a server than they used to.  The days of having a separate collection of hardware for each app are gone except for the very most intensive apps.  But that efficiency pales in comparison to true multitenancy.  If you wonder why, read my signature article about it.  I’ll run it down quickly here too.

Consider using virtual machines to run 10 apps.  Through the magic of the VM, we can install 10 copies of the OS, 10 copies of the Database Server, and 10 copies of the app.  Voila, we can run it all on one machine instead of 10.  That’s pretty cool!  Now what does Multitenancy do that the VM’s have to compete with?  Let’s try an example where we’re trying to host the same software for 10 companies using VM’s.  We do as mentioned and install the 10 copies of each kind of software and now we can host 10 tenants.  But, with multitenancy, we install 1 copy of the OS, 1 copy of the Database, and 1 copy of the app.  Then we run all 10 users in the same app.  In fact, with the savings we get from not having to run all the VM’s, we can actually hose more like 1000 tenants versus 10.

But it gets better.  With the Virtual Machine solution, we will need to make sure each VM has enough resources to support the peak usage loads that will be encountered.  There’s not really a great way to “flex” our usage.  With Multitenancy, we need to have a machine that supports the peak loads of the tenants at any moment in time on the system.  We can chose to bring capacity on and off line at will, and in fact, that’s our business.  For a given and very large number of seats, larger than most any single corporate application for most corporations, would we rather bet the corporation can be more efficient with on-prem software in its wholly owned data center or that the SaaS vendor will pull off far greater efficiency given that its software is purpose-built to do so?  My bet is on the SaaS vendor, and not by a little, but by a lot.  The SaaS vendor will beat the corporate by a minimum of 10-20x and more likely 100x on this metric.  You only have to look to the financials of a SaaS company to see this.  Their cost to deliver service is a very small part of their overall expenses yet most SaaS apps represent a considerable savings over the cost of On-Prem even though they carry the cost of delivering the service which the On-Prem vendor does not.

Conclusion

Raftery says, “energy use” and “emissions produced” have been conflated to mean the same thing.  I say he’s absolutely right about that but hasn’t seen the bigger picture that it is not energy use nor emissions produced in isolation, it’s seats delivered per emissions produced.  Itt’s having the flexibility to make a difference rapidly.  And that is why we bet on the Cloud when it comes to being Green.

Posted in cloud, data center, enterprise software, saas, strategy | 1 Comment »

Yes, In It’s Pursuit of Being a High-Margin Luxury Brand, Apple Must Eventually Be Less Functional

Posted by Bob Warfield on November 3, 2014

DSCN0023Even Seth Godin flushes out the Apple Fan Boys sometimes.  David Terrar has an, “I disagree with Seth Godin,” post going.  Seth’s premise, as set forth in, “Decoding Apple as a luxury tools company,” is that eventually, as a company builds a luxury brand, they must choose between luxury and utility or be trumped by another luxury brand that did make the choice.

I’ll cut to the chase–Seth is right and David is wrong to disagree.  Now I’ll explain.

David Gives The Best Counter-Examples to His Own Position

He talks about Patagonia being able to continue on utility and still function as a luxury brand.  But that misses the nuance of Godin’s article.  Patagonia is trumped by Louis Vuitton and countless others precisely because they were focused entirely on luxury with no need for any utility-seeking compromises.

He askes whether Ferrari, Bentley, Bugatti, or Aston Martin compromise their engineering in the interests of luxury, and suggests that of course they do not.  Au contrare, David, aucontrare.  At the risk of mobilizing both the legions of Apple Fan Boys and still more fans of these fine marques, they do compromise engineering.  Enzo Ferrari used to purposefully limit the performance of his street vehicles because he didn’t feel his customers were competent to drive cars with greater potential.

This practice didn’t stop when the Old Man checked out.  Every Ferrari I’ve owned or driven compromised all sorts of handling performance in the interest of greater comfort.  They love that light steering feel and the cars are ever so much more supple over bumps because of course we need to protect the delicate posteriors of our customers.  Luxury?  Absolutely.

Much the same can be said of Bentley, Bugatti, and yes, Aston Martin.  Their cache is exclusivity or outrageousness, not fine engineering.  We may as well lump Lamborghini into all that, if need be.  McClaren?  The jury is still out on that one for me, perhaps there is one shining exception.  Or indeed, perhaps individual models (F40) escape.  But overall, these auto brands are great examples.  Mercedes and Porsche are luxurious, but they are not apex luxury like these other cars.  They have much better engineering and bring more innovations to the table.  Heck, the lowly Corvettes have Utility advantages over many of these cars and are at best low-end luxury.

Watches?  Don’t get me started.  The luxury time pieces favor mechanical movements.  My Rolex loses time every day compared to a decent Swatch.  But it just wouldn’t be right to stick a quartz movement into a luxury watch like the Rolex, Patek, or name-your-expensive-Swiss-timepiece-here.  So they don’t, and have therefore done something to benefit their luxury status to the detriment of their utility functionality.  You could argue they’ve abandoned Utility altogether from any objective measure of what the Utility of a wrist watch ought to be.

Must Apple Do This?  Has Apple Already Done This?

So far, I think most agree that while Apple may have flirted with sacrificing Utility for Luxury, they haven’t actually crossed that line decisively.  There are certainly needless dogmatic issues that drive anyone transitioning from a PC crazy.  I have True Apple Fan Boy friends that only use their Macs with PC keyboards and PC mice.  It seems they want real <Del> keys, <Home>, <End>, scrolling mouse wheels, more buttons and all that jazz that Apple mysteriously refuses to give them.  In the past there have been missing fans and arrow keys that were again nods to Luxury versus Utility.  But Apple backed away from them.  Perhaps they’ll fix their keyboards and mice too.

These things happen because part of being apex luxury is ignoring customers.  After all, you are the infallible arbiters of style.  What you produce is by definition better than what anyone else produces.  What could a mere customer possibly have to tell Louis Vuitton about how to make more luxurious cases?

Yes, it’s arbitrary, dogmatic, and a chase your tail kind of tautology.  But that’s the nature of Luxury and Style versus Utility and Function.  It starts with how the brand is judged, and it would be hard to argue that Apple doesn’t see themselves firmly in the Luxury versus Utility side of the judgement game.  They don’t consider anyone worthy of judging their products.

What About the Ecosystem?

We shouldn’t leave this whole Luxury/Utility dichotomy without touching on the issue of ecosystems.  Luxury goods don’t have them.  Utility goods do.  There can be little question that ecosystems add utility value, though they can also add complexity and other pain.  My Macs plug and play with, well whatever they’re willing to plug and play with.  My PC’s plug into vastly more things but very often they don’t play very well once plugged in.

Apple has sharply limited their ecosystem to that which they strictly control.  In so doing, they have made some choices not unlike the Godin quote:

When Apple dumbs down Pages or Keynote or allows open bugs to fester for months or years, they’re taking the luxury path at the expense of the tools path.

Consider the whole approval cycle for their App Store ecosystem.  They will argue it is there to protect users from junk apps.  I’d argue it’s more about closing Apple’s ecosystem so it cannot threaten them in any way and so they can maximize their profits from it.  Here’s what I mean about the Godin quote being close to home:

One of the great advantages of SaaS is keeping everyone on the same release and making sure that release can be quickly and easily upgraded.  I surveyed Enterprise Software Customer Service one time and discovered that companies estimated that 40-70% of bugs in open trouble tickets were fixed in the current release.  That’s how important updates are–they literally keep 40-70% of your customers from even seeing the bug in the first place.

Yet, because we have to protect these  Walled Garden, it may take quite a lot of time and effort to get a new release approved.

To David’s list of brands and the power of ecosystems, I’ll bring in the world of audio.  Bang and Olufsen are beautiful.  They’re luxury.  But are they utility?  Are they the best sounding audio?  They’re all in one and they eschew an ecosystem, but is that really a good thing if you want to maximize their Utility (e.g. Audio Performance)?  No, not really.  And look at how similar B&O are to Apple.  Interesting parallels there.

Is Apple helping their Utility or their Luxury by limiting their ecosystem so much?  At one time, I think they were helping their Utility, but that balance seems to me is shifting more to Luxury.

Godin’s Decoding of Luxury vs Tools is Not Unlike Michael Porter’s Competitive Strategy

I found Godin’s view of the Luxury vs Tools markets to be not unlike Michael Porter’s venerable Competitive Strategy, for those who remember their B-School studies.  Porter argues that there are only 3 successful competitive strategies:

1.  Be the Best.  Here he means “having the most utility” vis a vis Godin’s take.

2.  Be the Cheapest.  This is Microsoft and Dell to Apple’s “Be the Best.”

3.  Serve a Niche that #1 and #2 are under-serving.  This is where the most Luxurious winds up.

Porter suggests that companies need to pick just one of these strategies.  Trying to serve more than one divides your resources and will allow a competitor that focuses on just one of the strategies to beat you.

What often happens to brands that start out to be the Best is they can’t sustain that advantage.  That requires too much engineering inspiration and innovation, which is just not reliably schedulable when you need it.  So instead, they start to flirt with design inspiration, which can be scheduled and in fact is more desirable if things change often because what that audience seeks is distinction.  They relish the opportunity that there is new distinction constantly being made available for their delight.

The situation for Apple is sustaining that pace of innovation.  My Microsoft Surface Pro 3 is a good example.  It’s hardware is absolutely up to Apple’s standards in every respect.  Apple at this time has no notebook tablet.  Will they build one?  Or will they insist that since they are Apple, the world must follow their lead and they will not be following anyone else?

Can there be a MacBook Tablet, or will it go the way of the keyboards and mice, wishing they had the PC functions or worse, suffering the indignity of having PC hardware plugged into the pristine Mac User Experience?

Is Apple selling the Best Technology or Silicon Haute Coutoure for the Well-Monied Gadget Set?

Oh and David, you mention you wished there were comments on Seth Godin’s blog?  I sure wish Medium where your article appeared had them too.

Posted in saas | 10 Comments »

Secrets of When and How to Talk to Customers at a Startup

Posted by Bob Warfield on October 9, 2014

elephant-with-blind-menJason Lemkin says forget building wireframe UI’s and start out interviewing 20 customers, because you just won’t understand your customers until you do.  Here’s the gist of why you need 20 interviews before you do anything else:

And you have to do 20.  I know it’s hard to get to 20.  But it’s the right number:

  • You need the First 5 Interviews just to truly understand the white space and the current opportunity.  Yes, you probably think you already understand it.  But you are the vendor, not the purchaser.  You need to understand your prospective app from the purchaser’s perspective, for real.
  • You need the Next 5 Interviews to confirm your pattern recognition.  You learn from the first 5, you confirm in the next 5.
  • You need Interviews 11-20 to Nail Your Pitch and Hone Your Thesis.  Once you truly understand the white space from a buyer’s perspective, and you’ve figured out the nuances and challenges … it’s time to nail your pitch for real.  And by doing this, you’ll also hone your thesis and strategy.   That’s what interviews 11-20 are.  To get real critical feedback on what you’ve learned.  To learn about corner cases that may in fact be critical insertion points for you to win.  To dig in on what is really 10x better, not just 2x or 5x better.

And let me tell you, at least from my experience, don’t expect all 20 to be positive.  Many of My 20 Interviews in both my start-ups were very critical.  Or worse, lukewarm.  Lukewarm is even worse, because it says yeah it’s sort of interesting … but no way I’d buy … and implicitly … your idea is a huge waste of time.  I’d rather get the negative feedback ;)

I get the Steve Jobs thing.  You just have to build it.  You do.  But this is SaaS.  You’re solving a business’ problem.  They don’t know how to solve it, or what you should build.  But they do now how to express their problem.  Acutely, and thoughtfully.

Here’s the funny thing–in some ways I agree with Jason and in others I totally disagree.  It depends really on what it is you’re trying to learn from your 20 interviews.  Jason says you’re trying to understand the white space and the current opportunity and that you’re trying to nail your pitch and hone your thesis.  He’s thinking about it like a Sales Guy, more power to him, someone in your company ought to be.  But there’s more to life and startups than Sales Guys.

Here is what I worry about validating in the early days of any startup:

1.  What is the problem we’re trying to solve for customers?

2.  Is it a real problem?  Do a large portion of customers believe they have this problem?

3.  Will the solution we’ve imagined actually solve that problem?  Do the customers agree that it solves their problem?  Can we charge enough to make a real business for this solution?

4.  Do we have a pitch that communicates we have a real and effective solution quickly?

I see Jason’s 20 interviews as helping to solve #2 and #4, but not really making much impact on #1 and #3.  Moreover, I see #4 as being pretty tactical, unless, of course, you need that finely honed pitch to convince investors.  It’s tactical because we won’t need it until it’s actually time to get customers to deploy beta product.  In other words, we have quite a lot of time to solve it.  #3 is not so tactical.  In fact, if we don’t solve #3 right up front, we could easily spend the bulk of our time building a product that we think solves the customer’s problem but that customers aren’t confident in.

Let’s drop back and work on each one of these 4 critical questions and see how and when in the startup cycle they should be tackled.

1.  What is the problem we’re trying to solve for customers?

This is a tough one for many entrepreneurs.  I’ve seen a few decide to try to find a hard problem to solve by interviewing potential customers.  What keeps you up at night?  What do you hate about your job?

Ugh.  That seems so hit or miss.  None of the ones I met who’ve tried this got very far with it.  They got problems that software was just simply not the cure for or they got problems that are more conditions of the human race than anything.  Jason says customers, “Know how to express their problem.  Acutely, and thoughtfully.”  Actually, they don’t, not so much.  They know how to resonate with a problem that you’ve stated acutely and thoughtfully.  They know how to resonate when you state a problem as a near miss to how they really think about it.  But customers are not product designers nor company founders for the most part.  They’re severely myopic.  As Henry Ford famously put it,

“If I had asked people what they wanted, they would have said faster horses.”

So don’t rely on customers to tell you what the problem is.  Really on them to confirm you’ve found a problem they feel.  Later, they’ll remember it as you having discovered the problem from them, but that’s not really how it works most of the time.

There are a lot of reasons for this.  The myopia is one but another is they just don’t know much about the medium you work in–software.  They have little idea what software can do for them.  They think of most software in terms of software they already have, which is another form of myopia.

You are not going to figure out that problem, in all likelihood, through a few simply interviews.  You’re going to have to live the life of your customers for a while, walk in their shoes, and feel their pain.  You need to know their domain intimately, which is not something that’s going to happen in 20 interviews, no matter how good they are.  That’s how two great Sales Guys wound up creating two great CRM companies–Tom Siebel with Siebel Systems and Mark Benioff with Salesforce.com.  I interviewed with Tom Siebel when he had less than 20 employees and the one thing that was absolutely clear about the man was that he knew the domain and its problems cold.  That’s the kind of solid domain knowledge you really should have in your startup.  Who can you point to who has lived and breathed the problems and knows them cold?

Is that the only way?

No, there are plenty of exceptions.  There are proxies available too.  Finding a large online community of your desired customer can give you huge insights into what their world is all about.  What do they ask questions about most frequently?  What do they complain about frequently?  These communities are so helpful to startups both for gathering information as well as for getting out the word that I’m not sure I’d want to do a startup that couldn’t identify an online community specializing in its customers.  In this age of Content Marketing, it seems to me that such a community would be a very valuable indicator that the market was going to be reachable and at reasonable costs.  I don’t want to have to advertise or cold call my way into existence, though many have certainly done so.

To put this into the perspective of Jason’s 20 interviews, you need domain knowledge for your startup before anything else.  You won’t get it from the 20 interviews, and it is just table stakes that you have to find.  Maybe you’re counting on a founder for it.  Maybe you have the world’s ultimate advisory board.  Maybe you’ve sold to these poeple in a former life and know all about them.  Maybe you’ve spent a year studying and interacting with their online communities.  Whatever it is, you’d better have it.

 

2.  Is it a real problem?  Do a large portion of customers believe they have this problem?

Having gotten your domain knowledge together, you believe you’ve discovered a real problem.  Now that you can articulate that problem, it’s time to confirm it with potential customers.  Jason’s 20 interviews are perfect for this stage.  I don’t know that there is anything magical about 20 or that this even has to be done via interviews.  If you’re going to be using feet on the street to move your product (e.g. a scratch golfin’ highly paid salesforce), you should probably get started with interviews.  If your Sales Guy can’t line up 20 interviews in his sleep, there is something wrong, so may as well set him to the test.  If you weren’t planning to get a Sales Guy until later and you can’t line up 20 interviews on your own, you better get the Sales Guy sooner.  There’s a lot of good that comes from achieving the 20 interviews and here Jason and I agree wholeheartedly.

But in addition to 20 interviews, I highly recommend a few other things.

One of my mentors has used the method multiple times of creating a web site that’s all about the proposed problem and solution.  He sets it up like there’s a product ready to go, except there’s no way to order it.  You can simply request more information.  He gauges the quality of the idea by whether he can get many information requests.  And yes, he understands the need to do some tuning up before giving up.  This is a case where having online communities of your potential customers is awesome.  If you have a simulacrum site as described (looks like a real company and product), you can ask the folks in the community what they think of the company and idea.

If you don’t like that approach because it just feels a little too funky, try my approach.  I started a blog before I started my current company and I waited to see if I could drive significant traffic to that blog discussing the kinds of problems I wanted to solve.  I would talk about how people were solving their problems today, rather than how I proposed to solve them.  I measured traffic using all of the standard web analytics to see what resonated and what did not.  I built a lot of credibility and I had a following already in place that I leveraged to a significant Beta test and significant cash sales when I was finally ready to launch the product.  But, before I started building the product, I knew from how people were reacting to my writings that I understood the customers and their problems very well.  I achieved what I call “Content-Audience Fit” (a precursor to Product-Market Fit).  More about that below under #3.

 

3.  Will the solution we’ve imagined actually solve that problem?  Do the customers agree that it solves their problem?  Can we charge enough to make a real business with this solution?

Here’s where I probably disagree with Jason the most.  He says, “So if you haven’t started yet, as fun as it is to just build the wireframes and get a codin’ … do the 20 Interviews.”

Here’s my problem–as I’ve mentioned, the Customers really can’t articulate their problem unaided.  They can only resonate with your articulation.  We may have to agree to disagree on that, but figuring out how to resonate well is a huge function for Sales precisely because the customer can’t do it for themselves.  They often need help even in how to present it to each other to get buy-in within their organizations.  When you go interview them, you’re going to get a variation on the three blind men encountering an elephant for the first time.  One touches the trunk, and thinks it’s a snake.  Another touched the tale, and thinks it’s like a straw fan swishing back and forth.  While the third touched the legs and pronounced that elephants are like trees.

When it comes to envisioning a solution, especially in software, things get far worse.  At least they have all experienced the problem, even though it may appear to be a snake, a fan, or a tree.  But nobody outside your company even has a glimmering about your proposed solution.

I’ve done lots of focus groups over the years and lots of the kinds of interviews Jason talks about, and I am here to tell you it is pointless to do either if you expect to get feedback about a software solution unless you have at least some wireframes and storyboards to show.  With modern tools, it’s just not that hard to produce these things.  I’m working on our third product at CNCCookbook.  I was able to put together a UI prototype that is substantially what our finished product will be with about 6 weeks worth of effort.  It’s been hugely valuable in securing feedback for the product and I have learned an awful lot from it.  Perhaps the biggest problem it has is people start to mistake it for a finished solution or they assume it’ll be ready much sooner than it will and they get too excited.  They’re ready to buy immediately.

Yes, it may be fun to build wireframes, but it is also fun to have real meaningful conversations with prospective customers about your proposed solution.  You’re going to learn so much more about everything if you can do that around a real demo.  You’ll learn about positioning, sub-problems and edge cases that as Jason says are critical insertion points to win.  You’ll learn whether your proposed solution really fixes the customer’s problem in their eyes.  You’ll feed on the enthusiasm they have for what they see, and that enthusiasm is valuable fuel for your startup, for convincing critical new hires, and for any potential investors you may have.

If it’s really going to be hard for you to get interviews with 20 real prospective customers, people who are solid citizens in their markets and who are not your buddies.  People who will give you the straight scoop, help guide you, and who you’re hoping will be early adopters.  If it’s that important and that tough, I can’t imagine wanting to do it without bringing along a UI mock up.  It isn’t just my current venture, I have done this at every single one of the 7 startups I’ve been with.  I have done it for every new product release.  It’s actually integral to how I approach the Agile Software experience.

If your Sales Guy can’t get 20 meetings, get another one.  If your Product Guy can’t get you a UI prototype quickly, get another one there too.  Both are equally as important.

One more thing–that last part, “Can we charge enough to make a real business with this solution?”  That’s critically important to answer ASAP.  It’s also nearly impossible to get a very good answer to it without a UI prototype.  Yes, they will give you some answers, but I am talking about real answers that will hold water when it’s time to cash the checks. Don’t you want to know whether customers will pay up for what you’re going to build as early as possible?

 

4.  Do we have a pitch that communicates we have a real and effective solution quickly?

This is what I call “Content-Audience Fit“.  I believe achieving that fit needs to come ahead of finishing the product if for no other reason than that you won’t know if the product is finished nor will you be ready to efficiently leverage content for product traction unless you do.

Jason’s 20 meetings go towards this end, but it’ll take more than 20 to really nail your pitch.  Personally, I don’t like to burn real perspective customers, investors, or other scarce as hen’s teeth resources for a company if I can find another way to test this stuff out and perfect it.  The online world and Content Marketing are your gateway to doing so. Once you can resonate with those audiences, break out the Rolodex (kids you’ll have to look up what that is) and start asking for meetings.  You’ll be bringing to that meeting a laundry list of good-as-gold asssets:

–  By this point you have a UI prototype to demo.

–  You have verified that you can talk about the problem and with the audience with enough credibility that they’re at least starting to come to you for answers.

–  You’ve had the opportunity to test a number of things with your growing audience.  You’ve probably even been able to do some surveys.

–  You have a corpus of content that you can point potential meeting invitees to that helps establish your bona fides and gets the conversation off on the right track.  If done right, this can be a warm call and not a total cold call.

Most importantly, none of this is all that expensive or time consuming.  You can do it on your own nickel without waiting for a Series A VC round.  I know I have more than once.  I’d set a goal of 3-6 months to get to this point.  If everyone is firing on all cylinders, you’re producing good content, you’ve gotten through your UI prototype, and you’ve made contact with a decent sized audience, you’ve accomplished a lot at your startup.  You’re right where you need to be.  Now line up those 20 meetings, get in there and make those 20 people your first Beta tests, and hit the ball out of the park for them.  They’ll love you for it and you’ll have set the stage for your next 6 months as you drive to launching the Beta and eventually real Sales.

Posted in bootstrapping, business, enterprise software, saas, strategy, venture | 1 Comment »

Microsoft’s 4 Real Problems that Gates, Nadella, and Ballmer Can’t Fix

Posted by Bob Warfield on October 8, 2014

WushuI just finished the Vanity Fair piece on Gates, Ballmer, Nadella, and whether Microsoft can be rebooted to its former glory.  It’s a good article, but it’s all about the past mistakes and there’s little about the future there.  Mostly, it is the account of how two best friends (Gates and Ballmer) broke up over the internal stresses of running Microsoft.  Ballmer characteristically doesn’t accept blame for much (we missed search and phones, but our real problem was the Longhorn project which the article implies he blames equally on Gates) and Gates never really talks much about what went wrong at all.

I’ve written a little bit before about what I see as the problems, but wanted to do a full treatment of it.

Problem number 1:  Microsoft Was Never Agile

Remember the old saw about how Microsoft products were never very good until the 3rd release?  Add to that the notion that the minimum product cycle was about 2 years and often 3 or 4 and you begin to get an idea of just how non-agile the company is. There are claims that this is being fixed, but it is a huge cultural problem to fix.  Microsoft is run by committees chaired by Product Managers and MBA’s.  Those folks are not agile by their very nature, meaning they don’t understand concepts like “Minimum Viable Product” nor how to work off a strictly prioritized agile backlog.  It’s just not how the culture works and it will take Herculean upheavals and new tissue grafts to ever make it very agile.

I’ve been through this conversion on more than one occasion, and it’s never easy.  Unfortunately, the very tenets of agile done right are at odds with how Microsoft makes its decisions.  Gates, Ballmer, and Nadella grew up developing software the Microsoft Way, which is not the Agile Way.  They may pay lip service to Agile, but until they have lived and breathed it, or brought in those new tissue grafts who have lived and breathed Agile, it’ll just be a lot of talk and Microsoft will continue to move far more slowly than Agile competitors.

Problem Number 2:  Microsoft is a Commoditizer, not an Innovator

Microsoft has always been a commoditizer.  They take someone else’s Great Idea, build a high quality facsimile, and sell it under the brand and monopoly umbrella.  That worked well for a long time, but the combination of frictionless product discovery via the Internet, the pace of agile software development, and new business models such as advertising make the role of commoditizer, at least as Microsoft plays it, very difficult.

In the past, people bought the commodity for a couple of reasons that are not nearly as strong today:

–  Brand:  The power of brands has greatly diminished, Microsoft’s brand has become tarnished, and there are many new brands to choose from.  If nothing else has happened during Microsoft’s corporate life, the world has learned that relative unknowns become Big Brands in a very short time.  There’s not nearly the stigma buying lesser names that there used to be. Brand is also about getting noticed, and the increasingly frictionless web has made it easier and easier for upstarts to get noticed.

–  Price:  When I was a General in the Office Wars, Microsoft beat Borland and my Quattro Pro product on price.  It was clever pricing too–who wants to buy individual best of breed products when you can get such a great deal on a suite with everything you need?  Today, Microsoft is hard pressed to be the low cost provider.  Open Source and Advertising Models have completely destroyed that advantage.

–  Interoperability:  This is Microsoft’s last bastion.  We buy Windows because so much that we depend on in terms of applications, data, and hardware needs Windows to function.  But this is not a particularly strong barrier.  It amazes to me that companies like Google haven’t worked harder to eliminate it.

Problem Number 3:  Microsoft is Not Especially Good at Strategy

I know this will come as a shocker to many, especially those inside Microsoft, but it’s true.  Once Microsoft’s essential monopolies were cemented, their strategy consisted 100% of holding onto them and milking them for every last penny they could.  You could call that strategy, but it isn’t competitive strategy, and that’s where Microsoft have been losing their shirts.

When you’ve been so successful for so long with such strong monopolies, it isn’t surprising that strategy becomes atrophied.

When you’ve gotten there by copying and commoditizing the Other Guy’s Ideas, who will deliver the next great Strategic Ideas that change the terrain meaningfully to Microsoft’s advantage?

Strategy is what you do to make winning easier.  When you have a very hard time admitting you’re losing badly and you think you have all the time in the world to fix it with overwhelming force, why bother with Strategy?

Perhaps Nadella is a strategically subtle Guy, but he hasn’t shown that side yet.  Sure, there are some decent tactics at play, but aren’t they more finally accepting the Other Guy’s Playbook than genuinely inventing any new plays yourself?

Problem Number 4:  Microsoft is Clueless About Creating Insanely Great Products

This has been clear for a long time.  As they commoditize Other People’s Ideas, the results have never been quite as good.  It’s like there’s a little extra noise each time you copy a tape.  By that 3rd generation where Microsoft supposedly gets it right, there’s quite a lot of noise.

The blame here goes squarely with Microsoft’s Product Management Culture.  There has been a misconception about Product Management for a long time in High Tech.  Many see them as the ones who write the stone tablets that are product vision and hand them to engineers who then laboriously transcribe those visionary ideas into products.  While a tiny percentage of Product Managers may be good at that, the vast majority are not, though their organizations give them that power for a variety of historical and political reasons.

Here’s the thing:

Product Managers are the only people in the organization whose sole job is to listen to the customer and help inform product direction of that feedback.

That’s it, that’s all, it’s a full time job, full stop.  They pass those customer insights on to whomever really does do the Product Vision.

The other shoe that drops is implementing laundry lists of literal customer requests does not a product vision make. Instead it creates the cluttered messes that are what we hate about Microsoft software today.  Synthesizing all of those requests to understand the real underlying problem customers want to solve may inform at least a portion of the vision.  But most of the real visionaries take this input as just a set of anecdotes.  They derive a vision far larger than the input because innovation cannot be deduced it can only be imagined and concieved.  The results may even be at odds with the customer input.  Most game changers are.  Characters like Steve Jobs and even Henry Ford (if I’d asked customers what they wanted they’d have said a better horse, not a car) worked that way.

By this stage, Microsoft software usability is hugely tarnished to the point of embarrassment.  No fiddling around with the current Product Management-based culture will fix it.  Real Product Vision is a fairly dictatorial process.  Until Microsoft finds and empowers some real visionaries, little will change.

Whither Thou Goest, Oh Microsoft?

Four tough problems that the current and past leadership and in fact the very culture at Microsoft are not well equipped to deal with.  Yet there are some mitigating factors.

Hardware and the Steady March of Moore’s Law Will Help to Buy Microsoft Time

I recently acquired a Microsoft Surface Pro 3.  It’s a fantastic piece of hardware–every bit the equal of Apple’s iPad or Macbook hardware.  The software is flawed, but relatively fixable.  When I use it, I can’t help but wonder if it were a little bit cheaper and the usability flaws were fixed, why would I care about iPads or Android tablets?

Those older devices have the compromises that were needed to make them work given the hardware limitations of their day. As it becomes possible to offer anything that could run on a PC in that form factor, such devices seem increasingly anachronistic.  This is a wide open opportunity for Microsoft to re-emerge if they can fix the usability problems of Windows 8.

Unfortunately, I don’t see Windows 10 doing that, but that’s a subject for another article.

Microsoft’s Chief Rivals are Not What They Used to Be

Apple and Google may be bigger than ever before, but their inevitability is much more in question than at various times in the past.

Apple is sorely missing Steve Jobs and has had a raft of problems lately ranging from privacy breaches to the painful task of propping up a stock price that already touches the sky.  In may ways Tim Cook could turn out to be Apple’s version of Steve Ballmer.  He’s certainly no Steve Jobs, and the question will be whether he can create a sufficiently Jobsian substitute in the already extant Apple Culture to keep the pace of innovation on.  The longer they keep up with ho-hums like the iPhone 6 or their wrist watch (battery life of one day and most of my friends have completely stopped wearing wrist watches) the more the world will begin to wonder.

Every day brings Google closer to being unable to sustain the growth needed for its multiples on its core search advertising business.  Every day customers are educated more fully that they are really not customers–in an ad-driven business model they are the inventory, and they’re not treated nearly as well as customers expect to be.  Google is so far another Microsoft milking its monopolies while it thrashes around wildly looking for new revenue sources that are big enough and profitable enough to matter.  Most of their acquisitions die with a whimper.

Microsoft Have a Monstrous Huge War Chest

The acqusition of Minecraft and Nokia makes that clear.  If Microsoft can find suitably strategic targets of opportunity, they certainly have the cash to acquire them.  The trick is in finding the right targets.  All too often this becomes an excercise in tying two stones together in hopes they float better than one.  Most of these acquisitions wind up net destroyers of capital.

Nadella has the Honeymoon Period’s Willing Suspension of Disbelief

He has time, perhaps two more years, to start making meaningful progress out of the quagmire.

Gates is no dummy either.  In fact he is probably the smartest person I’ve ever met.  Vanity Fair got it wrong when they said he’s a big picture guy.  I spent an afternoon debating deep product architecture with him as he considered acquiring my company and at least at that time he had deeper product knowledge than any CEO I’d ever met.  Unfortunately, he has little knowledge that’s relevant to the 4 big problems I’ve outlined.  But, he has always been the sort to throw himself deeply at problems, even intractable problems of the third world as the Vanity Fair piece suggests.

The trick for both of these gentlemen is focusing on the right problems to solve.  If they can, they’re likely to make a difference.  If they can’t, there will be change visible but it will be for naught.

What odds do you give them and what are the right problems for them to focus on?

Posted in saas | 2 Comments »

How I Helped Start the Agile/Scrum Movement 20 Years Ago

Posted by Bob Warfield on October 2, 2014

ShopFloorTeamI’m a day late, it was 20 years ago yesterday that Dr Dobbs published James Coplien’s article on how my Quattro Pro team was building software at Borland.  Jim sent me a very nice note of reminder on it:

20 years ago today, the famous Dr. Dobb’s article on Borland QPW was published: foreshadowing agile and Scrum’s daily standup (Jeff got the idea from an earlier draft floating on the web). http://www.drdobbs.com/examining-the-software-development-proce/184409329
Thanks for being there :-)

This is a good occasion for me to tell that story of how (with Jim’s article!) I helped start the whole Agile/Scrum thing going.

The article came about because Coplien was studying software development productivity while he was with Bell Labs.  He was interviewing various groups, measuring their relative productivity, and trying to figure out what the most productive teams were doing differently.  At the time, Borland was very much in the throes of launching a slew of products that were brand new code bases for the then very new Windows platform.  I agreed that it’d be fine for him to come in and study our team’s efforts.

I didn’t know an awful lot about how other companies were developing software, heck I didn’t know too much about how Borland was doing it either except that our team seemed to be smaller than a lot of the other ones out there (including many Borland teams) and that we seemed to be more nimble (avoiding the use of that loaded word “agile”).

I was very young back then, having started my first company straight out of grad school at Rice University.  I never did get that PhD in Computer Science because instead of writing a thesis, I decided to write a business plan instead.  One thing I will say for Rice is that it was a great education in CS.  It was also the genesis of my ideas about how to build software.  One of the most interesting things that went on there was they brought in guest lecturers who gave us some impression of what was happening elsewhere in the Computer Science world at large.

I vividly remember the first “famous” software developer I met as a guest lecturer.  It was Stu Feldman from Bell Labs who had invented a program called “make”.  We all used it constantly to discover which files had been changed and speed up the compilation process so that only those files had to be recompiled and they were recompiled in the right order.  This is so basic few even talk about it anymore, but back then it was worth noticing.

What was interesting about Stu’s talk was that what he had to say about “make” was a side I had never even considered.  It was obvious to me how it worked when I saw it first, but Stu was there to talk about programmer productivity moreso than “make,” and what he had to say really caught my attention.

Programmer Productivity was a pet of mine at the time, and I had visions of going forth in the world to create the world’s greatest programming tools–tools that would radically increase every developer’s productivity.  My first startup actually built some tools like that, but that’s a story for another post.  Suffice to say that when Feldman went down that path, he had my undivided attention, because he said “make” had come about because he was tilting at the same windmills I wanted so badly to attack.

Feldman boiled the central problem in productivity down to very simple terms.  Essentially what he said was that we didn’t know how to get very many people successfully working together on a project.  After maybe 10 or 12 developers, adding more generally degraded the group’s overall productivity more than the new developer’s additional productivity could help. The central problem, according to Feldman, was communication.  “We just don’t know how to get more than 10 or 12 communicating together effectively nor how to keep them all on top of what’s going on so they could do their jobs well.”

Of course I immediately went forth after that seminar and started to soak up any wisdom I could about these issues.  Brooks Mythical Man Month (you can’t use 9 women to make a baby in a month) was also a huge influence.  In the course of reading such things, it became clear to me that software tools were not enough.  What we needed were processes and cultural changes to manage those communication problems.  This realization led me to some very basic conclusions that have informed the culture and methodologies I have used for software development ever since.  They were alive and well when Coplien analyzed the Quattro Pro team.  In fact, they were 4th generation by the time James got to see us in action.

I haven’t changed these things much.  I go through an Agile or Scrum book every so often.  They make sense, but I don’t know that they’ve influenced me to change much.

Here are the fundamental tenets I follow from these experiences:

1.  Keep teams to 10’ish or smaller in size.  I’ve never really tried to push this envelope much.  In fact, not too long after Coplien’s work came out, I wound up in charge of all Engineering at Borland and one of the things I did was to insist on all teams fitting within this parameter.  Specifically, we cut back to 10 developers, 10 QA, and 3 writers on every project.  That included consultants and part-timers.  It was met with a high degree of skepticism and emotion as you would imagine, but it worked.  We cut costs and kept all the projects within the schedules that had been set before we scaled back.  The exception to the rule is projects where you can create solid API firewalls between components and put 10 developers on either side of the firewall.  Classic for Enterprise Software projects.

2.  If you can only have 10 on the team, they’d better be the very best that you can find.  Sure seems obvious to me, but I am continually surprised at how seldom it is followed for all the wrong reasons.  Get the best you can find means you’d better be prepared to do a lot of things:

–  Make engineering a first class part of the company.  You’ll often hear me saying, “They’re called Software companies, not Sales, Marketing, or Finance companies.”  If developers are second class citizens, they’ll smell it a mile away and won’t come near.

–  Pay what it takes.  Yeah, I know, every HR group on the planet will wave a bunch of studies saying compensation is not a motivator.  They’ll tell you, “We like to pay at the 70th percentile,” if you’re lucky and it’ll be 50th if you’re not.  Most studies of most things describe very eloquently a regression to the mean.  If you’re happy being on the mean, do what they have to say.  If not, ask yourself what you’re going to do differently.  I had the whole nth percentile pay conversation with probably my favorite PR professional in the industry.  This individual is probably also the most famous for various reasons.  Eventually I had to go to the CEO of the company to make the point about why we had to pay what we had to pay and after that, I believe this individual added it to her bag of tricks.  The bottom line is that the developer may not care about any specific bonus.  But they know they have the talent and they know when they’re being paid less when others of similar talent.  That’s a very bad thing to let happen, trust me.

–  Give them a high performance environment to work in.  Today, cubicles and often desks packed as tightly as possible together are being pushed as the ultimately productivity tools.  That’s horse hockey.  Writing software requires laser-like focus and concentration.  I am all about communication, that’s how I came up with all this, but communication needs to be engineered into the process and not slapped on by osmosis.  Maximize the distractions for these kind of people and you will minimize their productivity.  I can’t tell you how many places I’ve worked that just don’t get this.  Typically, you have to cheat it into the system with a liberal work-at-home policy.

–  Parallel Career Tracks for Pure Techies and Management.  This is another one that non-developers don’t get.  The worst days on the job for someone like me are when one of their very best individual contributors asks for a one on one, comes in all tense, and announces they’re ready to be made a manager.  I always start that discussion out by asking them why they’re attracted to the job.  If I get any variation on the flavor of, “I want to make the decisions because I have the most talent and will make the best decisions,” that individual gets counseled out of being a manager.  If we reach a point where they insist or they’re leaving, well, I tell them I will miss them.  Better to lose a great architect that turn them into a lousy manager who will no doubt piss of their team and then you lose a lot more.  As I said, those are among the worst days in my career when those things come up.

3.  Great teams build great software relatively cheaply.  Nothing is more expensive to a company than having a lousy team build lousy software.  Where am I going with this?  Forget outsourcing, offshoring, consultants, and all the rest of the silly things companies do to try to save a dime here or there on software development.  Lots of very smart people argue with me on this one constantly, but it’s true.  Look, if you’re hiring all the uber talented 10 person teams you can lay hands on and going offshore is just a way to hire even more (Google, you know who you are), it’s fine.  But if you can build anything with 10 or fewer great engineers, how much savings potential is there really in going offshore versus how much risk?  Which really awesome products in this world were built entirely offshore or outsourced.  And if communication is the biggest challenge affecting developer productivity, why would you put one team half a world away, make sure there were tons of cultural disconnects, make sure there were time zone challenges, and then just to be double darned sure you interfered with communication as much as possible make them talk over the two tin cans and a string called Skype to save a few more nickels?

4.  With only 10 on the team, they can know everything that’s going on.  OK, now we’re onto communication principles.  With only 10, they can all sit in a room together and know everything that’s going on.  Why not have them do that, every single day?  They’ll help critique each other’s work.  They’ll get fired up and empowered.  They’ll know things that the others don’t and share them.  They’ll all be on the same page, for goodness sake.  Wait.  Oh my, I hear the complaints and jeers.

Meetings are such a time sync.

Yes they are if you can’t manage one effectively.  What, did you think that you Mr Manager, were in that meeting solely so that  your subordinates could make you more efficient?  Hell no.  You’re in that meeting to make your team more efficient.  Use an agenda, keep the meeting short, make sure it starts and ends on time, change up the format to make sure people pay attention, assign everyone homework for the meeting so it doesn’t go stream of consciousness, make everyone present something, and when all else fails, make it fun.  Build the camaraderie.

I’m an extroverted management by walking around kind of guy.  Having meetings like this every morning was my attempt at letting everyone share the joys of that.  It was a crucial part of our productivity, and today it is a cornerstone of Agile/Scrum where it is called a “Standing” meeting or a “Stand Up” meeting.  Apparently some folks took it a bit literally and started doing the meeting without chairs.  That’s fine, I think I’ll keep the chairs in my meetings, but they’re short enough that not having chairs shouldn’t be a problem.  I used to tell people to get them to the meeting on time that there’d be two fewer chairs than attendees, but that was just my lame joke and I don’t recall actually every doing that.

5.  If communication is the challenge, focus the communication, make it count, and minimize unnecessary communication that just sucks up bandwidth.  The best way to do that is laser-like focus that fiercely attacks each challenge and finishes it before moving on to the next.  Thus was born the Agile Backlog on my teams.

I’m a compulsive list maker.  I always thought of them as ToDos, I made them long life documents, and I constantly evaluated priorities, deferring as much as possible until later.  Imagine my surprise the first time someone asked to see my “Agile Backlog” and I had no idea what they were talking about.  After a laborious explanation, I trotted out the “ToDo” for that project and they were invariably overjoyed.  Nothing like fancy terminology to elevate an obvious idea to sainthood, lol.

My role in the meetings was to present the near-term portion of my Todo, um, I mean the Agile Backlog, to the team.  Keep them focused at 2 week intervals was and is my mantra.  Keep dragging the highest risk most poorly understood items to the front of the Backlog so they get hammered down and solved.  That latter I got from a book on military strategies and was credited to Rommel, the Dessert Fox, who always believed on focusing his guns on his most dangerous adversary on the battlefield, moving to the next most dangerous, and so on.

6.  Make it clear with pictures.  UI Mock ups and Storyboards beat pages of narrative time and time again.  People hate PowerPoint, but that’s usually because they didn’t consider the alternative of reading a 70 page document that accomplishes the same purpose.  I am a big believer in building the UI first to this day, so we can argue usability and understand what the underlying engines will be called on to do right from the start of a project.

7.  Code Reviews.  I always made my developers present their major subsystems twice.  First was an architectural review before much code had been written.  Here’s the problem we’re trying to solve, here’s how we’ll solve it, here there be dragons, here we’re not so worried.  This was done in the morning meetings and everyone chimed in with thoughts. Everyone got to hear the underlying assumptions and could squawk if they saw a bad one.  The second meeting was a demo meeting when whatever it was got to “Beta” quality and a “Here’s what worked and what didn’t” if there was no demo.  The what worked and what didn’t often wound up being a dive into the code.

8.  Interactive Middle-Out Programming.  That curious phrase is one I had way back in my distant past.  I was greatly enamored and possibly warped by the first computer language I ever learned:  LISP.  That phrase referred to building up the “bones” or what I called the scaffolding as much as possible before adding the meat.  Don’t insist that everything be finished before you connect it all up.  Connect it up with dummy responses at first and then build out the most critical and highly traffic portions next.  Fill in the details after that.  Most of all, keep something working every single build.  This was the precursor to the Continous Release mindset that we see today.  It’s the beginnings of Minimum Viable Products.

I always presented roadmaps to my management and to customers.  My goal in doing so was twofold.  First, I wanted them to get used to the idea that releases are small potatoes.  Don’t get hung up on what’s in a release, worry about the longer term vision.  Most customers are extremely understanding of that and much more willing to take a lesser product now if they’re sure you’ll eventually get where they need you to be.  Second, I always asked a lot of prioritization questions in those meetings and took every opportunity to defer things that didn’t seem high priority to later releases.  We did this right from my very first startup, so I guess we were early to the MVP bandwagon.

9.  Embrace Change.  Software is the most malleable medium in the engineering world, yet it can be brittle when timeframes are too short.  What you can’t do is ignore the inevitability of change.  We learn new things every day that can result in change.  We can fear change, or we can embrace it as opportunity.  So many aspects of the methodology I’m describing help you to embrace change when you need to:

–  Keeping the Backlog short-term focused means you can churn the heck out of the part the team hasn’t visited yet with impunity.  Re-prioritize.  Add.  Delete.  Most of all, Learn and React.

–  Middle Out Programming surfaces weakness in the interconnecting structure, the architecture, sooner.  So does UI prototyping.  Ignore the details that are not costly to change and focus on validating what is.

–  Small Teams of Uber Developers are inherently more able to change.

10.  Communicate Face to Face.  Make any documents as temporary as face to face communications.  In fact, make them only as needed to facilitate the face to face.  The software is the only long-term document to worry about.

11.  Lead, Don’t Manage.  Sell, Don’t Tell.  Everyone has to be sold.  Your team, the business side, and the customers.  Don’t hide out and expect the final product to be so dazzling you won’t have to sell.  Don’t hide behind your title secure that your people have to do what you tell them.  As soon as you get the idea, go to all your sounding boards.  As it resonates, grow that audience rapidly.  Make each meeting a learning experience on how to sell the next audience even better.  When people are sold, they become passionate.  Nothing is more valuable to the team than passionate talent.

12.  Don’t Prematurely Optimize, But Manage Technical Debt Consciously.  Middle out programming encourages the avoidance of premature optimization.  Always code it up as quickly as you know how.  But know as best you can where you think changes will have to be made.  And in so knowing, know how hard those changes will be.  If the write bones are there, the changes are confined inside particular internal organs.  If we have to change all the bones, every organ will be impacted. You don’t want Technical Debt in your bones because it becomes pervasive in a hurry.  A little technical debt in the organs is fine and can be dealt with quickly when the need is proven.

13.  Do Post Mortems and then Experiment.  After every release, we’d do a post mortem on our productivity.  What worked, what didn’t, what were the problems.  Then we’d ask for ideas on how to change.  We’d pick one or two of those and implement them on the next project.  Then, at that project’s post mortem, we would evaluate their efficacy and decide whether to continue the practice or not.

14.  Be a Software Factory, Not a Release Workshop.  I like this one to be the capstone of the principles I’ve used to guide my teams over the years.  You want everyone on the team as well as the rest of the company to think of the team not in terms of each release, but in terms of their efficacy as a Software Factory.  No competitive war is won with a single release.  No market is dominated by a single release.  Rather, it is the ability of the team to be a better Software Factory than any they compete with that wins the day.  If they can turn the release crank faster, if they can anticipate what customers want better, if they can deliver higher quality, and if they can do some combination of that more cheaply than the competition, they’re doing everything that can be expected of a Software Development Team to win the war.

Many types of investment in Software Development have to be understood in these terms because they can never be justified for a single release.  If your CEO insists on being exclusively release focused, he is going to have you mostly chasing the puck instead of skating to where the puck will be.

Today’s Agile:  Lean Manufacturing

I’ve followed those 14 tenets almost from my start.  They were certainly completely baked into my software development efforts by the Quattro Pro days, and I haven’t found much need to add to them since.

I can’t decide whether it’s ironic or inevitable, but today I am doing many of the same things I had focused on for developers for the CNC Manufacturing world.  Coplien and Scrum Founder Jeff Sutherland comment that Scrum was inspired by the Toyota Production System.

I knew nothing of Toyota when I created my methodologies (and have carried on without spending too much time on Agile or Scrum either).  I did what made sense to me based on the influences I’d had as I’ve explained.  But my bootstrapped company, CNCCookbook, is intimately involved with the CNC (Computer-Controlled Machine Tools, 3D Printers, and the like) Manufacturing World, so it was probably inevitable that I would eventually write a series of articles on Lean Manufacturing.

The series is not finished yet, but all the key concepts are there.  I can absolutely see similarities between Agile/Scrum and Lean Manufacturing, but with that said, I find them more cousins than siblings.  The Toyota work was done quite some time ago.  It’s lessons are still quite relevant to manufacturing, but I believe that what we (I) have learned about Agile methodologies are relevant to manufacturing.  CNCCookbook is currently developing a new product called G-Wizard ShopFloor that will bring that to light in a modern collaborative environment that emphasizes these hybrid methods.

The first “grainy photos” from ShopFloor are starting to come into focus, the UI prototype is done, we’re starting to show it to a few friendlies and the interactive middle out programming process is fully underway.  I’m having a lot of fun with it and can’t wait to see if the manufacturing world can benefit as much as software development has from these techniques.

I’m really having fun with it!

Posted in saas | 6 Comments »

Authentication as a Service: Slow Progress, But Are We There Yet?

Posted by Bob Warfield on July 11, 2014

BankVaultSmallAuthentication as a Service solves a problem every Cloud Developer, mobile or desktop, has to solve.  As one player in the space, AuthRocket, puts it:

Do you really want to write code for users, forgotten passwords, permissions, and admin panels again?

To that I would add, “Do you really want to have to be a world class expert on that stuff to make sure you don’t leave some gaping security hole out of ignorance?”  I think the answer is a resounding, “NO!” to both questions.  Why do it in this world of Agile Development, Lean Startups, and Minimum Viable Products?  It’s one of those things everyone does (and should do) pretty much the same way from a user’s perspective, so there is no opportunity for differentiation.  You have to do it right because the downside of security problems is huge.  You have to do it right up front to protect your customer’s data and your investment (so nobody gets to use your products for free).  There’s basically very little upside to rolling your own (it’ll only slow you down) and tremendous downside.  Hence, you’d like to buy a service.

I keep going around this block for my own company’s (CNCCookbook) products, and I surely would like to get off that merry g0-round.  I wanted to buy this some time ago, and have written about it for quite a while.  For example, in an article I wrote 4 years ago on PaaS Strategy (Platform as a Service), I suggested login would be an ideal service for a pass to offer with these world:

Stuff like your login and authentication subsystem.  You’re not really going to try to build a better login and authentication system, are you?

I sound just like AuthRocket there, don’t I?  I’m sure that’s not the earliest mention I’ve made, because I’ve been looking for this stuff for a long time now.  As I say, I had to roll my own because I couldn’t find a good solution.  I would still like to replace the solution that CNCCookbook uses with a nice Third-Party service.  I only have few very generic requirements:

–  It has to offer what I need.  Basically that’s Email + Password login with all the account and forgotten password management interactions handled for me.  It would be very nice if they do Federated Login using the other popular web services like Amazon, Facebook, Twitter, Google, or whatever.  It would also be very nice if it could do 2 factor login.  The latter two are optional.

–  It has to work well.  I judge this by who has adopted it and how it is reviewed.

–  It has to be here for the long haul.  I’ll judge this by size of customer base and quality of backers.  AuthRocket, for example, is still at the invitation-only Beta stage.  That’s too early for me.  I have mature products and don’t want to have to change out this service too often.

–  It has to be easy for me to access the API’s.  I prefer a nice RESTful API, but I will take a platform-specific API for my chosen development platform: Adobe Flex.  And no, I don’t want to debate that platform, it has worked fabulously well for me, the products are mature, and I am not looking to switch.

–  It has to be easy to tie it back to securing my data in the Amazon Web Services Cloud.

–  Optional Bonus:  It helps me solve the problem of disconnected data access.  My apps are Adobe AIR apps.  You download and can run without a web connection for a period of time.  This is important to my audience, but means I’ve got to use data models that keep local copies and sync with the Cloud when they get connected.

While my apps are not yet available on iOS or Android, all of those things are almost exactly the same problems any Mobile App developer faces.  Therefore, this ought to be a hotbed of activity, and I guess it is, but so far, I still can never seem to find the right solution for me, and I don’t think I’m asking for anything all that crazy.  But, I have yet to find a solution.  Let me tell you a little bit about my 2 most recent near misses.

Amazon Cognito

I was very excited to read about Amazon’s new Cognito service.  At CNCCookbook we’re big Amazon believers, and use all sorts of their services.  Unfortunately, at least until Cognito, they didn’t really have a good service for solving CNCCookbook’s authentication problems.  They had IAM, which is a very complicated, very heavy-weight, very Big Corporate IT kind of solution.  It looked kind of like maybe you could do it if you had to, but you’d still wind up writing all the darned password management stuff and it looked like it was going to be a real ordeal.  Mostly, I think of IAM, as the tool used to define roles for how broad classes of users can access the various other Amazon offerings.  I wanted another service of some kind to be the sort of simpler, friendlier, front end to IAM.  Enter Cognito, and it sure sounded good:

Amazon Cognito lets you securely store, manage, and sync user identities and app data in the AWS Cloud, and manage and sync this data across multiple devices and OS platforms. You can do this with just a few lines of code, and your app can work the same, regardless of whether a user’s devices are online or offline.

You can use Amazon Cognito directly from your mobile app without building or maintaining any backend infrastructure. Amazon Cognito handles secure app data storage and sync, enabling you to focus on your app experiences, instead of the heavy lifting of creating and managing a user data sync solution.

A guy like me loves the part about, “You can do this with just a few lines of code” followed by “without building or maintaining any backend infrastructure.”  Now that’s what I’m talking about, I gotta get me some of this!

It’s nearly all there:

–  Amazon is an outfit that can be trusted for the long haul.

–  REST API’s are no problem, that’s how Amazon prefers to operate.

–  Tie back to other Amazon Web Services?  Puh-lease, who do you think you’re talking to, of course one Amazon Service talks to the others!

–  Sync?  Yeah, baby, that’s what Cognito is all about.  More potential time savings for yours truly.

Oops, just one little shortcoming:  it only does Federated Login via Amazon, Facebook, or Google.  That’s cool and all, but wheres my Email + Password login so I can seamlessly move customers over to it?  Maybe I missed it, maybe it’s coming, or maybe Amazon just doesn’t think it’s important.  Can I live with forcing my users to make sure they have either an Amazon, Facebook, or Google account?  Yeah, I guess maybe, but we sell a B2B app and it sure seems kind of unprofessional somehow.

Amazon, can you please fill this hole ASAP?

Firebase

I hear fabulous things about Firebase, I really do.  People seem to love it.  It’s chock full of great functionality, and on the surface of it, Firebase should fit my needs.  Yet, when I dig in deep, I find that the login piece is kind of a red-headed stepchild.  Yeah, they advertise Email + Password Login, and they even tell you how to do it.  But there’s no RESTful API available for it.  They list all the right operations:

–  Login, and returns a token
–  Create a new user account
–  Changing passwords
–  Password reset emails
–  Deleting accounts
etc.
However, it appears that those things are handled by a client library which is in a very dev platform specific format.  If you use one of their chosen platforms, it’s ok.  If not, you can only use their rest API’s for the Cloud Database–no login functionality.  That’s going nowhere for me.  It would’ve been so much nicer had they packaged what’s in the client library in their Cloud and provided RESTful API’s for the functions I’ve listed.  As I told them when I made the suggestion, that makes their offering accessible to virtually every language and platform with the least effort for them instead of just the few they support.
Conclusion:  Crowd Sourcing?
Hey, I’m open to suggestions and the Wisdom of the Crowd.  Maybe someone out there knows of a service that meets my requirements.  They seem pretty generic and I’m frankly surprised I still can’t find such a thing after all these years of building almost anything you can imagine as a service.  We’re not very far away from it.  Either Amazon or Firebase could add the functionality pretty easily.  I’m hoping maybe I’ll get lucky in the next 6 months or so.  If anyone knows the right people in those organizations (or their competition), pass this post along to them.

 

 

Posted in bootstrapping, business, cloud, mobile, platforms, saas, service, software development | 3 Comments »

Don’t Bury the Map With the Treasure: Thin Clients Trump Apps in Walled Gardens

Posted by Bob Warfield on July 10, 2013

FeedlyBugOne of the questions every SaaS company will have to be able to answer for their customers is, “What happens if you go under?”  It’s actually a fascinating question, and one you have a chance as a vendor to think about and turn to your advantage.  For example, one of my SaaS ventures was Helpstream.  We had the unpleasant experience of being shut down by our VC’s shortly after the 2008 crash, but we tried to do well by our customers.  As it turned out, our architecture made it very straightforward for us to offer those folks the chance to host their own Helpstream instance and keep going rather than have to stop cold turkey.  There are still customers live on the software as a result.  I won’t go into all the details of how this was accomplished, but suffice it to say our architecture made us very nimble about being able to create multi-tenant apartment complexes that could house anywhere from 1 to a couple of thousand tenants on standard Amazon EC2 + S3 infrastructure.  Thus it was trivial for us to set up a customer as their own tenant in their own apartment house and hand them the keys.  This is not something you could say about something like, say, Salesforce.com, or many other SaaS offerings.  Building on a commodity cloud like Amazon can have its virtues.

In the perpetual on-premises license days, we had source code escrows.  In the SaaS/Cloud era, it makes sense to codify what happens in the event of a dissolution of some sort.  As the Helpstream example shows, it’s possible to do something that makes enormous sense for customers and thereby give them a greater sense of security, something that the Cloud is not often known for.

Unfortunately, things also go on in the Cloud that have nothing to do with a particular vendor, but that actually make things much worse for customers.  I present the example of Feedly and the Apple App Store.

As most of you will know, Google discontinued Google Reader, forcing those of us who need such a thing to seek alternatives.  I looked at a good half dozen during the warning period and eventually settled on Feedly.  Let me be clear that this is still not a decision I regret, but I am forced to endure a not so pleasant aspect of the way Feedly works on my iPad.  There is a problem in that Feedly is set up to seamlessly transfer you from Google Reader to Feedly.  That part is good.  What is less good is that Google changed some aspects of the API and created a little problem for the Feedly app.  Feedly works great for me on my desktop, because I can access it via web browser as a thin client.  It is dead to me on my iPad because of this problem.  Feedly mistakenly thinks it is overloaded with users, a surprisingly plausible story in the wake of Google Reader shutting down.  In fact, this is not the case.  There is simply a bug that causes the iOS Feedly app to mistakenly report this problem.

Now here is the problem:

Since iOS is a walled garden, and Feedly has to wait until Apple approves a fixed version of the app, they are stuck.  It’s been 7 days and the app still doesn’t work and a fix has not been approved.  As my headline says, the map is buried with the treasure because Apple is presenting them from fixing a very obvious problem.  Feedly has no real answer for this, and Apple isn’t telling them an ETA on approval either.  It’s hard to be impressed with either Apple or Feedly based on how all of this is rolling out.  You’d think whatever process Apple uses would be aware of how many people use Feedly (it’s millions) and could find a way to expedite an obvious fix.  Apparently the Monarchy of Cupertino cannot be bothered with such mundane details as customer happiness.

Meanwhile, I have to ask myself, “Why can’t I run the Feedly thin client in the Safari browser on iOS?”  That would be so handy right about now.  Yet, they seem to have been at pains to ensure that if you are on an iPad, you surely must use their app and are to be prevented from accessing the thin client that works so well on my desktop and that would have prevented this nuisance.

Folks, the next time you’re using your tablet and you go to some website and it offers to download an app, skip it.  That app is not going to improve your user experience enough to be worth the trouble.  You are only going to encourage them not to keep their thin client working well on your platform.  And someday, you may wish the map hadn’t been buried with the treasure the way the Feedly guys did it.  Don’t frequent the Walled Garden.  Don’t encourage it at all unless you absolutely must.

This was all tragically avoidable, and I hope Feedly will take note and pave the way for their thin client to work on iOS so the next time they don’t have to wait on Apple.  Those of you at other companies, don’t let this happen to your customers!

Posted in apple, cloud, saas, service, strategy | 3 Comments »

Big Data is a Small Market Compared to Suburban Data

Posted by Bob Warfield on February 2, 2013

BurbsBig Data is all the rage, and seem to be one of the prime targets for new entrepreneurial ventures since VC-dom started to move from Consumer Internet to Enterprise recently.  Yet, I remain skeptical about Big Data for a variety of reasons.  As I’ve noted before, it seems to be a premature optimization for most companies.  That post angered the Digerati who are quite taken with their NoSQL shiny objects, but there have been others since who reach much the same conclusion.  The truth is, Moore’s Law scales faster than most organizations can scale their creation of data.  Yes, there are some few out of millions of companies that are large enough to really need Big Data and yes, it is so fashionable right now that many who don’t need it will be talking about it and using it just so they can be part of the new new thing.  But they’re risking the problems many have had when they adopt the new new thing for fashion rather than because it solves real problems they have.

This post is not really about Big Data, other than to point out that I think it is a relatively small market in the end.  It’ll go the way of Object Oriented Databases by launching some helpful new ideas, the best of which will be adopted by the entrenched vendors before the OODB companies can reach interesting scales.  So it will be with Hadoop, NoSQL, and the rest of the Big Data Mafia.  For those who want to get a head start on the next wave, and on a wave that is destined to be much more horizontal, much larger, and of much greater appeal, I offer the notion of Suburban Data.

While I shudder at the thought of any new buzzwords, Suburban Data is what I’ve come up with when thinking about the problem of massively parallel architectures that are so loosely coupled (or perhaps not coupled at all) that they don’t need to deal with many of the hard consistency problems of Big Data.  They don’t care because what they are is architectures optimized to create a Suburb of very loosely coordinated and relatively small collections of data.  Think of Big Data’s problems as being those of the inner city where there is tremendous congestion, real estate is extremely expensive, and it makes sense to build up, not out.  Think Manhattan.  It’s very sexy and a wonderful place to visit, but a lot of us wouldn’t want to live there.  Suburban Data, on the other hand, is all about the suburbs.  Instead of building giant apartment buildings where everyone is in very close proximity, Suburban Data is about maximizing the potential of detached single family dwellings.  It’s decentralized and there is no need for excruciatingly difficult parallel algorithms to ration scarce services and enforce consistency across terabytes.

Let’s consider a few Real World application examples.

WordPress.com is a great place to start.  It consists of many instances of WordPress blogs.  Anyone who likes can get one for free.  I have several, including this Smoothspan Blog.  Most of the functionality offered by wp.com does not have to coordinate between individual blogs.  Rather, it’s all about administering a very large number of blogs that individually have very modest requirements on the power of the underlying architecture.  Yes, there are some features that are coordinated, but the vast majority of functionality, and the functionality I tend to use, is not.  If you can see the WordPress.com example, web site hosting services are another obvious example.  They just want to give out instances as cheaply as possible.  Every blog or website is its own single family home.

There are a lot of examples along these lines in the Internet world.  Any offering where the need to communicate and coordinate between different tenants is minimized is a good candidate.  Another huge area of opportunity for Suburban Data are SaaS companies of all kinds.  Unless a SaaS company is exclusively focused on extremely large customers, the requirements of an average SaaS instance in the multi-tenant architecture are modest.  What customers want is precisely the detached single family dwelling, at least that’s what they want from a User Experience perspective.  Given that SaaS is the new way of the world, and even a solo bootstrapper can create a successful SaaS offering, this is truly a huge market.  The potential here is staggering, because this is the commodity market.

Look at the major paradigm shifts that have come before and most have amounted to a very similar (metaphorically) transition.  We went from huge centralized mainframes to mini-computers.  We went from mini-computers to PC’s.  Many argue we’re in the midst of going from PC’s to Mobile.  Suburban Data is all about how to create architectures that are optimal for creating Suburbs of users.

What might such architectures look like?

First, I think it is safe to say that while existing technologies such as virtualization and the increasing number of server hardware architectures being optimized for data center use (Facebook and Google have proprietary hardware architectures for their servers) are a start, there is a lot more that’s possible and the job has hardly begun.  To be the next Oracle in the space needs a completely clean sheet design from top to bottom.  I’m not going to map the architecture out in great detail because its early days and frankly I don’t know all the details.  But, let’s Blue Sky a bit.

Imagine an architecture that puts at least 128 x86 compatible (we need a commodity instruction set for our Suburbs) cores along with all the RAM and Flash Disc storage they need onto the equivalent of a memory stick for today’s desktop PC’s.  Because power and cooling are two of the biggest challenges in modern data centers, the Core Stick will use the most miserly architectures possible–we want a lot of cores with reasonable but no extravagant clock speeds.  Think per-core power consumption suitable for Mobile Devices more than desktops.  For software, let’s imagine these cores run an OS Kernel that’s built around virtualization and the needs of Suburban Data from the ground up.  Further, there is a service layer running on top of the OS that’s also optimized for the Suburban Data world but has the basics all ready to go:  Apache Web Server and MySQL.  In short, you have 128 Amazon EC2 instances potent enough to run 90% of the web sites on the Internet.  Now let’s create backplanes that fit a typical 19″ rack set up with all the right UPS and DC power capabilities the big data centers already know how to do well.  The name of the game will be Core Density.  We get 128 on a memory stick, and let’s say 128 sticks in a 1U rack mount, so we can support 16K web instances in one of those rack mounts.

There will many valuable problems to solve with such architectures, and hence many opportunities for new players to make money.  Consider what has to be done to reinvent hierarchical storage manage for such architectures.  We’ve got a Flash local disc with each core, but it is probably relatively small.  Hence we need access to storage on a hierarchical basis so we can consume as much as we want and it seamlessly works.  Or, consider communicating with and managing the cores.  The only connections to the Core Stick should be very high speed Ethernet and power.  Perhaps we’ll want some out of band control signals for security’s sake as well.  Want to talk to one of these little gems, just fire up the browser and connect to its IP address.  BTW, we probably want full software net fabric capabilities on the stick.

It’ll take quite a while to design, build, and mature such architectures.  That’s fine, it’ll give us several more Moore cycles in which to cement the inevitability of these architectures.

You see what I mean when I say this is a whole new ballgame and a much bigger market than Big Data?  It goes much deeper and will wind up being the fabric of the Internet and Cloud of tomorrow.

Posted in business, cloud, data center, enterprise software, multicore, platforms, saas, service | 2 Comments »

Can We Ignore Churn Early On at a SaaS Company?

Posted by Bob Warfield on January 10, 2013

Jason Lemkin has my juices flowing again.  He’s published a blog post with the suggestion that you should ignore churn and length of sales cycle as key management metrics when a SaaS company is young.  I’m with him on the Sales Cycle–it’ll be all over the map in the early days.  But on churn?  Nope, I am diametrically opposed.  In fact, I am so opposed to the idea of ignoring Churn that I’m going to have to get downright Medieval on the idea.  It’s going to be a bit of rant:

Churn is good, churn is right, it clarifies and cuts through to the essence of the evolutionary spirit…

Oh wait, that’s Gordon Gecko talking about Greed.  Let’s get back to Churn and why I think it’s a huge mistake to ever ignore it for any stage SaaS company including the very earliest.  I will extend this to any company that sells subscriptions to anything, and not just SaaS software companies.

First thing I want to acknowledge is that Jason is very clearly speaking about SaaS companies that are similar to his Echosign experience.  He talks about things like 7 figure SaaS deals.  For companies like that, who regularly do 7 figure deals and who are VC-backed, he is closer to being right, but I still don’t believe it is good advice for those companies to ignore churn.  Here’s why:

You can sell software that isn’t good enough to get people to renew

Jason says, “Because SaaS done well, is sticky … and once you get a Great VP of Client Success, Your Churn Will Go Down.”

(The boldface is his.)

That argument became circular right at the point where we stipulated that “SaaS done well, is sticky.”  You won’t know if you did SaaS well if you ignore Churn because you can sell software that isn’t good enough to get people to renew.

Jason seems to use the ability to close the deal as the litmus that the software must be good enough to be likely to renew simply because it sold in the first place.  This only makes even a little sense for big ticket sales so this is where Jason raises the 7 figure note, but it is still a circular argument.  Yes, closure of the sale means the problem being solved is sufficient to warrant a 7 figure expenditure.  Yes, the Sales Cycle around a 7 figure expenditure means there was some diligence done on the software.  And yes, Jason’s experience was that his company and likely others he talked to had low churn without trying.

Unfortunately, there is a simple existence proof that this is not always the case–there is tons of Enterprise Shelfware out there.  Companies bought it and never installed it.  Or they bought it, intalled it, and nobody would use it.  It’s even more common for the more expensive software because some centralized decision making organization wants to impose a solution on the troops and the troops aren’t having any.  Or some change rendered the software moot.  There are companies who make their living coming in to find what you’re not using any more so you can quit paying for it.  Sure, you should know about this well before the renewal date comes up, and you should figure out how to get past it, but whose job is that in an early stage startup?  The Sales Guy is off closing the next deals and calling on all of his minions to help sell more ASAP.  If the CEO doesn’t call out Churn as a top priority, it won’t get done.

Come on, we’ve all bought a subscription to something we didn’t renew.  It’s one reason companies make it so hard to cancel–because it happens so often.

Before going on, every Exec Staff Meeting needs to do a Customer Success Review right after the Sales Pipeline Review every single week.  If you don’t have a VP of Customer Success, get your VP of Prof Svcs to do it.  You need to know the status of every customer in implementation (roughly corresponding to sales “prospects”), what the issues are, and when is the go-live (roughly corresponding to when sales will close the deal).  The review must also cover the status of everyone live including any problems being reported.  Do it every week just like the Sales Pipeline Review.

Now let’s consider a different kind of SaaS company.  Something more like an SEOMoz or perhaps a Marketo.  They don’t charge 7 figures.  SEOMoz doesn’t sell many seats into an org and the seats are cheap.  Marketing Automation companies have this problem that if they let customers pay for them monthly, the customers will turn the service on and off and only buy it when they need to refill the lead pipeline.  There is ample possibility in such lower price lower friction scenarios to sell a product where everything was hunky dory during the Sales Cycle, the deal closed, they went live, they even used it a bit, and then they decided it wasn’t helping.  And they didn’t renew.  And you got horrendous churn.

Jason somewhat acknowledges this when he says it is more important to consider Churn at Freemium startups.  That’s a conflation.  It is more important to consider Churn at startups with lower average deal sizes, whether or not they employ a Freemium model.  For the reasons I mention above and below, it is still important to consider even with large deal sizes.

Failing to make renewal the path of least resistance

I am a big believer in what I call the “Gas Pump Theory of UX Design”.  People take the path of least resistance.  At most gas stations in the US, people read left to right, so they put the most expensive grade of gas on the leftmost button.  Or they stick the cheapest grade in the middle, out of order.  If you’re not thinking about what you’re doing, you just bought their highest margin product.  So it is with renewal, especially on subscription products that are not absolutely mission critical.

Companies these days are reasonably focused on the Growth Hacking associated with web site conversions and landing pages.  It uses this path of least resistance a lot, and Growth Hacking gets the business.  But I wonder how many are focused on Growth Hacking to keep the business?  Since Saas compounds, this is very valuable Growth Hacking indeed.  Put another way, we often hear things like it costs 7X more to get a new customer than to get more revenue from an existing customer.  Note:

If your existing customer doesn’t renew they are no longer a customer.

If that happens, you just spent that 7x or some such to replace that revenue because you failed to make renewal the path of least resistance.  You just did the complete opposite of the compound growth SaaS is justifiably famous for.  You just invested the bulk of the expenses you will ever have around that customer while limiting the lifetime value of the customer to the lowest it can ever be because you weren’t worried enough about Churn.

Doing it right means worrying about Churn enough that a new Sales Cycle is to be spun up to ask for the renewal sale in time to get it done.  That Renewal Sales Cycle can mean anything from sending a Rolex-clad Scratch Golfer straightaway to Customer X’s Headquarters to meet with the CIO to starting a drip email campaign to having the product itself remind you the clock has started counting down.  It can mean having a “man overboard” promotion that fires up if the customer is more than X days late with the renewal.  You might choose to be proactive and offer the discount for early renewal.  If you plan to raise prices soon, something every young SaaS company should be looking at annually, time that so that it happens right after the quarter where the largest number of customers need to renew.  Then go talk to them before that happens and give them a sweetheart deal.  You’ve got the old Colombian lead (we’re raising prices) or silver (renew early and get a deal) working in your favor.

BTW, customers don’t like it if you only call them when you want more money.

This Renewal Sales Cycle needs all the same Growth Hacking expertise your original sales need.  At Callidus, the Sales Rep that closed the deal originally was responsible for the Customer’s continued satisfaction.  Consider doing the same until you can afford to have a handoff Customer Success Rep.  Make it that person’s responsibility to secure the renewal and quota them on it.

Don’t wait for the all too common scenario where you get to your renewal anniversary for the original customers and golly, churn looks high.  But someone says, “Let’s wait a bit, those were some of the first customers, they’re not telling us much about why, and they probably just weren’t a good fit.”  So you wait another quarter or two and eventually get to the part of the cycle where a surprising number of customers didn’t renew and then you’ll wish you’d known why and fixed it a lot earlier.

Churn is a measure of Customer Satisfaction.  Every Churned Customer is a Bad Reference for your Company and Products.

One could argue Churn is the only Customer Sat Metric that really matters.  It’s the one where the customer is putting their money where their mouth is.  As an aside, there’s another good one where you call them up and tell them you need to raise your prices, but that’s another story.

A Churn Rate that’s too high means low customer satisfaction, and that ultimately goes directly to your ability to close new customers who try to speak to these old non-renewing customers or customers who barely got up the gumption to renew about your product.  The non-renewers are going to be the worst form of reference.  They’ll say things that are friendly and happy on the surface.  They won’t directly shoot you down in most cases.  They’ll just opine that, “Great product, but didn’t quite solve our problem.”  Like any reference call, there’ll be an undercurrent to the tone that makes your Spidey Senses tingle.

Worse, if you are not proactively all over Churn, you’ll inadvertently put prospects in touch with customers you thought were happy, but that are actually not going to be renewing.  They may not even realize it yet, but they won’t be able to articulate a strong enough case for the product because somewhere in their gut they know there are problems.

Everyone, including Jason, recommends you commit almost unnatural acts to ensure the success of your first reference customers.  If they don’t renew, they are not successful.  If you gave them the software or made it so ridiculously cheap, they didn’t really renew either.  Not in any meaningful way.

Every Churned Customer is a Bad Reference for your Company and Products.

Churn is at the Bad End of Compounding

One of the things we love about SaaS is that it compounds.  But Churn is at the Bad End of Compounding.  It cuts off the compounding and reduces it to linear growth at the absolute worst time–the latest possible time before the customer would’ve paid in more revenue.  That’s the point where the line on the revenue graph that represents compound growth is the furthest from the line that represents linear growth.  As I’ve already mentioned, it’s the point where you’ve invested the most in the Customer for the least return.

CEO’s, let’s be careful out there.  A customer is a terrible thing to waste.  Don’t let them Churn.  Renewals are not an entitlement, they are something you earn.

Posted in business, saas, saas business venture, strategy | 2 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 348 other followers

%d bloggers like this: