Growth Leaders Beware: the Road to Hades is Paved with Good Intentions

carmen

It’s a common conversation, yet it continues to surprise me.  I was talking with a P&L owner of a smaller, publicly-traded firm, when they raised the issue of how they put themselves in a bind: “I’m not sure what else we could have done. We hit the customer need dead on, yet when we went to scale, we hit the wall.  We have orders with deadlines that I can’t meet and operations is ready to throw me overboard.”

One of the most common patterns I run into is the misprioritization of the work needed to create the breakthrough.  It’s not an issue of total resources or lack of hard work, but more a misplaced overinvestment in three areas (more on this later).  In other words, there is plenty of effort being applied, but it’s being applied to known work to be done – instead of to the major roadblock risks to be eliminated.

The best example of how to take on big things and productively develop new platforms harkens back to the space race.  When you look at each generation of the program (Mercury, Gemini, Apollo), each mission was predicated on the previous one, with the foundation and platform of expertise growing with each cycle.  In each case they removed risk from the ultimate goal – a moon landing.  Mercury was launch and orbit, Gemini the rendezvous and docking, along with the outside vehicle work, while Apollo was moon orbits, and developing lunar module operations.  By building a platform of capability, they were able to take the next step with a limited amount of risk and exposure.

In the same way, we can build a platform of new expertise in new business.  You may not need to go to the moon, but you do need to use your platform and bridge your business to something new.

I get to work with many capable firms that have well-established businesses that have hit the plateau of diminishing returns.  My job is to assist them in assessing their current foundational strengths, then help them target productive (and less competitive) new offerings so we can build an efficient and workable bridge between the two.  (Just because it’s easy to describe doesn’t mean it’s easy to do).

There are patterns that emerge repeatedly that consume these firms’ time, energy and resources. These over investments usually take three different looks:

 

1) Overemphasis of Technical Proof Points

The most common place this occurs is in tech teams, which have a tendency to overshoot the basic requirements of the project with significant additions to scope…in fact, we usually find R&D teams working well beyond the boundaries sketched out by the marketing team.  Secondly, it’s very common to find them working on enhancements to the core product or service before the main platform has been operationalized.

This always results in sub optimization of the investment, as the learning in bringing the first complete version of the solution to market is always profound and impactful.  While the team may build some useful general IP, the utility of that effort could be much more focused.

The anecdote to this is to make the R&D team part of the end-to-end delivery system and reward them for putting a basic prototype in the client’s hands.  Five minutes in the client environment is worth hundreds of hours in the lab.

I once worked on a very costly and detailed device that actually pre-dated the ill-fated Apple Newton by some time.  The issue was that while the device tech worked, the wireless data speeds were measured in kilobits, which made the device slow and unusable for its group.  Technical win – market fail.

 

2) Overdependence on Business Model Proof Points that Align with Existing Business Model Norms

Success in the current business model results in an over confidence that it can absorb the new product with no issues.

Nearly every effort starts with the assumption that the same benchmarks for their current product will apply.  The business is modeled on the same ratios of sales investment, marketing investment and partner development investment.  This is very, very common and these assumptions very rarely hold.  The work of developing the channel assumptions with clarity is amongst the highest priorities the team needs to work on, yet these are frequently not even part of the initial discussion when resources are being allocated.  The result?  We put the new product in the old system and find the business model does in fact need significant work.  

My example here is about a client company that was great in the business-to-business space who decided to do some consumer-based device work.  They were completely unequipped to support the product and provide training for the front-line technical team that needed to equip the channel (which they hadn’t budgeted for).  By doing a more thorough set of work, we were able to efficiently bring a partner in that could offload the consumer-centric channel support so the product come become successful.

For an additional examples of “confirmation bias” examples, check out this post.

 

3) An Over Emphasis on Those Things That Were Hard Won in Their Current Business Model

When the leaders who are currently in place were building their careers, they were rewarded for solving a series of unique problems that they encountered.  Having been promoted and found success in that expertise, these “success imprints” stick with them, and so they continue to assume that the portion of the program is still high risk and hard.  This “fighting the last war” issue can be very compelling, as they have solid experience that backs their interest and curiosity.

You can see this clearly in groups that continue to pour money into extending a product line after the utility has passed.  Each significant new wave is preceded by an overly engineered version of the last wave.  An example that has played out in front of us is the PC microprocessor “competition.”  Intel and AMD were continuing to push cores and speed long after the true competitive sphere had shifted to mobile and battery life.

 

How do we Avoid These Issues?

So how do we go to work on these three areas?  It comes down to using holistic analysis and letting true risk to solution delivery be the guide.  In using the “Right Project, Right Team, Right Plan” methodology, we build a solid plan that traces the arc from current strength to new business as a system, sussing out both business and technical risks.  These risks are then sized and worked sequentially until the Minimum viable value chain has been established.

If you would like to know more about the tools and processes we use to support the creation of efficient projects that deliver, please give me a call at 847-651-1014 or click here to set up a no-strings-attached phone call.

Related posts you can benefit from…

Did you enjoy this blog post?
Sign up to get access to Scott's monthly innovation newsletter and blog post.