A product is only as good as the question it answers.
I'm Ushaan, a Product Manager at Pexus Tech. Most of my work happens before anything gets built: finding out why it needs to exist, who it is for and what "done" should mean. Then I see it through to release.
8,000+ students served by a portal I built from scratch
10+ company tenants on a multi-tenant MIS I own
50+ people led across 7+ specialised teams
4+ years in software delivery, from developer to PM
Seven questions I ask before anything gets built
Not a process diagram. These are the questions I keep coming back to, in roughly this order, on every product I work on.
Why does this need to exist?
Understand the problem. A request is usually someone's proposed solution. Before anything is written down, I want the problem underneath it: what isn't working today, for whom, and what it costs them.
In practice: On AttendEase, requirements start with client elicitation, before anything reaches an SRS or a PRD. (AttendEase · Pexus Tech)
Who are we building this for?
Understand the people. The person asking is rarely the only person affected. A product used by staff, teachers and students serves three groups whose needs don't always agree.
In practice: AttendEase is used by 500+ staff and teachers. Its student portal, built from scratch, serves 8,000+ students across 5+ institutions. (AttendEase · Pexus Tech)
What does success look like beyond shipping it?
Define what success means. "Done" should be agreed before the work starts, not argued about afterwards. Writing it down early gives everyone the same finish line.
In practice: I define acceptance criteria for every requirement, so engineering and QA share one basis for sign-off. (AttendEase · Pexus Tech)
Are we solving the right problem, or just what was requested?
Challenge assumptions. Feasibility comes before commitment. An honest effort estimate is often when a request turns out to be bigger, smaller or different from what anyone assumed.
In practice: At Islington College's IT R&D unit, I ran feasibility and effort estimates before accepting projects, matching scope to each client's business goals and technical requirements. (Multi-team delivery · IT R&D)
What matters most, and what can wait?
Prioritise. Saying yes to everything is also a decision, and usually a costly one. A trade-off should be visible to the people it affects, not quietly absorbed by the team.
In practice: Change requests are logged in ClickUp, with in-scope and out-of-scope decisions recorded in sprint and PI plans. On Odoo MIS, one shared backlog is ordered across 10+ company tenants. (AttendEase and Odoo MIS · Pexus Tech)
Who needs to be involved, and when?
Align people and resources. Plans tend to break where one team hands work to another. A roadmap is only useful if it shows who is needed, when, and what they are waiting on.
In practice: Portfolio roadmaps covering tasks, timelines, milestones and resource allocation, for 50+ people across 7+ specialised teams. (Multi-team delivery · IT R&D)
What happens when it meets the real world?
Deliver, learn and improve. Release is when the real feedback starts. A launch date should follow what testing found and when data can move safely, not the date we hoped for.
In practice: Launch timelines set from security (VAPT) findings, and data migrations planned around server and database moves. (AttendEase · Pexus Tech)
One request. Two ways to answer it.
An illustrative scenario, not a client story. The request: "Can we add a new report to the dashboard by the end of the month?" A client on a multi-tenant product, two weeks before a release.
The request arrives. What do you do first?
Estimate it and add it to the next sprint.
Ask what decision the report is meant to support. (my choice)
Ask why before how. A report is a proposed solution. If the real need is spotting a problem early, a report might not be the best answer: a change to a view people already use could do more. So I ask why before I estimate.
It turns out only one tenant is asking.
Build it for them. They asked first.
Check whether other tenants have the same need. (my choice)
Check who else it affects. On a shared platform, one tenant's request becomes everyone's product. If the need is common, it goes on the shared backlog and is prioritised like everything else. If it isn't, it may be configuration, or a change request with its own scope.
The date is fixed, and the sprint is already full.
Squeeze it in and quietly push something else back.
Log it as a change request and make the trade-off visible. (my choice)
Make trade-offs visible. If something has to move to make room, the client should see what moves. In-scope and out-of-scope decisions go into the sprint plan, where everyone can read them.
The feature works on the test server. Ship it?
Yes. It works, and the deadline is close.
Only once it meets the agreed criteria and is safe to release. (my choice)
Define "done" before you ship. Working is not the same as done. Acceptance criteria agreed up front decide sign-off, and security findings and data migration decide the launch date.
From building it to owning it · Pexus Tech · 2022 – Now
What changes when the person who built the app becomes the person who decides what it should be?
I joined AttendEase as a Flutter developer and shipped it to Google Play and the App Store. Today I own it as Product Manager. Knowing how it is built shapes the questions I ask about what it should become.
8,000+ students on the student portal
500+ staff and teachers
5+ educational institutions
The problem: Institutions rely on attendance and college records every day, and each one brings its own requests. The product has to keep taking those requests on while scope, quality and launch readiness stay under control.
My part: The product lifecycle: requirements, scope decisions, delivery coordination and launch timing. Engineering, QA and the security team built, tested and assessed it.
The constraint: Each institution has its own requests, but they all share one product that has to stay stable.
Write every requirement with acceptance criteria. Functional and non-functional needs, each with a clear basis for sign-off, so "done" is agreed rather than argued about.
Weigh change requests in planning, never absorb them. In-scope and out-of-scope decisions are recorded in sprint and PI plans in ClickUp, so the cost of each change is visible.
Let readiness set the launch date. Launch timelines follow security (VAPT) findings and data-migration windows, not the other way round.
What changed: A student portal built from scratch, now serving 8,000+ students across 5+ educational institutions. AttendEase itself is used by 500+ staff and teachers.
One platform, many companies · Pexus Tech · Jul 2025 – Now
When ten companies share one product, whose request comes first?
Odoo MIS is a multi-tenant management information system. I own product work across its HRMS and Procurement modules, from discovery and backlog prioritisation through to release.
10+ company tenants
2 modules owned: HRMS and Procurement
The problem: Every company on the platform shares one product and one backlog. Work done for one tenant has to hold up for all of them.
My part: Product ownership of HRMS and Procurement: requirements, backlog prioritisation and delivery through release.
The constraint: Tenants' needs differ, but the platform can't fork for each one.
Understand needs in discovery, before they become tickets. Tenant needs are explored before they reach the backlog, so what gets prioritised is understood, not just requested.
One shared backlog, not a queue for each client. Ordering a single backlog across 10+ tenants keeps the platform coherent and the trade-offs between tenants explicit.
Carry prioritised work all the way to release. Ownership continues from discovery through release, module by module, rather than ending at the specification.
What changed: HRMS and Procurement taken from discovery through release, on a platform serving 10+ company tenants.
Many projects, one pool of people · IT Research & Development, Islington College · Dec 2023 – Jul 2025
How do you keep five large projects moving with one shared pool of specialists?
As Associate Project Manager at Islington College's IT R&D unit, I planned and oversaw 5+ large-scale, multi-tenant projects for educational institutions, marketing organisations and IT offices.
50+ people led
7+ specialised teams
5+ large-scale projects
The problem: Several large projects ran at once and drew on the same specialists. Two decisions sat with me: which projects to accept, and how to allocate people so every project kept moving.
My part: Delivery across the portfolio: leading and allocating work for 50+ people in frontend, backend, QA, DevOps and database teams.
The constraint: The same specialists were needed by several projects at the same time.
Estimate before accepting. Feasibility and effort estimates came before any commitment, with scope matched to each client's business goals and technical requirements.
One portfolio roadmap instead of a plan per project. Tasks, timelines, milestones and resource allocation in one view, so a decision on one project showed its effect on the others.
Scope AI Tutor tightly. I defined the product scope for a RAG-style chatbot that answers strictly from the PDFs and books users upload.
What changed: Delivery of 5+ large-scale, multi-tenant projects planned and overseen across 7+ specialised teams.
Not everything was mine end to end. Here is exactly what was.
Bug bounty platform · Delivery: Managed project delivery and progress
A bug bounty platform where my role was project management: keeping delivery on track against its planned timeline.
Skills, traced to where they were used
Product strategy & roadmapping: AttendEase: Own the product lifecycle across requirements, feature development, delivery and quality. Odoo MIS: Own HRMS and Procurement from discovery and backlog prioritisation through release. Multi-team delivery: Built and maintained portfolio roadmaps covering tasks, timelines, milestones and resource allocation.
Requirements elicitation & business analysis: AttendEase: Lead client requirement elicitation. Other products: Shaped the business logic behind Ticketing: how tickets are raised, routed to departments and resolved.
SRS & PRD authoring: AttendEase: Author the SRS and PRDs for the student portal and feature requests, covering functional and non-functional needs.
Acceptance criteria: AttendEase: Define acceptance criteria for every requirement, as the basis for engineering and QA sign-off.
Backlog prioritisation: Odoo MIS: Order one shared backlog across 10+ company tenants.
Scope & change management: AttendEase: Run change control in ClickUp, recording in-scope and out-of-scope decisions in sprint and PI plans. Multi-team delivery: Ran feasibility and effort estimates before accepting projects. Other products: Owned change requests on inRol and Pexus Ingine, both live systems.
Agile & sprint planning: AttendEase: Scope decisions made in sprint and PI planning with the team.
Stakeholder management: AttendEase: Work with clients on requirements and with the security team on launch timing. Multi-team delivery: Aligned scope with each client's business goals and technical requirements. Other products: Kept the Hackarena team aligned with priorities and deadlines.
Resource allocation: Multi-team delivery: Led and allocated work across 50+ people in 7+ specialised teams.
Risk & release readiness: AttendEase: Coordinate security risk analysis (VAPT) and set launch timelines from the findings. Plan data migrations during server and database moves. Other products: Tracked Hackarena's progress and helped clear delivery blockers.
Technical understanding: AttendEase: Built and deployed the Flutter apps to Google Play and the App Store, integrating Spring Boot backends. Multi-team delivery: Defined the product scope for AI Tutor, a RAG-style chatbot that answers only from uploaded documents.
Google Project Management: Professional Certificate, Google. Courses: Foundations of Project Management; Project Initiation: Starting a Successful Project; Project Planning: Putting It All Together; Project Execution: Running the Project; Agile Project Management; Capstone: Applying Project Management in the Real World
Cloud Computing Core Concepts, CompTIA
Introduction to Cybersecurity, Cisco Networking Academy
Crash Course on Python, Google
Introduction to Psychology, Yale University
Swim Australia Teacher, Swim Coaches & Teachers Australia
MBA Dissertation · MBA in Project Management · Quantitative · Survey · 316 IT professionals · Research completed · Dissertation submitted · Publication pending
A survey of 316 IT professionals found that both constraints predicted more micromanagement, their direct effects on motivation were not statistically significant, and micromanagement positively mediated the relationship between the constraints and motivation.
Outside product work
Creative Head & Admin / Senior Swim Teacher, Swimming Everyday Nepal · Jan 2024 – Now. I teach children with special needs, including children with autism and Down syndrome.
Final Year Project Supervisor, Islington College: I supervise the final-year projects of 35+ BSc IT students.
Experience
Product Manager, Pexus Tech
Jul 2025 – Now · Kathmandu, Nepal
Own AttendEase, a biometric attendance tracking and reporting platform used by 500+ staff and teachers, and built its student portal from scratch: now serving 8,000+ students across 5+ educational institutions.
Lead client requirement elicitation and author the SRS and PRDs, covering functional and non-functional needs.
Define acceptance criteria for every requirement, giving engineering and QA a clear basis for sign-off.
Run change control in ClickUp, recording in-scope and out-of-scope decisions in sprint and PI plans with the team.
Coordinate security risk analysis (VAPT) with the security team and set launch timelines from the findings.
Plan and schedule data migrations during server and database migrations.
Own Odoo MIS, a multi-tenant management information system serving 10+ company tenants, including its HRMS and Procurement modules.
Own product definition for a Student Enrollment System, an end-to-end enrolment platform for academic institutions.
Contribute across other Pexus Tech products: feature ownership on Certify, inRol and Tracking; business-logic input on Ticketing; change requests on Pexus Ingine; and delivery management for Hackarena.
Final Year Project Supervisor, Islington College
2024 – Now · Kathmandu, Nepal
Supervise the final-year theses of 35+ students on the Bachelor's in IT programme.
Guide students through conceptualisation, research, development, documentation and presentation of their projects.
Mentor students, facilitate brainstorming sessions and give constructive feedback that shapes their ideas.
Associate Project Manager, IT Research & Development, Islington College
Dec 2023 – Jul 2025 · Kathmandu, Nepal
Led and allocated work across 50+ cross-functional members in 7+ specialised teams (frontend, backend, QA, DevOps, database).
Planned and oversaw delivery of 5+ large-scale, multi-tenant projects for educational institutions, marketing organisations and IT offices.
Ran feasibility and effort estimates before accepting projects, aligning scope with each client's business goals and technical requirements.
Built and maintained portfolio roadmaps covering tasks, timelines, milestones and resource allocation.
Defined the product scope for AI Tutor, a RAG-style chatbot that answers strictly from user-uploaded PDFs and books.
Mobile Application Developer, IT Research & Development, Islington College
Aug 2022 – Aug 2024 · Kathmandu, Nepal
Translated product requirements into shipped cross-platform Flutter apps, working closely with product managers and owners.
Built and deployed AttendEase to Google Play and the App Store, integrating Spring Boot backends for a 35% improvement in responsiveness and data sync.
Delivered pixel-perfect UI from Figma at 95% design fidelity.
Session Volunteer, Hour of Code · WLiT Nepal fellowship
Jun 2022 · Sanothimi, Bhaktapur
Volunteered at SOS Hermann Gmeiner School as part of the WLiT Nepal fellowship team.
Helped students understand programming fundamentals such as conditionals and loops.
Guided students through the "Minecraft Hour of Code" puzzles and documented the workshop visually.
Core Organizer / Moderator, Autumn AI · with CodinGame
Aug – Sep 2020 · Islington College × CodinGame
Organised a seven-day AI programming contest with CodinGame to get Islington students practising AI; the wider CodinGame community took part too.
Managed and motivated 451 contestants to submit their first AI.
Oversaw all communication on the server and maintained the code of conduct.
Ran a workshop for mentors and guided the organising team through their assigned tasks.
Education
MBA in Project Management, Islington College (awarded by London Metropolitan University), 2024 – 2025. Distinction, average 71.06%.
BSc (Hons) Computing, Islington College (awarded by London Metropolitan University), 2019 – 2022. First Class Honours, average 73.89%.
Have a problem worth solving?
Start by telling me why it matters. I will bring the rest of the questions.