Function First!
The market place is a battle field littered with the corpses of dead and dying
products. It has been estimated that as many 90% of all new products fail to gain
wide acceptance in the market place and fail to return even the initial development
investment. There are a number of reasons for this, but failure is rarely the
result of poor technological implementation. On the contrary, a lot of
failed products have excellent technological performance - in fact, in many cases,
much better than the perceived market leaders.
So what is going wrong?
It's simple, with the exception of early adopters who are impressed by technology
itself, the failed products do not deliver to the majority of end users, any
perceived benefits valuable enough beyond what already exists in the marketplace
to motivate a buying change. And, without that motivation, inertia and fear of
change guides the buying decision making process.
As technologists, engineers tend to focus on the technology first, then the product
function second. We need to keep in mind that the technology is just the vehicle used
to deliver the function. To stretch that analogy a bit further, it's like delivering
a package to the end user. There are many ways to send a package, each with a
particular cost-performance benefit. But, ultimately, whatever the delivery
vehicle, the end user still expects to receive the whole package at the time of
delivery. We technologists are sometimes more interested in designing the vehicle
than the delivering the package! There is nothing sadder than company thrashing in
the marketplace with an innovative technology in search of a solution.
While no one can guarantee a marketing success, there a couple of things we designers
can do at the beginning of a design program to enhance the product's probability of
success.
First, do a real market analysis. Identify and understand real market needs -
don't become a "market mirage" chaser. Then, before specifying anything, budget time
with the market analysis people to write a comprehensive product requirements/function
definition. This document is not a specification, but a non-technical definition - from the end users perspective - of what needs the product must address, and and how it will function to meet those needs. An end user review is particularly helpful here
Second, only when you have a firm handle on the product requirements, should you
begin to write the product specification. Review the specification and cross-reference
each product feature against a product requirement. If a feature does match a
requirement eliminate it.
Finally, don't design in a vacuum. Prototype early and frequently and bring perspective
end users into the design process! The first prototype should be a quick concept
evaluation prototype. The earlier you catch design flaws, the easier and
least expensive they are to fix.
The quick concept evaluation prototype does not have to look like the final product,
but it must perform the basic function of the final product. The quicker you get
the concept model into the hands of users/evaluators, the quicker you will determine
if you are on the right track. More importantly, Market place requirements shift in
time - sometimes very quickly. You will discover if your users agree that your
solution still meets their needs while you still have time to make a design course
correction
|
Some applications require switching
high voltage AC, such as 120VAC lights and fans directly. The MB4001 MechaBlox card
Quad Relay Controller makes switching AC signals easy.
