July 18, 2011
.jpg)
The Rest of the Story
A close friend of mine works with an engineer formerly of the NASA staff. He is a sharp engineer that tells a amentable story of his experience with the wonders of the space program.
He explains that he spent two years working on a project to develop a treadmill for the international, or any other, space station. Think about that one for a few seconds.
He was a young engineer at the time and probably didn’t have the tenure or confidence to say what many of the rest of us are probably thinking. “Get lost! I want a different project!”
Are you one of those marketing, sales, engineering, or common sense folks who can smell a booby trap a mile off? The space treadmill stinks of disaster.
The idea behind the treadmill is to solve the problem of exercising the astronauts in a very compact space while on board the space station. Apparently, aerobic exercise is particularly difficult to facilitate. But, how a treadmill became the objective is beyond my imagination.
Granted, it fits in a small space; we even have versions in our home that fold up against the wall or under our beds. It is also universal to body size or fitness level. Fair enough. But as an engineer I see a whole menu of disaster-driving challenges.
The first and most significant is gravity. It’s kind of hard to run on a treadmill without it, so now you need to somehow replace gravity. No, a bungee cord on a belt won’t do it. The dynamics of running are apparently too complex.
Second is the problem of impact and vibration. The third thought in my mind is power. I won’t belabor the points except to point out that dampening vibrations, to save the space station’s lightweight structure and meeting the limed power budget are certainly difficult challenges for a system that must also be very compact and light.
I understand from the story that the engineer’s team did design a treadmill to work within the constraints, but that it was never produced because other exercise options proved to be more practical. Naturally, the engineer tells the story with a blush in his cheeks and some chagrin in his voice. Still, he got to work for NASA on the space program, so I remain jealous. I won’t give him any grief either. I too have worked on less-than-practical projects because I was ordered to do so.
I think what we have here is an example of NASA’s well-deserved reputation of “Nothing is impossible” attitude. I think its “If you can dream it we can make it happen” culture got a little carried away with trying to develop the space treadmill product.
In spite of the engineer’s observations that a treadmill might not be the best idea, he was told to develop one because that is what the contract said to do. I’ve worked in engineering services and I fully understand the notion that the customer is always right and that if we want to get paid we make the customer happy. But there’s the catch.
Sometimes what the customer asks for is not what will make the customer happy. Just because the customer wants it, or just because you can do what no one else thinks it’s possible, doesn’t mean it’s the right thing to do.
Take the urban legend example of two Marketing and Engineering teams competing with each other to develop the better luggage product. Both teams explore customer feedback and desires and get the same response. “My luggage is heavy and it hurts to carry it around. Make my luggage lighter.”
One team went off and spent a great deal of time and money developing expensive materials and a minimalist design to make their luggage product incrementally lighter than all others on the market. The other dug deeper into understanding the problem and instead developed the very successful rollerboard we all travel with today. By the way, the latter is actually heavier.
The second design team understood that it isn’t the luggage that determines how much weight a customer carries; it’s what the customer puts in it that determines how heavy the burden will be. Instead of battling a problem that the developer could not control, the second team simply eliminated the problem by eliminating the need to carry the luggage.
What the customer asks for is often what the customer believes the solution is. Or the customer puts his problem into language that implies a solution and we assume that such is what the customer wants. For example, “make it lighter.” The customer probably means for us to make the burden lighter, not necessarily the luggage. The customer is thinking about the problem, the design team is thinking about the product.
Sometimes it isn’t the customer that dictates a solution, but our Marketing or Sales folks in our own business who dictate a solution which is the first to come to mind, not necessarily the most practical. Whatever the case, if we take our orders and run without thinking; we can easily spend gobs of resources developing a product that is exactly what was requested, but won’t make anyone happy.
Has this ever happened to you? Have you ever made the mistake yourself? I have. I suggested a solution to a process problem and began the production of the equipment when someone pointed out a much simpler and more practical solution. It’s an easy mistake.
To prevent the mistake, build a quick and easy system to prevent developing a bad idea. The first key is to include several perspectives on the decision. I know that Marketing folks sometimes prefer not to include engineering folks in the product vision because they desire a bit more of the NASA “nothing is impossible” attitude instead of the, “do you have any idea what you are asking?” attitude, but many times the engineers will be able to insert a pragmatic perspective that can greatly simplify the solution.
Next, make sure that you really understand the problem. Take a few minutes to write a good problem statement. A good problem statement includes the following:
What is the problem?
How do you know?
When (under what conditions) does the problem occur?
The problem statement must not include opinions, nor should it include solutions. It may be an exercise that takes one or more iterations, but really it takes only a few minutes and it can save you months of wasted product development.
Finally, be sure that your system asks and answers some simple questions to make sure the product vision is the one you really want. Here are my favorites:
Are we solving the customer’s true problem?
How do we know that we are developing the best or right solution?
Will it be easy for a competitor to “leap-frog” our solution with a better one?
By “leap-frog” I mean to create a solution that is one function or capability better, or of comparable capability but less expensive and, therefore, a market stealer.
In my experience the above three questions are sufficient to prevent the two-year-long space treadmill projects. Re-word the questions all you want to make them fit your business and your language. Just, be sure to utilize the automatic checks-and-balance opportunity of including other functional voices in your question-and-answer review.
It may take a little extra effort and time, and it may generate more discussion than you care to entertain when making a business decision, but some decisions are worth it. Decisions that drive months, or years, of product development resources and potential product failure are certainly worth a little extra effort. Mitigate the time and discussion by keeping the process simple, and doing it frequently for practice.
The first decision in product development is that which determines what the product will be. Don’t be hasty and jump to task on the first idea to come to mind. Don’t blindly develop what the customer asks for when it is clear that an alternative might serve better.
The very order of “develop this” is the command that will invest your resources on either success or failure. Make an effort to challenge your decision with a few simple questions. It’s the most important one in the process. Issue your orders wisely and with greater confidence for the effort.
Stay wise, friends.
0 comments:
Post a Comment