There are three important principles of fast-time-to-market (FTTM) thinking. These are:

1. Bring pain forward

2. Happy schedules

3. Know the gap

All three are interconnected. They come from the idea that knowing something in advance is better than, a) finding out about it later or b) being surprised by something previously unknown. Why are these concepts hard to understand and implement in practice?

Because they are based on before-the-fact behavior. The anticipation of something that might happen, based on an assessment of risk or based on past experience, or on an expert assessment of what is expected to be delivered within a specific time frame. Looking forward is hard to get people to do. Most of the time teams are looking down or looking in their rearview mirror. To anticipate what might happen tomorrow is even harder. Why?

Because looking into the future might expose something that is contrary to what you may want to happen. For example, if we need to deliver an advanced/never-been-done before technology in the 3rd quarter next year in order to maintain our market share position (which is tied to our growth plans and executive compensation packages), yet when we put our plan together with the core team it indicates that we are over a year late. This is not what we/they want. The fastest way to fix this problem is to ignore the late prediction and then to find fault with the person, the people, or the logic that they used to arrive at the big gap in time. Killing the messenger always works to stop this “foolish thinking.”

Further, if we, as executives, acknowledge the year delay then we might, somehow be implicitly giving this delay credibility. Maybe people will start believing it and then it will become a self-fulfilling reality. So the best way to kill this is to ignore it or aggressively discourage it. Rather, gather the team together and explain how important hitting the target date next year is; that this means the future of the company and maybe their jobs. Perhaps this was not clear to the team when the time goals where established and set in stone. Was this a communication problem? For if they understood, then they surely would have made a schedule showing it finishing on time, and so on and so forth…. This is followed by a team building session with “trust falls” and lots of drinking at the beach party project kick-off event. I bet you have been though this drill. How did it end?

This is why it hard to change behavior from after-the-fact to before-the-fact action.

It is hard to get organizations to accept reality because that reality is not what people want to hear or accept — it just can’t be, so therefore it isn’t. And God help the person that forces the issue and brings the bad news. These people are usually pushed aside as being “non-team players” and get calls from the HR people, then “managed” out of the company.

The difference in our thinking from what I have dramatized (all based on real situations we have seen of course) above is that fast teams want to know that there is a gap and they are late, they don’t want untrue “happy schedules,” and they really want to accelerate the pain; bringing it forward so they can deal with it right today, not later. They want to deal with it now, while there is time to fix the problem or to take actions that could cause the gap to be closed. They want to accelerate before they slip, to bank time for when the unexpected happens, and they will need to withdraw from that time bank. This is called “reality based planning.” It is harder than you think to actually implement it though.

For example, if we know we are a year late with the current requirements set, which requires a major technical breakthrough in the next few months, one that we are not even close to making; then could we achieve the product objectives any other way?

Could we buy (not make) a similar component for the next product cycle while we give our research team longer to invent the longer term solution that will give is the breakthrough we need? Could we use an existing component we have in hand now and then mitigate the capability limitation through enhanced software features?

You see, when you have a Happy Schedule that tells you everything is fine (you are on schedule), then you never have the discussions about alternatives. We are not forced to explore alternative paths to achieving our product goals, because we pretend that we can “invent” the breakthrough right when the schedule tells us we have to. There are no learning cycles planned, it will be right the first time, and nothing will go wrong. This is stupid planning, but very common. This wishful thinking is what has killed many Silicon Valley projects and eventually companies in our 30+ years of observation and counsel. Lots of money has been wasted with this stupid thinking, from some of the smartest people on the planet.

In order to implement these three “before-the-fact” behaviors in an organization, the management hierarchy must be conditioned. Another word for “condition” is “trained” to understand that their actions and reactions will permit this thinking to develop or will it cause it to be extinguished. Many C-Suites say that they want open, transparent, honest, participatory involvement from their new product development people, but when their people try to communicate reality to them, they shut it down quickly, since it contradicts with what they want to have happen. Lets be clear, wanting something does not make it automatically happen. Even most five year olds know this.

Reality Distortion

Can’t you hear them saying, “We want can-do not can’t do managers…” and so on. Many of them think they are channeling Steves Jobs’ “reality distortion” when they ignore reality like this, but what they are really telling us is that they don’t understand how “distortion” really worked/s in practice. Jobs’ distortion was based on setting aggressive targets and then managing the gaps by narrowing the requirements to fit the time frame, and then through micro managing its execution with constant iterations between requirements and the product. He got people to collectively believe it could be done, because he proved they could do it — this feedback loop is why his reality distortion worked. Few people have the skills to do this. We have coached and mentored some of them, but this is the topic of a future post.

But just ignoring reality or distorting it and then doing nothing else is a recipe for failure. We have witnessed it first hand many times. Arrogance, ignorance, and testosterone could be the title of the new Silicon Valley movie on the history of its spectacular failures. You need to do something more, if you don’t have Steve Jobs-like skills (very few do), you need a system to plan reality, see the gap, factor in risks, and then use this information to energize a group of technical people to find breakthrough solutions. We have learned that bright people will always find solutions if the reality of their situation is allowed to be communicated. It is a basic engineering principle in innovation; we must reach a failure point in order to find a solution. Same is true of FTTM thinking — we must show reality, show the failure (of the gap) in order to engage people to find solutions. Ignoring reality just pisses them off and causes them to disengage and they will never succeed, but you won’t find out until it is too late.

When this works well, we see the executive team embracing these concepts and rewarding people who exhibit the behavior. The person who avoids the fire is rewarded, not just the person who puts it out after (they) started it. They encourage people to speak the truth about potential future risks and then drive people to find mitigating actions to reduce those risks.

They express the gaps; the gap between when it is needed and then when a team could be able to reasonably deliver it. Once expressed, they are encouraged to explore solutions that could close the gaps. These often require decisions to be made that involved trade-offs. When it works, these trade-off alternatives don’t compromise the product. Going faster does not mean doing it with less quality or with fewer features and capability.

“No-trade-off” Paradigm

Rather, they use a “no-trade-off” paradigm to force the solutions that deliver the right product at the right time. This is all made possible when there is a culture of openness where people use data to solve problems, rather than to hide from them. Few organizations around the world have achieved this sort of environment, but when they do, they tend to produce a lot of good things very fast. We have experienced this on many projects and it is exciting to participate on these teams. It is made possible by the environment that is set up by the leadership team. It does not happen without this support infrastructure and mindset.

The following is from one our executive presentations on this topic. It is an attempt to communicate these ideas. We tend to fall short most of the time, since it is so hard to explain. It is easier to do than explain.