Ankit's expertise in product development, stakeholder management, and team collaboration was instrumental in driving project success. His keen understanding of customer needs and ability to translate them into actionable product roadmaps was impressive.
The User Problem
When Cotecna acquired a consumer product testing lab business in 2022, they inherited a LIMS (Laboratory Information Management System) that users had essentially rejected.
The numbers told the story: only 15% adoption. Lab technicians were using the system for one thing—registering products for testing—and then immediately abandoning it for their real workflow: paper pages, Excel spreadsheets, and Word documents.
Who were these users?
- Registration staff who logged incoming products
- Lab analysts who performed 2,000+ different tests across 4 testing standards
- Report specialists who compiled results into client-facing documents
The lab analyst would conduct tests and write results on paper pages. The report person would physically collect these pages from around the lab, then manually type everything into a Word document—one value at a time. Save as PDF. Print for signatures. Repeat for every single report. A report that took 30 minutes to test took hours to document.
The Decision
I had two paths:
Option A: Keep adding test configurations to the existing system. This is what the technical team proposed. It would take months, require constant maintenance, and still wouldn't handle edge cases.
Option B: Redesign the architecture to let users handle variation themselves.
I chose Option B, but it required convincing stakeholders to abandon two years of their previous approach.
What I Said NO To
- Adding more hardcoded test configurations
- Building a "training program" to force adoption
- Incremental improvements to the existing workflow
What I Pushed For
- Database restructure to support dynamic configurations
- A form builder that lets users create their own reporting tables
- Connecting form-built tables directly to tests in the system
Strategic Impact
The Lesson
How I apply this now:
When users reject a product, the instinctive response is "they need training" or "they'll adapt." Sometimes that's true. But often, user rejection is intelligent feedback about a fundamental mismatch between the system and their reality.
The diagnostic question I always ask: Are users successfully using other tools to accomplish the same goal? If yes, the product has a design problem, not a training problem.
My methodology: Don't ask users what they want. Watch what they do. The workarounds reveal the requirements.
The architecture principle: If a domain has high variation (thousands of test types, customer-specific requirements, edge cases), don't try to hardcode every variant. Build systems that let users handle variation themselves.