Achieving Fast, Flexible Flow


If we consider product management in a linear fashion, our job is to:

  1. understand customer pain points,
  2. create insights,
  3. vet those insights against potential solutions and business opportunities,
  4. prioritize those opportunities,
  5. work with development to build the solution, and
  6. market the solution so the world, or at least the target customer, knows it exists.

More simply stated, product managers take insights and ideas and convert them into products and revenue (figure 1).  All along the way, we need to build in opportunities to validate our ideas, broaden our learning, and refine our plans.  Our goal is to create winning products by optimizing the sustainable flow of value to our customers and profits to our companies. But how do we best flow value?

Product Management Flow Insight




Figure 1: Product management simplified

Elements of Fast, Flexible Flow

One lean concept that has become popular is that of fast, flexible flow.  Fast, flexible flow has five elements:

  1. Minimize Queues by working in
  2. Small Batches, managed through
  3. Work in Progress (WIP) constraints, to
  4. Shorten cycle times, and approach
  5. Single piece flow

Minimize Queues

As discussed in a previous post, queues are the enemy of responsive and flexible solution development. They hurt cycle time, quality, and efficiency. This exposes ourselves to changes in preference, competitor pre-emption, unpredictable schedules (i.e. delays), decreased quality due to long feedback loops, and reduced revenue.

Small Batches

Limiting batch size, therefore, is very important because queue size can never be less than batch size.  If we want to shrink queues, we need to learn to work in smaller batches. I already discussed how product managers can deliver PRDs incrementally in the form of minimum marketable features (MMFs) in my post on Working in Small Batches.

Work in Progress (WIP)

A further way to manage queues and keep batches small is to enforce WIP constraints.  Thus, we limit the work in progress and monitor queues at each step in the process.  If a back-up occurs, for example, at QA, the team shifts to assist QA until the back-up is cleared and flow is restored to the system.  This contrasts to the traditional approach and thinking that views engineering as a precious (i.e. expensive and scarce) resource that must be kept 100% utilized writing new code.  Delaying the release of the product by creating a large backlog at testing does not create value for our customers or our companies. Rather it makes us inflexible and slow to deliver value.

Shorten Cycle Times

As batch size shrinks and the team focuses on fewer concurrent items, cycle times decrease.  If features and enhancements take less time to get through the system, for example going from months to a week, then tracking and status reporting are greatly simplified. Status is simple, either the feature is in progress or it’s in queue.  The team can even produce estimates of when an item in the queue will be worked on based on their capacity and throughput. Lastly, as features are developed serially but quickly, product management will have considerably more opportunity for feedback throughout the development process. As new learning emerges and/or opportunities emerge, the plan can be adjusted for an optimal outcome.

Single Piece Flow

The final element of fast, flexible flow is the goal of single piece flow.  You can think of a “piece” as a requirement or feature.  Thus, the team works on one feature at a time, only works on that feature when there is proven demand (ideally orders), and delivers it quickly. The shorter the cycle time, the more practical single piece flow becomes.

However, due to the complexity and uncertainties of software and new product development, it may not make sense to truly go to single piece flow.  First, it would expose us to risk that if the team became blocked on a requirement, there would not be additional requirements defined well enough on which to work.  If customer validation is required on a proposed solution or acceptance test, this could introduce a delay outside the team’s control.  Secondly, depending on the size of the team, it probably does not make sense for example to put eight developers on a single, small feature.

In the end, each team needs to find the right balance of WIP and Cycle Time to optimize the flow of value.  Product management’s role is to ensure the problem being solved is one for which there is a market and having just the right number of requirements detailed and queued up for the development team to balance flow and agility.

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *