FTTM Host

Fast-Time-to-Market (or FTTM) is a set of best practices that resulted from an ongoing study into the factors that drove speed in development projects. I’d like to briefly speak about a context for these practices.

Why be fast? It’s a simple business model. There’s a market window for everything that’s new. Enter early and it means you get the maximum revenue over the life cycle, and in the tech world, early entry means you also get the highest margin. On the other hand, enter late, and your market share, revenue, and margins are lower and your costs of development is higher — due to the extended run-rate of development. This simple model works for just about everything.

As we studied fast teams, we observed three high-level systems that enabled them to be fast. We called these systems Strategy; instilling a mindset for speed at the top, Portfolio; defining the right products at the right time, and Execution; establishing fast structures.

When we say, “Mindset” we mean how management in these fast environments grasped the enormous financial advantage gained through speed to market performance. They created a fast culture, were fully involved in the product portfolio, and aggressively broken down slow structures. Apple and HP are or were good examples of this thinking.

Delivering the right products at the right time involved a careful management of a number of factors summarized here. Take a minute to study the list….

It is relatively easy to make a single development project go fast, by “robbing Peter to pay Paul.” But since it is a zero-sum game, this always meant one team lost when another won. The best practice environments we study and work in manage the portfolio through careful prioritization based on strategic drivers. Further, products were designed for speed and managed to break-even -- teams functioned like a business, not science projects.

The third element for FTTM has to do with creating fast structures. Perhaps the greatest barrier to speed are the interrupts that organizations place in front of teams, causing them to waste time finding work-arounds. The fast teams were laterally structured versus traditional hierarchical silo structures that are inherently slow since information flows up and down the hierarchy, which waste more time. We say that fast teams are “provisioned” for speed with information, resources, and direction. Most importantly, the cost-of-delay was known across the team. Each day late has a cost. In a majority of the Silicon Valley projects we’ve worked on this figure is well over $100,000 a day of lost profit every day a team was late. This knowledge creates urgency and accelerates decisions.

Let’s drill down and look at specific “execution” practices which we’ve observed operating with fast teams. The most important being Refresh Planning; they refreshed their schedules multiple times a week, each time breaking down near-term critical path tasks into finer detail and exploring ways to accelerate the schedule. The complete team participated. They used the schedule to drive the project, not just to report on it. They had early warning of potential slips, they used this to create urgency, well before something slipped.

We also observed “environmental factors” that drove speed. They knew what it cost to be late and provisioned teams with dedicated and empowered people.

These “environmental factors” extended outward from the team to the customer. Fast teams use voice-of-the-customer (VOC) continuously through development. They understood what customer valued and use this information to prioritize requirements in order to implement the highest value requirements within the target market window time frame. They knew that if they hit the market window in time, successive product generations would incrementally improve the product. They knew, "It was better to be roughly right than exactly wrong"— and the payoff for early market entry was hugh compared with the delay associated with “getting everything perfect.”