Allocations and Decisions

I frequently run into an issue with allocations.  Specifically, an issue with confusing accounting allocations for something that is useful in decision-making.  In accounting, allocations is:

the process of shifting overhead costs to cost objects, using a rational basis of allotment. Allocations are most commonly used to assign costs to produced goods, which then appear in the financial statements of a business in either the cost of goods sold or the inventory asset.

As an example, imagine this classic situation in engineering.  BigCo is developing a new product line.  My kid is 4 and obsessed with potty words, so we'll call it "Product Booger".  Product Booger will cost about $1,000 of RND spending to get ready for market, and once it goes to market, BigCo expects it will sell around 500 units at $20 each.  Each unit will cost $10 to manufacture.  Should BigCo do this project?

Here is the super-basic analysis

If BigCo has the $1000 to invest and doesn't have other investments with a better efficiency ratio, they should do this project.

Now imagine that a super-eager young person comes along with an idea for a product extension based on BigCo product Booger.  Product NoseGoblin is a derivative product that will cost $100 of additional RnD and should sell around 200 units at $16 each.  Each unit will cost $14 to manufacture.  It is safe to assume that NoseGoblin won't cannibalize any of Booger's sales or anything like that. Should BigCo do this project?

Here is this super-basic analysis:

So this NoseGoblin isn't as good as Booger, but it still has a positive return and recommends itself for investment if BigCo's alternatives don't have a better efficiency ratio than 1.0.

Then the accountants catch wind of NoseGoblin.  They decide that it needs to carry a portion of the shared investment from Booger.  Doing a classic revenue basis allocation--allocating the RND spending according to proportional revenue-- Nosegoblin picks up an extra allocation of $242 (at the same time, Booger looks $242 cheaper).  A few months later, a new financial analysis is performed and NoseGoblin's financials look like this:

It is now a negative financial return.  Kill it fast!  Super-eager person's heart is broken.

this what a GIS for "sad super eager person" finds for me

This is not a made up situation.  I have seen this happen.  It gets even crazier when BigCo decides that everybody needs to carry a share of overhead allocations in financial analyses, too.  Suddenly you see stuff like this:

Even though this project doesn't drive any additional SGnA, IT activities, shared technology development, new building construction, etc., GAAP rules require that these allocations get managed in the PNL so they tend to find their way into the financial analysis, too.  Load in things like depreciation, taxes (which are usually so convoluted that trying to estimate the real tax impact of a new product is fool-hardy) and you're ready to start shooting down loads of good projects that fail to meet a corporate hurdle that completely misses the point.

Accounting allocations being used for decision purposes leads to bad decisions.  When we do portfolio analyses, we keep them separate and link the spending through relationships and work hard to identify incremental spending.  Only spending that is truly incremental is relevant in the analysis.

The parable in Tsar Saltan... "Gvidon's Squirrel"

I like to tell my 3 year old stories that are loosely based on Russian Folk Stories that I found in this book.  I take down the gore as much as possible and generally try to shift the jobs that people do to be a little more appropriate for modern times (and make the animals more fit for the desert, where we live).

On story I love to tell is based on "The Tale of Tsar Saltan".  In this story, a young man (Gvidon) ends up distant and unknown to his father (Tsar Saltan).  He helps out a swan, who turns out to be a magic princess and who falls in love with him and does him all sorts of favors.  Every time Gvidon sneaks back to his father's castle in the form of a fly, he comes back with a request for some new and crazy thing that he heard about there.  One example is this one:

 "After he flew back to the island, Gvidon told the swan the story he heard about the remarkable squirrel. Then the prince walked into his courtyard and, lo and behold, there was the singing squirrel, sitting under a fir tree, cracking golden nuts! The prince rejoiced at this and ordered that a crystal house be built for the little animal. He placed a guard there to stand watch and ordered a scribe to record every shell. Profit for the prince, honor for the squirrel!"

Basically, he found himself in possession of a magic squirrel/tree combination.  The tree produced golden nuts (each of which held a ruby inside) and the singing squirrel would go up and collect them, take them down and crack them and stack the riches up in piles.

The part that I love about this story is that Gvidon doesn't just take the riches, he then builds a completely non-value-added organization around those riches.  He establishes a completely superfluous crystal house for the squirrel, he organizes and accounting department to keep score and establishes a management structure that watches the whole thing happen.  

When I tell the story, I keep going.  The guards need management, so an executive structure is organized.  The accounting department eventually branches out into strategy and financial analysis and grows headcount.  Eventually there are organizations built up around selling the rubies and the gold on international markets.  The organization continues to get bigger and bigger and bigger until eventually the tree and the squirrel are at the bottom of the hierarchy, getting bossed around by MBAs and seasoned executives who have been in this business for years.  By the end, Gvidon's entire income is consumed by the organization.

How many times does this happen in the real world?  A start-up comes out with a great business concept and develops a product that is worth buying.  People value the services or the experience and the company starts to take off.  The need to scale and they take on investors, who want to track progress.  Before you know it, it's "Gvidon's Squirrel."

(if you're interested in reading the whole story, I found an online copy here, which is where I found that picture, too. 

The metaphor of the deer

Many moons ago (in college) I was driving on a small, country road in upstate New York ( somewhere around here, if I remember right ).  It was night and it was winter.  A dusting of snow was sprinkling down on the already frozen road, the sides of which were burmed with banks of tight-packed snow and ice with thick forest beyond.

This was college, and I was broke.  I was driving a Nissan Sentra Station Wagon, which was an absolute POS in case you're not familiar with it.

The POS in question

I was going around 60 and came over a hill to discover a deer hanging out in my lane, about half a mile away.  He was a big buck, facing to my left.  I seemed to have plenty of time to work out my options in my head, and it went like this:

a) Swerve around him to the left.  This would bring me into the empty oncoming lane, but I have always heard that a deer will jump forward if frightened, and that would mean he would jump right in front of my car.
b) Swerve around him to the right.  This would bring me right into the frozen snow bank.  Odds were really good that my junky little car would end up in the woods in the middle of nowhere.
c) Jump on my breaks.  The road was frozen and it seemed really likely that the bicycle tires on my car would lose traction and I would end up spinning out in the middle of the road.
d) Get off the gas, steer straight and hope for the best.

Now, it's worth mentioning that I was a truly terrible driver as a teenager.  These scenarios were not academic concepts to me, they were all experienced realities.  I had driven off the road several times (including a roll-over accident that crushed the roof of my car with a tree), I had lost control and entered into flat spins during bad weather, bad road conditions (and honestly sometimes under ideal conditions but bad choices).  I had wrecked 4 or 5 cars by this point IIRC.  I knew my way around crashing a car.

So, I did what they teach you to do in that circumstance.  Without any panicking, I took my foot off the gas and steered toward the right edge of the road.  I knew there wasn't room to get around the deer, but I was hoping he would jump out of the way.  In retrospect, I should have honked my horn, too.

About an hour later the local sheriff was there by the roadside, poking a buck with his foot and pronouncing "yup, he's dead alright.  Do you want to keep him?"

I spent the rest of the year driving a car with a completely smashed up front end, leaking Styrofoam from the bumper (did you know that cheap cars have Styrofoam bumpers??) and with a grill full of fur.

I tried a google image search for "furry bumper" and "fur in my bumper"... I don't recommend it.

There are lots of situations like this.  You can see them coming a mile away, but there isn't anything you can do about it.  In fact, anything you do is likely to make the situation worse.  When you look back at the outcome, it's easy to second-guess, but sometimes the right choice is to limit the downside--not to try to avoid it.

Bad stats -- "good enough"

I'm reading (or really listening to the audiobook during my commute) "Traffic: Why we drive the way we do" by Tom Vanderbilt.  It is a pretty good book and well researched and surprisingly interesting given the pretty dry nature of the material.

This morning, he was discussing what is a "safe road."  In particular, he was talking about small, curvy roads and whether they are made safer when the turns are labeled with reflective posts and recommended speed signs.

Proper signage is optional

Research has shown that the average speed on unlabeled roads is lower than on labeled roads.  The proposed reason is that the unlabeled road is observably dangerous, so drivers are more careful and drive more slowly.  The labeled road lulls drivers into a false sense of security and therefore they drive faster.  His conclusion is that the labeled roads are therefore more dangerous, as evidenced by the higher average speed.

Here's the thing though... average speed doesn't matter!

What matters is the occurrence of a driver entering a turn with a speed that exceeds the combination of his driving ability, the character of the turn (radius, traction, etc.) and the performance of his car.  If the "fly off the road threshold" (or put another way, "bad enough") isn't exceeded, the driver keeps right on going, no matter how close he might have gotten.  The conclusion drawn by the author is therefore baseless.

Further, if we imagine that the presence of the signage increases the average speed but decreases the standard deviation (or more specifically tightens up the distribution in one way or another), then we're probably less likely to hit the bad-enough threshold and have an accident, even though average speeds are higher.  This seems believable, since better information means that people don't have to guess how fast to go through the curve, and they should converge on something similar to the posted, recommended speed.

made with @Risk by Palisade

In the little simulation I did here, we have two distributions.  The blue represents the "no signs" scenario, where the driver has no idea what they're in for and tends to drive slower.  The red represents the good signs scenario, when everybody knows what's coming.  I set the "bad enough" threshold at 40 mph.  You can see that 0% of the good signs people crash, but 1.3% of the no signs people crash.

There is an analogous concept in marketing, called the "good enough" line.  The idea is that people have some threshold for purchase that depends on certain quality vectors.  In a car, for example, a driver might have a minimum requirement for horsepower, seating capacity, gas mileage, etc.  If your car doesn't meet that threshold, that person won't buy it.  If you exceed that threshold, they won't pay any more for the car and you don't monetize the value.  It's all or nothing.  This concept applies to lots of things.  While the car crashes when it exceeds the threshold, the customer buys something when their desire for the product exceeds the threshold.

So here's the problem.  Statistical process control (SPC) is all about removing variability.  Mass marketing and homogeneity of product offering is the way of the world.  What are the actual differences between different Android phones, for example?  As things move toward the red distribution, fewer and fewer outliers will exist in the tail, and fewer and fewer people will reach the purchase threshold for your product.

So the takeaway is that new products should desperately avoid the middle path.  If you're going to put out something new, put out something really new.  Expect most people to dislike it.  What you need is a few people who will like it, and you won't get there if you don't produce the wildly unpredictable product.

Growth and ungrowth - forcing the vote

Over the past 30 years the US economy has grown.

from http://data.worldbank.org/

At the same time, middle class incomes have stayed flat.

from: http://www.advisorperspectives.com/

I found a really great breakdown and analysis of earnings trends at this website.  It's interesting to note that the sources here are not political sources or think tanks.  This is the US census and a couple of investment advisers that have aggregated and charted the census data.

At the same time, there has been considerable growth in the income of middle class women, and some minorities.

http://www.bls.gov/opub/ted/2013/ted_20131104.htm

The majority of middle class men have not been realizing these gains.  Additionally, many recent college grads are not experiencing these gains.  Link to wikipedia on income

There is a significant body of research on happiness that points to the concept that an individual's sense of happiness is a function of how they feel they compare to their self-described set of peers.  When a person looks around at their friends they do a natural, precognitive comparison that establishes happiness on a sliding scale.  In the case of the economy, the rule is similar.  White men are still better off than most ethnographic groups in the US, but when they measure themselves based on growth, they feel left behind (they are left behind in growth).

Lastly, I'll leave this article on the slide of the American Middle class from the NYT.

Now I will make a logically unsubstantiated leap here and posit that a vast majority of Donald Trumps supports are accurately described by the above economic picture.  I believe that Trump's base is built on the frustrations of white men (and those who are close to them and care about them) who have legitimate economic grievances regarding their individual situation.

It is really a shame that Trump is their mouthpiece, however, because his root cause analysis is deeply flawed.  I don't think there are any credible economists out there who would blame illegal immigration for the trends I identified above.  Certainly there are no economists who would blame ISIS or gay rights or a woman's right to freedom from sexual assault or any of Trump's other defining positions.

The shame here is that he a) provides an unproductive distraction to the people who are getting screwed.  They're now getting screwed by him, too.  b) His angry rhetoric is producing a dangerous death spiral in the form of a reactionary populist echo chamber.  c) the result is that everybody who has been experiencing the gains in the economy assumes that those who are left behind are just racist crackpots.  The whole argument becomes illegitimate.

Ironically, the result is very similar to what you see with Black Lives Matter.  White men are not the subject of negative implicit bias and therefore are not systematically and consistently exposed to negative (and often lethal) encounters with the Police can't wrap their heads around the problem.  They look at the movement, find the worst in it, see some looters or rioters and decide the whole thing is bullshit.  Same story, different disenfranchised and marginalized set of experiences.

Metacognition, forecasts and estimating ability

tl;dr: Odds are pretty good that your opinions on everything are worse and more ill-informed than you think they are. Suspend judgment about the ability of others (positive or negative) because it is probably just an echo effect (they're brilliant if they agree with you and stupid if they don't). This is all especially true if you aren't an expert in the field under consideration. Don't apply this logic to others, apply it to yourself first.

Metacognition refers to the act of thinking about thinking. This is the same sort of concept as Freud's superego, or what phenomenologist philosophers call our consciousness. Kahneman might refer to it as "slow thinking".

In general, our brain has two methods for making a decision. By "decision" I mean just about any sort of conclusion about something. There is a fast method that runs ahead and draws its conclusions based on instinct, training, experience and mental shortcuts. The fast method is great for things that we are evolutionarily prepared for and for things where training is effective. Generally training is effective for things that require quick reflexes and that provide immediate, salient feedback. Fast thinking is gut feel and reflexes and is not something we are aware of consciously because it doesn't formulate in language -- it forms in action.

The slow method is what we think of as "thinking". It is logical, it handles new ideas and concepts. It is what we observe as "thought". It presents itself in our language and is shaped by the way our language works. Slow thinking spends a lot of its time confabulating a logical reason why the fast method came up with what it did. A lot of our thought is spent thinking about what we just did and justifying it to ourselves.

This where our ability to forecast comes in. Most of the time, when asked about the future, people immediately have a gut feel. That gut feel is hugely biased (too many forms of bias to go into now). As long as we don't get immediate and obvious feedback that the forecast was wrong, our brain has mechanisms in place to pat itself on the back for another great forecast. Even if the forecast is terrible, if the feedback is subtle or slow, our brain still thinks it did a great job and our metacognition formulates a story to back it up.

Unfortunately, most of the forecasting situations we face in the modern world don't provide immediate and obvious feedback.

This is the reason that we're all bad at estimating our ability. We are best at identifying problems when we have expertise with a subject. The better we are at something, the more capable we are of identifying when we screw it up. Conversely, the worse we are at something, the worse we are at identifying how bad we are. We blithely go along, thinking we're pretty awesome at the stuff we're worst at. Those who are the best at things are also the most aware of their shortcomings.

There are lots of examples of this in the world. I guarantee that Tiger Woods is far more critical of his golf game than a typical weekend duffer. Proof-reading the English language is another great example--if you don't know the rules of grammar very well, then you won't be aware of your errors. Driving is another example where people are notoriously bad at identifying their own skill (except race-car drivers, who are typically very slow drivers on city streets).

So what?

Well, this whole thing applies to business, sure. I think what's really interesting is how much it applies to politics. Look at how many people who know nothing about economics are judging the economic policy pronouncements of the Presidential candidates. Look at how many people who know nothing about police training are hypothesizing about their motives. Look at how many people who know nothing about life experience as a black American are denigrating their perspective. Science would tell us all those people are probably wrong and atribiliously wrong about it because they are even ignorant of their ignorance.

Mutual Admiration Society

Be careful what you hear, it may not have been what was said (or what was meant).

I just finished Malcolm Gladwell's wonderful podcast series "Revisionist History".  There are many interesting threads through the various episodes, but the big meta-theme that loomed large for me was the danger of confirmation bias.  I think it was the second episode  (the one about Saigon) that really hit on the issue.  It is worth the listen.

This problem is giant when you're building a business model.  It is very hard to keep somebody in the room who honestly thinks your idea is stupid, but that person is essential.  I'm not talking about some devil's advocate who will throw out half-baked objections before rolling over and giving you a false sense of accomplishment.  I mean somebody who really thinks the idea won't work and is willing to try hard to articulate why.

"Oh, you're so smart and your new business idea can't fail!"

What comes naturally is that you will find somebody else who is enthusiastic about your idea and will be supportive.  Often this is somebody you already know, and probably you're on friendly terms. After all, that's why you brought the idea to her in the first place.  She'll talk up how great your idea is and you'll recognize what a genius she is for liking your idea.  The two of you will add more friends until you've built up a real, proper mutual admiration society around self-love as represented in lavish praise for one another's brilliance.

"We're all so smart and funny and we're all going to be super-successful!!"

This is great when you're starting out!  Everybody except the most ruthlessly anti-social people need external approval of some kind.  The trick is knowing when it is time to stop bolstering your confidence and adding good news and start sorting out the potential problems, doing your pre-mortems with serious abandon and sorting out the real contingency plans.

At that point, it's essential to realize that sometimes the smartest people in the room are the ones who are willing to say "I don't get it" and your best friends are the ones who are willing to say "that's stupid."

Intelligent Software Building: products, platforms, programs

On a regular basis I see folks who are trapped by the siren song of reusable code.

Now, don't get me wrong.  Reusing code is a wonderful thing, and it's a good goal, but it's important not to get carried away.  There are basically three levels of reuse:

1. Programs - this is when you reuse parts of your own code, on a personal sort of level.  You built these routines and snippets, documented them and like them.  They're something you've done before and know you want to do again, so you were kind and thoughtful to yourself and wrote it in a way that you would recognize.

2. Platforms - this is when you specifically plan for reuse when you're writing something.  Platforms refer to a broad area of capability that is important and that you'll want to build on.  Platforms require serious forethought.  They also require serious documentation and some support.  Typically this is something you will share with other members of your team.

3. Products - this refers to a software platform that you want to make broadly available.  When you create a software product you absolutely have to have clear documentation in and out of your code.  You have to plan for wide deployment and you have to have support people in place.  When changes are made, you have to have a thorough test apparatus in place to understand what the impact of your changes will be on others who have built their software with your product.

especially to yourself...

Be kind to the person who will inherit your code, because often that person is you. 

Many times I have cursed the me of weeks or months ago for leaving a mess for me.  When I'm kind to me, I always appreciate it.  Reuse of your programs is just good practice, and naturally happens when you're writing thoughtful and clean.

After you've experienced those benefits a few times, you'll start dabbling around with platform style reuse.  You'll think "hey!  that little block of code has been so useful to me, I bet others would like it!"  Before you know it, you have a whole set of interconnected things that you've put together and share.  You probably don't have any sort of obligation to support it, but it's fun and you're supporting your own work through the thing anyway, so it just makes sense. 

Ain't nothin' wrong with Platform style reuse.

Where you have to think long and hard is around the Product-style reuse.  This makes sense if your goal is to sell this code as a development tool.  This is something like D3, or Telerik, or the Unreal Engine, or Havok or anything like that.  More often than not, I see this when developers fall in love with their own, potentially reusable programs, assemble them into a platform and then decide the whole world needs it.  You will have tons of support work to do.  You will have to maintain forward and reverse compatibility.  

If this is some sort of exercise in self-love, you need to stop now and slowly back away.  Really, unless you're planning on making enough revenue from this (or if internal facing, saving enough effort) to justify several developers and a testing team, this is just a bad idea.

Sometimes a platform may naturally find demand in the market.  Maybe the platform you built is truly wonderful and well documented and bullet-proof and you really really want everybody talking about how awesome you are... Even then, don't do it unless you have the support staff.  The first time some package you're including gets depricated or MS rolls off some capability you're counting on or any other of a million possible things, you're going to have all those people who were singing your praises on your IM, demanding immediate fixes...

options in the wild: part II

At the very beginning, I did a straightforward ROI type of analysis.  The decision seemed very clear from that perspective.  There was one line that took a little more work to get to, but was half as long and had twice as many windows operating.  It should have moved twice as fast.  Easy choice!

I hadn't considered the uncertainty in the model.

The people in line "d" were long a call option on all of the windows to the right.  If any of the windows from "e" through "h" opened up, they could easily exercise that option by walking over and moving to the new line.  I hadn't thought of that until it happened!

Once window "e" opened up, I sat there considering moving to line "e", thinking they might open up "f" or "g" or "h" and I didn't want to miss that opportunity, even though it meant moving to the back of the line.  I decided I was pot-committed to "b" when the other option in the mix made itself known...

The crew of any plane that happened by was long a call on window "a" and "b"!  Since I was in line "b", I was effectively the counterparty and short a call on those windows.  When the crew turned up and took over the windows, they exercised their call and my line came to a stop.

This story is a pretty good representation of the value of using a real options decision framework for a couple of reasons.  The most obvious reason is the importance of involving uncertainty in your decision.  If nothing had changed, my first choice was unquestionably the best.

The second reason is the importance of having a dynamic decision framework that can adapt to new information.  It's easy to make a straight-forward ROI type decision when you ignore the changing world.  One line was served by two windows and was half as long!  That's an idiot-proof decision!  A few minutes later, the decision was more complex.  I was at the end of a line that was roughly the same length as the others, but didn't have the advantage of more windows possibly opening up.  A few minutes after that, I was at a stand-still.  A robust, options-based decision framework that encapsulated the upcoming decisions would have helped.

From an executive decision making perspective, this sort of decision tool is almost never available.  What can be available, however, is some intelligence about what the inflection points are.  If I had any idea about the chances of another window opening up, or what the chances of a crew showing up, I could have produced some heuristics about comparative lengths of each line and made dynamic adjustments to my strategy when the real world changed in front of me.

Options in the wild

A few weeks ago I was travelling on an international business trip.  On the way back I came to the top of an escalator to face the immigration / passport check area.  It looked like this:

(only the lines were a lot longer)

I just jumped into the line that was right in front of me and then sort of observed the lines.  The mental schematic I put together was this:

So I moved through the crowd to line "b" because it was the shortest one I could join (since I don't hold a EU passport).  Also, I realized that there were to windows serving that lane... both window "a" and window "b".  No wonder the line was shorter!

A minute later, the situation looked like this:

As the efficient, German airport had recognized a long line and opened window "e" up, and a mad dash had taken place as people near the end of the line for window "d" scrambled to be at the front of the new line.  My old location at the end of line for window "d" would have put me in pole position for the newly opened window!

Then, a minute later, this happened:

When the crew for some flight showed up and took over priority on window "a" and window "b".

Being a ridiculous person I thought "This is fantastic!  What a great example of real world options analysis!!  I can't wait to write this up!"

What are the options?  Take a few minutes to think about it.  In a few days, I'll publish my thoughts on it, but I would really like to hear what others say, too...

Visualizing your business model

The elements of the business model

If you haven't read my last post about the elements of the business model, do so now.  There's not much sense in reiterating what a prospect is, or how it fits with a product, etc.

Now, check out this picture:

The visual business roadmap

There is a great deal of information in this drawing.

Along the bottom you have the projects associated with your technology (product development) roadmap.  In the drawing I have here, you have two layers--real business can have many more, of course.  The bottom row represents core technology programs.  The layer above that represent product development projects.  Each product development project relies on one or more core technology program.   This is very typical.

Along the left side are market development projects.  These projects are intended to change the appetites and buying behaviors of the markets in general--whether or not you will capture the business produced.  For example, when Apple introduced the ipod the TAM for portable MP3 players exploded.

Along the right side are all sorts of projects.  In a real portfolio this is where most of the decisions really are.  These projects can be things like customer enablement programs, directed marketing programs, and anything else that will impact your expectations around your prospect.  That is to say, anything you think will impact the market share and/or pricing expectations for that product with that market.

Often a project will have impacts at multiple elements of the drawing.  

For example, adding a cool, new feature that has never been seen before may encourage people who would never have bought a product like yours to enter the market (TAM expansion), will help you increase your share of that newly expanded market (MSS expansion) at an increased price (ASP increase) but with the downside of an increased product cost (Cost increase).  In this case, you would be impacting markets, products and prospects all at once!!

Will your project survive in a big company?

This is based almost completely on work by this guy:
http://www.thomasthurston.com/

He found 8 questions that will effectively predict whether your new business line will succeed in a large organization.  I've paraphrased them and reworked them a little according to my experiences.  It has been a while since I've seen the originals...

1. Are the margins big enough to be interesting?  (Interesting >= current margins)
2. Are the markets you're serving big enough to be interesting? (Revenue contribution >= current revenue * 1%)
3. Does the project help sell products the biz is already selling?
4. Is the product in a market category we already participate?
5. Does the program help combat a top competitor?
6. Is the target market available through current primary channels?
7. Is there no perceived threat to an existing top customer?
8. Is there no perceived threat to an existing, power internal group?

If you can answer "YES" to everything, congrats!  You may survive the business funding cycle!

If you score one "YES" you're looking at a 50/50 chance of surviving each funding cycle.

If you score two "YES" answers... well, forget about it.

You might have a great business concept, a wonderful go-to-market strategy, and competitive products that serve a real market need.  If the corporate anti-bodies are going to reject you... you'll be rejected.

I have seen this happen several times.  There are reasons for a lot of this behavior.

For example, if this margins are too small, it will drag down the company's margins and starts to look like a growth trap.  From a strict-finance perspective, you're lowering the effective return for shareholders.

Most of what you see there are questions that are associated with diversifying the business.  Expanding into new markets, serving new customers (or pissing off old ones), attacking new competitors, etc. -- these are all outside the core and scary and difficult to do.

This is why big companies often fail to thrive.

Common Pitfalls - part 2

Last time I wrote about common problems in business plans that are associated with market sizing, forecasting and especially about estimating market share.

Other common issues are associated with pricing and margin expectations, defining the target market, project risks and customer contact.

Pricing forecasts are too aggressive

We see two sides of this coin.  For established products, we rarely test the limits of pricing for product line extensions, roadmap refreshes and similar product introductions that have the possibility of increasing our asking prices.  In these cases our models will always hold pricing flat, and thereby underestimate the revenue potential.

On the flip side, for new products in currently unserved or underserved market spaces we regularly overestimate the likely selling prices.  A common method to estimate these prices is to do a value chain analysis, some sort of should-cost and required margin analysis and then to determine how much profit pool is left in the portion of the value chain that the product will displace.  This makes a lot of sense and gives a good feel for how much the product could sell for.  Then, when it's finally ready, sales has a volume quota to meet, leadership gets worried about failing to land anchor customers and everybody sort of loses their spines.  The result is that we ask a laughably low price and the customer readily agrees!  This is a real "Flaw of Averages" sort of problem -- you will never get a higher price from your customers than the one you ask.

Margins are unrealistic for a new product

This one happens when we do a lot of market benchmarking to try and estimate prices based on our expected production costs and the product margins reported by competitors who are playing in the same (or comparable) markets.  Benchmarking is a great place to get started, but eager analysts and business managers often overlook the fact that incumbent competitors have had a head start to work out their cost structures, to improve their manufacturing flows and to feel out the best price points.  Their margins probably have improved over time--our first few years will not be so fat.  Similarly, fat margins happen in low-competition environments so by our very entry, everybody will have to tighten their belts and margins all around will probably come down.

Serviceable Market is too broadly defined

Often we will do market surveys that start with a "Total Available Market" this is broadly defined and we draw our numbers from commercially available sources like IDC or Gartner, etc.  For example, if we're working on a part intended to be included in new home construction as a sort of OEM Smart Home product, we will buy research around new housing starts for the next 10 years or so.  Ignoring the fact that these reports are almost never stochastic (they almost never include estimates of uncertainty or ranges for their estimates), they also almost always describe a very broad potential market.  For this reason, we try to define a portion of the total market as a "Servicable" market.  This is the subset of that market that could hypothetically meet their needs with the product we're intending to develop.  Often this segmentation is just as broad as the Total Available segmentation and we overlook the nuances in purchasing decisions between members of that sampling.

Sticking with our smart home example, if the key features of this product are all associated with climate control (like Nest or something) then you should anticipate that it won't be very attractive to new home builders in mild climates.  You can also safely assume that builders below a certain price point (like KB) will have a much lower sell-in rate than custom builders or luxury builders (like Toll Brothers).  It's common that a business manager won't consider all this and will just say "let's just assume we can address 80% of the market".

This approach is not only guaranteed to misjudge the size of the market that we could really address, it also skips past one of the most important parts of building up a business plan; actually talking to customers.

Business Plan never learned about actual customer preferences

I almost forgot this one is on the list, and in retrospect I'm not sure how I could forget it.  This is the case where an entire business plan is built up around a perceived use for a product that we already have--it just takes some modification or rebranding--with a new group of customers that we have little or no experience with.  It can be surprising how quick people can be to extrapolate their own experiences into conjecture about a broad segment of the buying public.  Compounding this problem is that (typically) between our business plan and that hypothetical buying public is a constellation of partners, manufacturers, retailers, channels, and co-travelers, any of whom can throw up a "I don't get it" roadblock.  We should have a really good answer to that objection before we even start to get serious with the rest of these forecasts.

Project risks are ignored

For most of the analyses I see, the actual Project spending isn't material to the overall NPV of the project.  By this I mean that the amount of the NPV is de minimis when compared to the margin dollars involved.  For this reason, it's common for teams to ignore project risk when building up their forecasts.  The business development managers involved will pulse the project managers for a general idea of how long it should take to develop and how many heads will be required and some real primitive multiplication-type analysis will take place and the RnD budget for the project is roughed out.

This approach really leaves a lot to be desired.  For one thing, "a failure to plan is a plan to fail" and RND project management really needs have at least the major serial stages of development roughed out, with the parallel activities in each stage identified and some sort of risk register built up.  Even this basic analysis will often show that the back-of-the-envelope timeline proposed above will really underestimate how long the project will take.  Sometimes the project timeline balloons to as much as 2x when taken in this sort of risk-adjusted, expected value perspective.

Whether or not the spending itself becomes material, there are usually other projects waiting for those people to finish up and move on to the next thing.  Even more importantly, a product that hits the market months (or even years) after the expected launch date is very likely to experience a very different competitive environment than the original forecasts of market share and market pricing called for.  Competitors may have produced improvements to their products, new competitors or new substitute products may have appeared, in some cases the very ecosystem purpose for the product may have rendered it obsolete.

Common problems in business models - Market Share

Common Pitfalls when estimating Market Share

There are a few things that seem to pop up on a regular basis when a business analysis / business plan is being developed.  More often than not, these are the product of biases and short-circuited heuristics on the part of the analysts and business owners involved.

When I'm doing an analysis review (and especially when I'm doing a long day of these reviews) I start with this list and immediately look to make sure these problems don't exist:

Competitive environment is poorly understood

Most of our business decisions address a competitive environment in which we are the incumbent.  This sometimes trips up business managers who are looking to extend our business into adjacencies or into transformational arenas.  If the plan doesn't comprehend the current competitive situation as well as how that competitive environment is evolving, it's time to go back and break out Porter's Five Forces again.

Market share ramps too quickly

I occasionally see some really enthusiastic projections.  I mean, really enthusiastic.  For example, a brand new product, that serves a market we're not familiar with, customers we don't currently do business with, through channels we're unfamiliar with, but we'll ramp up our volume faster than the last iPhone.

Peak market share is too aggressive

I see this one a lot.  The logic seems to be "if we can't capture first place in the market, why would we even enter?"  This might be true, but it doesn't mean that we will capture first place in the market.  If the peak market share for a product introduction is not consistent with the competitive environment, it needs to be adjusted.  Similarly, if the peak market share makes volume assumptions that we can't physically produce with our current manufacturing facilities, supply chain and channel structure, it needs to be adjusted, too.

(more to come)

"Decision Intelligence"

What are the steps of successful business strategy?

• Market Intelligence (outside facing)
• Market Sizing/forecasting
• customer trends, workloads, size, growth
• drivers, sensitivity, elasticity
• current customer groups, neighbors.  things your products could serve
• what are the customer needs for each group of customers?  what measures of performance and quality are important to them and what is their utility curve?
• Design Win Pipeline
• What RFQ and RFP are in the pipeline?
• What products best fit the customer requirements, both on roadmap and off roadmap?
• What are our chances for each opportunity?
• probability of the win
• size of the win, assuming we do win
• Prospect Estimations (workload / sku mapping)
• how will products play in the market, given the needs of the customers?  how do the performance/quality characteristics of these products match up to the needs of the customers?
• What does the competitive environment look like?  How do our products stack up?
• How much market share can we expect to capture?
• How much can we charge for our product?
• Business Intelligence (inside facing)
• Product Roadmap / communication
• what products do we have in the market now?  what about our competition?
• What products are in the pipeline?  What products are we not currently developing but could be?
• what are the important performance/quality characteristics of those products?
• what is the cost structure for those products?
• Project Planning/execution
• When will our products be ready?
• What resources will we need to develop our product?
• What resources will we need to bring our product to market effectively?  To support our customers?
• What risks are there to our project planning?  How can things go wrong, and if they do, what will the impact be?
• Execution Risk
• Upstream Roadmap risk
• interrelationships between project decisions  - 
• what projects are required for other projects?  
• what projects are required to build a product?  
• what projects help shape the markets? 
• what projects are required to take a product to market?
• Decision Intelligence
• Project strategy (portfolio) / funding
• funding decisions - what projects to do / cancel / keep alive
• Enterprise Risk
• What major pivot factors exist that would radically change the value of our company?
• What decisions would we make differently if we had perfect information?
• How can we hedge our bets most effectively?