A product is only as good as the question it answers.
I'm Ushaan, a Product Manager at Pexus Tech. I start every product by finding out what we're actually trying to solve, then see it through to release.
What are we actually trying to solve? (Illustrative.) "Can we add an export button to this page?" Why? The team copies these numbers into a spreadsheet. Why? A weekly report is built from that spreadsheet, by hand. The problem isn't a missing button. It's a report someone rebuilds by hand every week.
Seven questions I ask before anything gets built
Why does this need to exist?
Understand the problem. A request is usually someone's proposed solution. I look for the problem underneath it before anything is written down.
In practice: AttendEase requests start with client elicitation, before any SRS. See the case study
Who are we building this for?
Understand the people. The person asking is rarely the only person affected, and the people affected don't always want the same thing.
In practice: AttendEase serves staff, teachers and students at once. See the case study
What does success look like beyond shipping it?
Define success. "Done" should be agreed before the work starts, not argued about afterwards.
In practice: Every AttendEase requirement carries its own sign-off criteria. See the case study
Are we solving the right problem, or just what was requested?
Challenge assumptions. An honest estimate is often the moment a request turns out bigger, smaller or different than anyone assumed.
In practice: At IT R&D, projects were estimated before they were accepted. See the case study
What matters most, and what can wait?
Prioritise. Saying yes to everything is also a decision, usually a costly one. Trade-offs should be visible, not quietly absorbed.
In practice: Odoo MIS runs one backlog for every company on it. See the case study
Who needs to be involved, and when?
Align people and resources. Plans tend to break where one team hands work to the next. A plan should show who is needed, when, and what they wait on.
In practice: IT R&D roadmaps tracked people and timelines across projects. See the case study
What happens when it meets the real world?
Deliver and learn. Release is where real feedback starts. A launch date should follow what testing finds, not the date we hoped for.
In practice: AttendEase launch timing follows its security findings. See the case study
One request. Four decisions. You make the call.
Illustrative scenario, not a real client or project. The request: "We need a new report on the dashboard before our board meeting at the end of the month." (Operations lead, one of several companies on a shared platform. Release in two weeks; Sprint already full; One backlog shared by every company.)
Ambiguity: The request lands in your inbox. What do you do first?
A. Say yes, estimate it and start building. What happens: Two days in, the client explains the board needs a different figure. Half the work is thrown away. Why: Feels responsive, but commits effort before anyone knows what the report is for.
B. Ask what decision the report is meant to support. What happens: The board wants to see one trend every week. An existing view covers most of it; one filter is missing. Why: Costs one conversation and turns a vague request into a clear need. (My call.)
C. Decline: it isn't on the roadmap. What happens: The client escalates to their account manager. The real need is still unknown. Why: Protects the roadmap, but leaves the need unknown and the client unheard.
What wasn't obvious: A report is a proposed solution. The need is the decision behind it.
Ask why before how. I ask why before I estimate. "No" without understanding is as risky as "yes" without it.
Scope: The need is real, but only this company has asked for it.
A. Build a custom version just for them. What happens: Fast for them, but now there is a one-off to maintain in every release. Why: A quick win for one client becomes a permanent cost for the platform.
B. Check whether other companies need it too. What happens: Two others had asked for something similar. It becomes a platform feature on the shared backlog. Why: A shared need belongs on the shared backlog; a unique one gets its own scope. (My call.)
C. Make it fully configurable for everyone, now. What happens: Scope triples. The board meeting comes and goes. Why: Builds for imagined needs before the real one is confirmed.
What wasn't obvious: On a shared platform, one company's request becomes everyone's product.
Check who else it affects. If the need is common it belongs on the shared backlog. If it isn't, it's a change request with its own scope and price.
Prioritisation: The date is fixed and the sprint is full.
A. Squeeze it in and quietly push something else back. What happens: Another commitment slips. Nobody agreed to it, and it surfaces at release. Why: Hides the trade-off from the people who should be making it.
B. Log a change request and show what has to move. What happens: The client picks a lower-priority item to move. Everyone agrees before work starts. Why: The client decides what moves, with the cost in front of them. (My call.)
C. Ask the team to work overtime. What happens: It fits, just. Testing gets squeezed and the next sprint starts tired. Why: Moves the cost onto the team, and onto the next sprint.
What wasn't obvious: Every yes is paid for by something. The question is who decides.
Make trade-offs visible. If something has to move, the client should see what moves. In-scope and out-of-scope decisions go where everyone can read them.
Delivery: It works on staging. One security finding is still open and the release is tomorrow.
A. Ship it and patch later. What happens: On time, with a known risk now in production. Why: Meets the date by moving the risk into production.
B. Hold until it's fixed and accepted, and tell the client today. What happens: It ships two days later. The client heard early, so there are no surprises. Why: A short delay, announced early, protects both trust and users. (My call.)
C. Ship the parts that pass and hold the rest. What happens: Can work, if the smaller release still answers the board's question. Here, it doesn't quite. Why: Sometimes right: it depends on whether the smaller release still meets the need.
What wasn't obvious: Working is not the same as done.
Define "done" before you ship. Agreed acceptance criteria decide sign-off, and security findings decide the launch date. Telling the client early keeps their trust.
Every institution wanted something different from the same product.
A college management and attendance platform. I first built its mobile apps as a Flutter developer; now I own it as Product Manager.
My role: Flutter developer → Product Manager
8,000+ students on the portal
500+ staff and teachers
5+ institutions
The central decision: Treat every new request as a scope decision made in planning, not something quietly absorbed.
Context and problem: Institutions rely on attendance and college records every day, and each one brings its own requests. The product has to keep taking them on while scope, quality and launch readiness stay under control.
I owned: Requirements: client elicitation, SRS and PRDs; Scope decisions and change control; Delivery coordination; Launch timing. Others owned: Engineering built it; QA tested it; The security team assessed it.
Write every requirement with acceptance criteria. Engineering and QA share one definition of finished.
Weigh change requests in sprint and PI planning. In-scope and out-of-scope calls are recorded, not implied.
Let readiness set the launch date. Timing follows security (VAPT) findings and migration windows.
Constraints: One shared product, many institutions with their own requests. Launches depend on security findings and data-migration windows. The trade-off: Visible change control over quick yeses, even when absorbing a request would have been faster.
Delivery approach: Elicit requirements → Write SRS and PRDs → Define acceptance criteria → Control change in sprint and PI plans → Assess security, plan migrations → Set the launch date
A student portal built from scratch, now serving 8,000+ students across 5+ educational institutions.
AttendEase in use by 500+ staff and teachers.
Earlier, as its developer: Spring Boot integration that improved responsiveness and data sync by 35%.
10+ companies, one backlog. Whose request comes first?
A multi-tenant management information system. I own product work on its HRMS and Procurement modules.
My role: Product Manager, HRMS and Procurement
10+ company tenants
2 modules owned
The central decision: Order one shared backlog across every tenant, instead of running a queue for each client.
Context and 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.
I owned: Discovery of tenant needs; Backlog prioritisation; HRMS and Procurement, through to release.
Understand needs in discovery, before they become tickets. What gets prioritised is understood, not just requested.
One shared backlog, not a queue per client. The platform stays coherent and trade-offs stay explicit.
Carry prioritised work all the way to release. Ownership doesn't end at the specification.
Constraints: 10+ companies share one platform and one backlog. Their needs differ, but the platform can't fork for each one. The trade-off: Platform coherence over speed for any single tenant: work for one has to hold up for all.
Delivery approach: Discover tenant needs → Prioritise one backlog → Deliver HRMS and Procurement → Release
HRMS and Procurement taken from discovery through release.
Several large projects, one shared pool of specialists.
At Islington College's IT R&D unit, I planned and oversaw large, multi-tenant projects for education, marketing and IT clients.
My role: Associate Project Manager
50+ people led
7+ specialised teams
5+ large-scale projects
The central decision: Accept a project only after a feasibility and effort estimate, so commitments match the people available.
Context and 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 that every project kept moving.
I owned: Feasibility and effort estimates; Portfolio roadmaps; Allocating work across 50+ people; Product scope for AI Tutor.
Estimate before accepting. Scope was matched to each client's goals and requirements.
One portfolio roadmap across all projects. A decision on one project showed its effect on the others.
Scope AI Tutor tightly. A RAG-style chatbot that answers only from documents users upload.
Constraints: Several large projects ran at the same time. They shared frontend, backend, QA, DevOps and database specialists. The trade-off: "Not yet" up front over overload later: projects were accepted only after they had been estimated.
Delivery approach: Feasibility and effort gate → Align scope to client goals → One portfolio roadmap → Allocate across 7+ teams → Track progress
5+ large-scale, multi-tenant projects planned and overseen for educational institutions, marketing organisations and IT offices.
50+ people coordinated across 7+ specialised teams.
Bug bounty platform. My level of ownership: Delivery (Managed project delivery and progress).
A bug bounty platform where my role was project management: keeping delivery on track against its planned timeline.
Where the thinking comes from
Experience
Product Manager, Pexus Tech (Jul 2025 – Now): Own AttendEase and Odoo MIS, from requirements to release.
Final Year Project Supervisor, Islington College (2024 – Now): Supervise the final-year projects of 35+ BSc IT students.
Associate Project Manager, IT Research & Development, Islington College (Dec 2023 – Jul 2025): Planned delivery of large multi-tenant projects across 7+ teams.
Mobile Application Developer, IT Research & Development, Islington College (Aug 2022 – Aug 2024): Built and shipped the AttendEase apps in Flutter.
Session Volunteer, Hour of Code · WLiT Nepal fellowship (Jun 2022): Helped school students learn programming basics.
Core Organizer / Moderator, Autumn AI · with CodinGame (Aug – Sep 2020): Organised a seven-day AI contest for 451 contestants.
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%.
Capabilities
Discover (Find the real problem): Requirements elicitation, Business analysis, Discovery, Feasibility and effort estimates. Seen in: AttendEase, client elicitation; Odoo MIS, tenant discovery; Multi-team Delivery Portfolio, feasibility gate; Ticketing, business logic.
Define (Agree what done means): SRS and PRD authoring, Acceptance criteria, Scope definition, Business rules. Seen in: AttendEase, SRS, PRDs, criteria; Multi-team Delivery Portfolio, AI Tutor scope; Ticketing, routing rules.
Prioritise (Decide what comes first): Backlog prioritisation, Roadmapping, Scope and change control, Stakeholder alignment. Seen in: Odoo MIS, one shared backlog; AttendEase, change control; Multi-team Delivery Portfolio, portfolio roadmaps; Pexus Ingine, change requests.
Deliver (Ship it, together): Agile and sprint planning, Resource allocation, Delivery coordination, Progress tracking. Seen in: Multi-team Delivery Portfolio, resource allocation; AttendEase, sprint and PI plans; Hackarena, delivery management; Certify, feature delivery.
Improve (Release safely, keep evolving): Release readiness (VAPT), Data-migration planning, Enhancements to live products, Legacy product evolution. Seen in: AttendEase, security and migrations; inRol, live-system enhancements; Certify, tenant enhancements; Pexus Ingine, evolving features.
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 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.