A Prototype Is Not a Product: The Gap Indian MedTech Must Cross

    India has no shortage of engineers, researchers, clinicians, entrepreneurs and ideas.

We see prototypes being developed in laboratories, universities, hospitals, startups and innovation centres.

But there is a question that deserves much more attention:

What happens after the prototype works?

A working prototype is an important achievement.

But it is not yet a product.

The prototype creates excitement

When a prototype successfully demonstrates its intended function, it is natural to feel that most of the difficult work is over.

In reality, another set of challenges begins.

Can it be manufactured consistently?

Can the design be reproduced without depending on the person who originally built it?

Has it been properly tested and validated?

Can a clinician or customer actually use it comfortably and reliably?

What documentation is required?

What happens when something fails in the field?

Can the required components be sourced reliably?

Can it be maintained?

Can it be produced at a cost that makes sense?

And perhaps the most uncomfortable question:

Who is actually going to buy it?

Engineering success and product success are different

A technically successful prototype answers one important question:

"Can we make it work?"

A product has to answer many more:

"Can we make it reliably, safely, repeatedly, affordably and sustainably?"

That difference is easy to underestimate.

A prototype can be made by a highly skilled team working with considerable flexibility.

A product needs repeatability.

A prototype can tolerate improvisation.

A product needs defined processes.

A prototype may depend heavily on the knowledge of its creators.

A product needs knowledge to be transferred into designs, specifications, documentation and systems.

This is where engineering, operations, quality, regulatory understanding, manufacturing and business development start coming together.

India's opportunity is bigger than developing prototypes

I think India has an enormous opportunity in MedTech.

We have a large healthcare market, engineering talent, manufacturing capabilities, clinicians who understand real-world problems and an increasingly strong innovation ecosystem.

But developing another prototype shouldn't always be the objective.

The bigger achievement is taking a useful idea all the way to a product that can actually reach patients and healthcare professionals.

That requires a different mindset.

Instead of asking only:

"Can we build it?"

we should also ask:

"Can we build the next 100, 1,000 or 10,000 units with the same quality?"

That question changes the entire development process.

The missing middle

There is often a gap between:

Research → Prototype

and

Product → Market

The space in between is where many promising ideas struggle.

This is where activities such as:

• design refinement
• verification and validation
• documentation
• quality systems
• regulatory planning
• supplier development
• manufacturing engineering
• costing
• usability
• service and maintenance
• intellectual property
• distribution
• customer feedback

become important.

None of these are as exciting as unveiling a prototype.

But they are what turn an invention into something useful at scale.

We should celebrate the second milestone too

Perhaps our definition of innovation needs to become broader.

We celebrate when someone develops a new technology.

We celebrate when a prototype is demonstrated.

We should also celebrate when that technology survives the much less glamorous journey from:

Prototype → validated product → manufacturing → market → real-world use.

That is innovation too.

And in a country like India, perhaps it is one of the most important forms of innovation.

Because the ultimate value of a MedTech innovation isn't in the prototype sitting on a demonstration table.

It is in the technology reliably reaching the person who needs it.

---

A small observation from my own learning

The more I learn about MedTech and product development, the more I realise that innovation is not a single event.

It is a chain.

A brilliant idea can fail.

A mediocre idea with excellent execution can sometimes succeed.

And a genuinely valuable technology needs both:

good engineering + good execution.

That is probably one of the most important lessons I'm taking from being around this ecosystem.

The prototype is the beginning, not the destination.

When a Process Depends on One Person, Is It Really a Process?

     

PERSON-DEPENDENT → PROCESS-DRIVEN

One thing years in operations have taught me is that a process can appear to be working while actually being completely dependent on one person.

The work gets completed. Deadlines are met. Problems are solved. Everyone feels that the system is functioning.

But then that person goes on leave, moves to another role, resigns, or simply becomes unavailable.

Suddenly, everything starts slowing down.

Questions that should have had clear answers start appearing:

Who is responsible for this?

What is the next step?

Where is the information?

What was agreed earlier?

Who needs to follow up?

Why wasn't this documented?

This is where an important distinction becomes visible.

A person making a process work is not the same as a process being capable of working.

The hidden dependency

In many organisations, particularly as teams grow, certain individuals gradually become the "person who knows."

They know whom to call.

They remember what happened last time.

They know which vendor responds quickly.

They know which approval usually takes longer.

They know where an old document is stored.

They know what needs to be pushed and when.

Their experience is extremely valuable.

But if all of that knowledge exists only with the individual, the organisation has created a dependency rather than a system.

The person may be highly capable.

The process may still be weak.

Good operations should reduce unnecessary dependency

This does not mean every decision should be converted into a complicated SOP.

That can create another problem: organisations sometimes respond to operational problems by creating excessive documentation that nobody actually uses.

The objective should be much simpler.

A good process should make it reasonably clear:

What needs to happen → Who owns it → When it needs to happen → What information is required → What does completion look like?

The exact level of documentation will depend on the work.

Some processes may need detailed SOPs.

Others may only need a checklist, a responsibility matrix, a tracker or a clearly defined workflow.

The important thing is that the work should not depend entirely on someone's memory.

The test I find useful

There is a simple question that can reveal a lot about an organisation:

"What happens if the person currently handling this is unavailable tomorrow?"

If the answer is:

"Someone else can pick it up because the process and information are clear."

That's a healthy sign.

If the answer is:

"We need to ask that person."

Then there may be a dependency worth examining.

This doesn't mean the person is the problem.

Usually, the opposite is true.

The organisation may have relied on that person's initiative and experience for so long that the underlying process was never properly converted into a system.

People are still important

There is a danger in taking this idea too far.

Organisations are made of people. Experience, judgement, relationships and initiative cannot be completely replaced by procedures.

The goal isn't to make people unnecessary.

The goal is to make sure that people add judgement and value instead of repeatedly compensating for gaps in the system.

An experienced employee should be able to improve a process.

They shouldn't have to personally hold the entire process together.

From individual effort to organisational capability

For me, this is one of the differences between simply getting work done and building operational maturity.

In the short term:

"I'll take care of it."

can solve the problem.

But as an organisation grows, the better question becomes:

"How do we make sure this gets taken care of reliably, whoever is responsible?"

That shift is not always easy.

It requires clarity, documentation, ownership, communication and continuous improvement.

But once that shift happens, the organisation becomes less fragile.

The objective of good operations is therefore not to eliminate individual contribution.

It is to turn individual experience into organisational capability.

Simple idea. Hard to implement.

Principle and operation of stylus probe instruments

 Principle and operation of stylus probe    instruments

Direct Instrument Measurements (Metrology):

These methods enable to determine a numerical value of the surface finish of any surface. Nearly all instruments used are stylus probe type of instruments. These operate on electrical principles. Further, these electrical instruments can be of two kinds. In first type, they operate on the carrier-modulating principle. The movements of the stylus exploring the surface are caused to modulate a high frequency carrier current. The second type includes those operating on voltage-generating principle. In these the movements of the stylus are caused to generate a voltage signal. In both these types the output has to be amplified and the amplified output is used to operate a recording or indicating instrument .The carrier modulated frequency type of instruments have the advantage that the signal fed to the recorder depends only upon the position of the stylus. While in the voltage generating type, when the oscillatory movement of the stylus stops, the output falls to zero no matter where the stylus may be.Some pneumatic instruments are also used for measuring surface finish.