Fighting proxy culture in product development

Hashworks
Hashworks
Published in
4 min readJul 8, 2018

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so — Mark Twain

Today’s product development practices are run by the dogma of beliefs like productivity, innovation, reduced cycle times, elimination of waste, quality and so on.
The key to answering this belief system is to step back and answer a fundamental question of WHY do we want to stick to these beliefs? The answer — Maximizing profits.
The danger of relying these proxy variables is it doesn’t focus on economic decision making, rather it diverts the issues between the correlation of each of this variables.
For example, if we consider the belief of efficiency is good, with blind eye to queues. We will push high capacity utilization to reflect efficiency, since under-utilized capacity will appear as waste. But on the hindsight the high capacity utilization may causes queues resulting in huge backlogs, with no apparent cost on the pending inventory of work.

A book on principles of lean product development “The flow” by Donald G.Reinertsen says, the current orthodoxy of product development is fundamentally wrong and it is so obliviated from the current reality, he compares this orthodoxy to applying old manufacturing principles in the modern lean manufacturing age.

Traditional product development practice have phase gate-process. Work is divided by phase gates, one phase must be complete before the next phase start. Which means there must be atmost clarity in the way the requirements are defined before the design activity followed by the development phase. At the offset, this approach appears pefectly sensible and portray a picture perfect scenario for product development.

In the real world, what really happens is quite different…
- The requirements are never fully done, it keeps evolving as complexity changes
- No development team waits to design a product till they acquire the complete requirements.
- They start the design at 50% clarity of the requirements, but follow — don’t ask, don’t tell policy.
- Distortion of reality, people follow status quo. Most of the work they do in parallel just remain as dead-inventory.

These behaviours emerge due to the proxy objectives as below that has a damaging influence in the product development….
- High capacity utilization for efficiency with blindness to queues/backklogs
- Innovation with delay in Design-Process adding to inventory, long cycle time with cost of delay
- Workship for conformance, FIFO queues based product development practice without the sense of variablity & risk
- High capacity utilization and workship of efficiency while ignoring variablity, small batch transfers, rapid feedback & limited WIP inventory
- Demeaning Variability, we cannot innovate without variablity.
- Manging timelines instead of queues
- Absence of WIP constraints & Kanban principles to Agile Development practices
- Centralized control with zero control on the uncertainity

The limitations of current orthodoxy can be overcome by the themes of flow-based product development.
- Economics
- Queues
- Variability
- Batch size
- WIP constraints
- Cadence, Flow control
- Fast Feedback
- Decentralized control

Economics
Applying economics based decision making in a product development process will enable teams to see issues from a fresh point of view. The economic goals will set tangible and clear goals to the team to achieve greater operational efficiency and project management correctness.

Queues
When you see the product development lifecycle through the eyes of economic framework, the most visible discovery you can make is that reduced cycle time will lead to higher profit gains. If you look deeper into the cycle time issues, our real problems are with the period of inactivity and not slow activities. Unpredictable work arrival times and unpredictable task duration leads to low levels of capacity utilization resulting in poorly managed queues adding to inventory. Responding to Queues will enable the teams to plan their work inventory and capacity utilization. It will improve the cycle times, feedback loops, manage variability & risk thereby improving the economic performance.

Variablity
Change is the only constant. We should look variability as a key attributes to relevance. Variability is good as long as the change is adding value to the product shape & reduces the consequences of no change. Variability is contextual depending on the economics of what change could mean to product development. Only certain payoffs will cause variability to create economic value. Like the value of a change is much higher than the cost of failure.

Batch size
Product development paradigms over years has continuously pointing to reduction in batch size of work in a development life cycle will result in better performance and reduced cycle time. It also accelerates the feedback loops, reduces variablity by eliminating the queue since the delivery cycles become faster. The risk exposure to development cycle also goes down significant. Overall resulting in lesser overhead & increased efficiency.

WIP constraints
Toyota maintain shorter cycle times in the factories, TPS (Toyota Production systems) widely uses WIP constraints in their production line. Batch size reduction is key to reduces queues. WIP constraints affects delay, blocking & utilization when not applied properly so it needs to be applied with caution. When WIP constraint are relatively light cycle-time savings are much higher than cost of under utilization or blocking.

Flow control, Fast feedback & Decentralized control in the product development attribute to fighting the proxy culture of following the vanity metrics & correlated action of the performance variables in a product delivery. What the organization needs from the product development teams today is a strong acumen on the economic value for delivering a product.

--

--

Hashworks
Hashworks

Your digital transformation partner to Collaborate | Innovate | Change