|
Product Development is a noun. It often appears with a variety of adjectives added to it, such as Agile, Customer-centric, Flexible, Inspired, Leading, Lean, Profitable, Total, Revolutionizing and Winning. I look at all these terms (they are often book titles) and take heart. We in the development community are working our fields. A lot of smart, capable people are trying to advance the state-of-the art in product development. This is a good thing.
Here is another adjective: Rational Product Development. As a consultant deeply engaged in this profession I often see the following situations that are "irrational" as far as effective product development is concerned:
1. Asking team members to work on too many projects.
This is characterized by starting a task on one project, being told to cease doing that work; start up a task on another project and ramp down that effort only to start up a completely different task on yet another project. This can become the day-to-day norm and is demoralizing.
2. Overloading team members with more than 100% of their capacity to do high quality work.
Frequently I find individuals booked to 150% of their capacity to conduct work. It is easy to load a person beyond 100%. What happens is the person will find a way to do the tasks, but the quality of their work suffers terribly - especially if creativity and thoughtfulness is required.
3. Placing a biased emphasis on speed that results in short cuts and rushing.
Driving a new product to market before it is properly developed to customer expectations, corporate standards and legal requirements is also quite irrational.
Pass the Test...There's No Time for Learning!
One of my recent newsletter articles was about the difference between planned and detailed learning through designed experimentation versus rapid preparation to pass a test. Development team leadership can reinforce a bad habit learned on our college campuses - also known as "cramming for the test". Why not take the time to learn? Development is a lot closer in definition to learning than it is to test-passing.
More About the "Need for Speed"
"There is no time for this, that or these other things... just get it done!" How can there be little or no time to truly understand what makes our products work under normal as well as stressful shipping, storage and use conditions? Yet there exists an irrational push to cut corners. Rushing has become an acceptable development practice. I dare say it would not be tolerated if one of these managers or their loved ones were in surgery!
A Quick Self-Test for Irrational Product Development
If you are a product development leader, ask yourself these questions:
Is my team being asked to do more tasks than they can physically and mentally conduct and still produce quality results? Are they spread too thin across projects? Is my team being rushed so its likely mistakes will be made that could have been avoided? Are we cramming our development actions to pass tests as opposed to conducting a planned series of developmental learning experiments so we really know why and how our products perform? Are we launching products with the knowledge or suspicion they have not been properly developed? Will post-launch problems be someone else's responsibility?
A "yes" or "maybe" answer to any of these questions could indicate irrational product development practice(s).
Towards Rational Product Development
To encourage rational product development, there are a few well-known aphorisms to consider:
Haste makes waste.
This is the "lean" model. It is rational to believe that if you rush people as they do their tasks they will likely make mistakes leading to the creation of wasted time and resources.
Do it right the first time.
Doing things at a reasonable rate, with care and mindfulness according to a rational plan is likely to get the results you desire the first time you do the work.
Tell the Truth.
If a development team and its leadership have an honest approach to learning and communicating facts, the likelihood of having to slow down and clean up "the hidden design" that really exists is reduced.
We leaders of product development must be willing to learn. We must continually ask ourselves if what we are doing is reasonable or irrational. We must have the courage and determination to stop and change. It's hard and it's risky - but if more of us do it things will improve and our credibility in the corporate culture will improve. Get a copy of the book Car Guys vs. Bean Counters and see what Bob Lutz says about being a reasonable leader as Vice Chairman at GM. I think he tried, but not hard enough for the power he had. Those who don't care and want to follow the status quo will begin to lose traction and will be forced to do the right things for the right reasons because those of us who are reasonable will prevail.
Next month I will discuss specific ways to drive reason into the development of project schedules that forecast just how long it really takes to develop a product.
| 
