Intense Team
An employee monitoring and productivity product. The project that changed how I think about product design — and put me in front of a payroll system I had to learn from zero.
This is the project that talked me out of believing polish was the job. It’s also the most unfamiliar territory I’ve designed in — a domain I had to learn before I could design anything useful in it.
Intense Team is a product for monitoring and measuring employee productivity — the kind of tool that lives or dies on whether it ships something useful fast, not on how complete the first version looks. Partway through, I was asked for something well outside a normal design brief: a complete payroll system for the Nepalese market.
I had no real background in payroll or Nepalese taxation before this. I had to learn the rules well enough to design a system that calculated them correctly, on a deadline that didn’t leave room to learn slowly — while still thinking about it as a product, not just a form that produces the right numbers.
Making it pretty was never going to be enough here. It had to be correct, and it had to ship.
This is where I want to be careful rather than tidy: I don’t have hard numbers to put here yet — adoption, accuracy in production, how the payroll module held up once real payroll runs went through it. That’s the honest gap in this case study right now, and I’d rather flag it than dress it up.
That a polished interface proves nothing on its own. Products need to ship with the features that matter first, get in front of real users, and improve from what actually happens — not from how confident the mockups looked in review. This project is where “ship, learn, improve” stopped being a slogan and became something I actually did under pressure, in a domain I didn’t start out understanding.
Also still open — I want to give this a real answer rather than a generic one. Coming back to this once I’ve properly reflected on it.