How to connect product functions to technology solutions

An engineering team may be asked to add a vibration sensor to a pump. Before comparing sensors, clarify the job: detect developing bearing deterioration early enough for maintenance to intervene. A vibration sensor is a candidate solution. The function is early detection. Stating them separately leaves room to examine alternatives.

IfM's T-Plan approach connects market, product and technology perspectives. Its product discussion includes features, functions and attributes; the technology discussion examines potential ways to provide them. An organisation can use familiar engineering terminology while preserving those relationships. [1]

For a manufacturing team, a useful starting record contains the need, the required function, the operating conditions and the evidence needed to accept a solution. The product function should remain recognisable when a preferred technical implementation changes.

Consider a fictional pump manufacturer exploring a retrofit monitoring unit. Its customer need is to reduce unexpected stoppages. Its proposed functions are detecting deterioration, installing without a lengthy shutdown, and operating in a demanding environment. The team has not yet established a detection threshold or a commercial business case.

Accelerometer sensing and ultrasonic sensing are two candidate approaches to detection. A magnetic mount addresses installation. A sealed housing addresses the operating environment. These choices belong to different parts of the argument: ranking every component in one undifferentiated list would hide that distinction.

A promising detection approach still needs trials against representative faults, false alerts and the actual installation conditions. A component specification is evidence about the component; it is not yet evidence that the complete product will deliver the customer outcome.

Put product functions on one axis and technology options on the other. For each relevant relationship, record whether the technology supports the function, creates an adverse effect, has no material relationship, or has not yet been assessed. Keep the explanation beside the judgement.

An unassessed relationship should remain unknown. Treating it as zero makes missing knowledge look like evidence of no effect. Negative relationships also matter: a mounting approach might ease installation but weaken measurement quality under particular conditions.

Avoid adding numbers from unlike criteria simply because the grid permits it. Agree the scale and interpretation first. If the team uses weighted scores, test whether a plausible change to an uncertain score or weight reverses the choice. The result is a prompt for investigation, rather than a proof of technical suitability.

Roadmap architecture makes the relationship between layers and time explicit. A technology option should connect to the function it enables and to the need behind that function. [2]

In the pump example, put bench qualification before the installation pilot. Put the pilot decision before tooling or a wider rollout commitment. Give the evidence gap an owner and a review point: who will check false alerts, by when, and what finding would change the selected approach?

The next conversation can then be specific. Are we ready to commit to accelerometer sensing? Do we need a comparison trial? Is the installation constraint more important than our present estimate suggests? A readable roadmap exposes those questions while choices are still open.