My Users Were Research Scientists, Not Developers
At IIT Bombay's Nano-bios Lab, I was the sole interface between 5 research scientists and the engineering implementation of a collaboration platform. The scientists were the most demanding users I have ever worked with — not because they were difficult, but because they had precise, domain-specific workflows that I had zero prior knowledge of.
The brief was simple: replace scattered email threads and WhatsApp messages with a proper async collaboration tool. I started, as many first-time builders do, by assuming I understood what 'replace email' meant. I did not.
What Watching People Work Actually Reveals
After the first demo, a senior researcher opened their laptop and showed me how they actually collaborated. They would share a YouTube video of a lab session, write time-stamped email threads with comments like 'at 4:32, note the crystallization pattern,' and manually compile responses from 4 colleagues.
The product I needed to build wasn't a chat app. It was a time-stamped video annotation and discussion platform. The YouTube API integration became the core feature — because that was the actual user workflow.
Shipping on a 2-Week Cadence with Real Users
We moved to a 2-week release cadence. Each sprint started with a 30-minute session where I asked the scientists what had gotten easier and what still felt painful. I translated those conversations into technical specs. This tight feedback loop meant we shipped 6 meaningful iterations in 12 weeks.
The Lesson That Stayed With Me
Research scientists replaced email threads entirely with the platform within 4 weeks of launch — not because I told them to, but because the tool fit their actual workflow. That's the only metric that matters for internal adoption: does it reduce friction for the way people actually work, not the way you assumed they work?