We conduct ongoing research into the best practices of highly successful new product development teams, and we continuously maintain a current best-practice experience base. This “competency-based” research forms the core of our consulting practice, keeping us at the cutting edge of new thinking before, in many cases, it is documented by the academic community.

Our focus has been, and remains, on practical solutions that can be applied to real-life client problems, rather than theoretical or esoteric ideas that “publish well,” but tend to be difficult to implement in practice. The study is ongoing with new clients, projects, and experiences added every year.

The practices are culturally refined through implementation projects around the world - what worked in San Jose California is likely to change in Shanghai China, based on cultural differences and human behaviors.

FTTM Best Practices (Fast-Time-to-Market)

FTTM was first researched by lateralworks in the early 1990’s, through an extensive multi-company study of over 500 people involved in fast-to-market projects in Silicon Valley. Over the past 3 decades lateralworks has engaged with hundreds of teams trying to accelerate the delivery of new technology products to market, and continues to study fast team practices through its international consulting practice. Each engagement builds on the research database in terms of both changing practices and deployment tactics.
 

FTTM outcomes are a function of two inputs; 1) the behavior of the team and 2) the environment within which the team operates. Individual project teams can achieve fast cycle time results, often at the detriment to other projects (by stealing resources). The portfolio of projects will therefore remain slow if the environment within which the teams operate is not oriented to help teams move faster.

Senior management must create the right environment through specific behaviors and mindset, a fast development framework, lateral organization structures, and fast decision-making systems. It is easy to make one project go fast at the expense of others, so the challenge is to balance the portfolio so the highest value projects get the resources they need in order to get to market quickly.

We call this environment the “Host” environment. In fast corporate cultures, the Host empowers heavyweight teams, removes interrupts, and provisions teams so they can be successful. In normal/slow corporate environments the Host tends to interrupt teams by not providing the resources when needed, filling the pipeline with more projects than there are resources to get them done in a timely manner, not developing “bench strength” of skills needed to create the technology, and controlling cost (at all costs) without understanding its economic impact on speed (i.e. arriving to market late).

In short… provision teams for success, eliminate the interrupts.

Best Practices broadly fall into three categories: Mindset, Host, and Team (horizontal axis). Down the vertical columns is a second classification; Portfolio, Environment, and Execution. For example; “2.1 Fuzzy-front-end is managed” is a practice performed by the Host that relates to the portfolio planning and management process. Most of the Portfolio practices are owned by the Host, with the exception of “3.1 Co-develop with tier 1 customers; continuously refine requirements” which belongs to the Team, but it relates to how the Portfolio is managed.

One could argue for a different classification of some of the practices, as they could fall in multiple locations on the matrix. We chose this configuration (above), but what is more important is that there are mindset, host and team practices we observed that enabled the right products to get to market at the right time. Overriding these practices was a corporate “mindset” that speed was the most critical asset of the company, and this mindset was understood by the leadership team and practiced consistently. They didn’t just say it, they did it.

In the Study we will generally describe the practices that make up each category using a contrasting technique to accentuate the differences in terms of “normal” (or the typical team/corporate environment) and “best” in class. Although it may seem as though we are exaggerating at times, all of the “normal” conditions we write about are observed in real world situations. Each new project generates more live examples.

Few companies follow all the “best” practices, but a lot of them follow many of the practices described as “normal,” and they also considered it normal to behave this way. The difference between “normal” and “best” separated the fast from the slow teams/companies.

When we speak about speed, we always mean “right product delivered at the right time.” FTTM is not just being fast, but also delivering what customers want and value at a given point in time. Balancing this equation is very hard; on time with the right product, not a de-featured or technically compromised (in order to get it out the door on time) product. Going fast is relatively easy when product functionality or quality is compromised (i.e. traded-off), but what the best in class teams do is to deliver what customers want, when they want it. This requires knowing what they want (listening to them), being flexible enough to adapt as their requirements change (when they find out they are not sure about what they want), and then being able to execute on aggressive timelines through continuously pulling-in (accelerating) the schedule.

They did this by continuously changing the product and continuously changing the schedule. This is counterintuitive as one would expect that the way to solve the problem would be to fix as many of the variables as possible. When teams fixed the spec and fixed the date, they almost always failed - missing both by wide margins. Why? Because nothing is fixed and everything is always changing, especially when it comes to technology development.

On the contrary, fast teams kept the product definition fluid and the schedule fluid, always adapting them to the dynamic conditions of ever changing cutting edge technology development. The practices outlined in this document describe how they did/do it - how they execute using counterintuitive thinking. To understand why this is counterintuitive thinking is to really understand the best practices.