Black Swans and business planning

Must say I'm enjoying the book, and being cheeky, I recognise much therein that support my own attitudes:

Accept that you do not know (much / anything).

Plan for the unplanned.

But alas, radical attitudes are not popular when planning a new product's early life. Planning is important etc. The process usually goes along these lines:

1. Have a board meeting, sit and discuss for hours what users "you think" your product is for, what problem it solves and how it's going to be used. Much back and forth, sometimes heated arguments flying simmering in the end down when all wants to go home and some consensus about the target customers is reached.
2. With that set you roll up sleeves and plan features, colour, packaging, distribution partners, timelines...
3. Create cost and investment budgets, estimate income over time, calculate backwards to find a nice NPV for your investors on the board. Bliss and much strokes from board members.
4. Go and implement.

Points 2 to 4 are easy, stuff that any MBA should know well. An air of very professional and business like activities ensues.

What everybody forgets is that point 1 is a huge, unbelievable, amazingly risky bet.

And even if the same MBA should know that task number one is to minimise risk, that first jump-to-conclusion bet-the-farm decision is often conveniently brushed under the carpet. The mere thought of not having any basis for all that nice planning is unbearable.

What to do?

Obviously plan for the unplanned instead (software example follows):

Accept that you do not know who your customer will be nor for what and how your potential customers wants to use it. Focus on the creation of some suggestive examples and let them decide, whoever they might be. Extreme Business Planning.

Do not focus much on what features to add (that would require an up-front decision as to who and how it's going to be used), but how to structure and architecture the code (or product) so any kind of feature can be added one day. And that fast, because when a customer finds he needs a non-existing feature you'd better have it in there asap. And without much fuzz bug wise either.

Do not focus much on the path to market, accept the unplanned-for channels and partners that could appear. Focus on making the product (pricing, technology, value added opportunities for third parties) interesting for many channel partners, and please, no limits to what you'd define as channel partners.

Obviously this comes naturally if you are tinkering with some broad technology, something horizontal. Thing is that such a definition is often in the mind of the beholder, so try to think as if your product is in fact a broad technology, a platform even. FaceBook went from narrowly vertical to horizontal and broad - and that, and only that, allowed users to create verticals (as is happening as we speak). Trust your users.

Think "platform", the "products" will manifest themselves later.

But there is a speed-bump out there. A force pushing for the good old scenario of bet-the-farm plus professionally looking plans: The difference in the math used by your investors and yourself, a tad simplified it could go like this:

A professional investor can play the numbers game over a portfolio. They solve the issue by pooling ten of you accepting a 20% chance that you make the right first-step-bet leading to a good return for their portfolio (if two goes ten times and the rest flops completely their initial investment would be doubled).

This would be pretty bad for you, you do not want to live with a 80% chance of complete failure. At that level I'm not sure I would bother getting out of bed in the morning.

But the pressure for you to "decide" up front what customer and how they will use your product will appear in the first meeting with your professional investor. Actually, if you do not spell that out in the Business Plan you forwarded there will probably be no meeting!

This because there is a "truth" out there that you must "solve a specific problem" - and for that the customer and use must be specifically defined up front. This truth is extremely well entrenched and seldom questioned. An extremely dangerous "truth" this one, many build their life around it so tread carefully indeed when questioning it.

Resist the pressure, turn around an make a good case for a "plan for the unplanned" scenario and lower the 80% failure rate up front. A sensible investor might be convinced.

In fact there are sensible investors out there, let me quote Fred Wilson from his latest post:

"I don't think you can build a great product without being a platform."

Spot on.

Comments

[Paul P Magee]

Very, very interesting Sig. For me, in this similar situation, where the plan you described above is make or break is in the marketing of this platform to the hoards of unknown businesses who might use it.

Last week we were discussing getting peoples attention on the very same page - reticular activating system or simply 'pricking up of the ears' getting people to see your generic platform as the place to solve their specific problem is no easy task.

The guy who is looking for a solution to his hospital problems has "pricking up of the ears" when he hears 'Hospital Software' not 'Generic platform'

You could wave a generic platform in front of his face for a very long time and he may not see it.

Until...

You are able to communicate enough examples of your product, through enough stories / metaphors for the guy in the hospital to say - "hey, that's not far removed from the model of a hospital, I wonder if..."

I have not yet worked out what the solution is for my own software, but I am working on something in between generic and specific examples.

Not - "Software for Hospitals"
or "Software for anyone"
but "Software for organisations *like* Hospitals"

(alongside lots of other *like* examples)

Maybe this approach could also help smooth the path with investors. They get their specific examples and also a free stepping stone to unknown additional potential?

I am starting to think that sometimes we have to hide the radical idea inside a more easily digested one to move forwards. Or at least serve it alongside.

Being radical can be a huge hindrance in making progress. It's only *after* your ideas are accepted as self evident you get to bask in being called the great radical genius inventor :)

[sig]

Paul,

agree totally - although have this little nagging idea that there is a "fine" line to balance somewhere, lemme try some examples:

Lego: Delivers sets with instructions to build a specific model, simple too extremely complicated. When my kids were really young I saw them follow the instructions to get to finished model. But soon they ripped them apart and built freely - what I saw was a real good pedagogic system in action, learning the mechanism of the system by building something defined, but when they had that under the skin the real fun started.

Spreadsheets: When I first got my hands on Visicalc I had seen a pro forma P&L / Balance Sheet / Cash-flow output by some big bank system and rebuilt that in a snippet (no template in the spreadsheet mind you!) and never stopped since.

Accounting software: Quicken, Moneydance, Gnucash - been at'em all and never ever started with a template, saw the mere building of my accounts from bottom up as a grand opportunity to rethink / remodel.

So I wonder if not ease to "build" (as in utilise the platform) is where the total focus must be as real life presents so many ready examples anyway. I.e if the "platform" is as easy as a spreadsheet / Lego system then the urge to model something real would be enough...

Not sure though, but slightly drifting in that direction.

[Paul P Magee]

I suspect that there is much learning to be gained from studying the evolution of Ruby On Rails.

Observing how the various channels are adopting and marketing ROR as a tool to build better apps is sure to raise more relevant insights.