I turn complex requirements into products teams can ship.
I'm Ushaan Shrestha, a Product Manager with a software development background and experience across product ownership, project delivery and cross-functional leadership.
I work from discovery to release — translating stakeholder needs into clear requirements, prioritised roadmaps and delivery decisions that balance business goals, technical constraints and user needs.
AttendEase is an education management and attendance platform designed to support the operational needs of educational institutions.
I first contributed as a Flutter developer, building the mobile application, before moving into Product Management and taking ownership of product requirements, scope and delivery.
Role: Flutter Developer → Product Manager · 2022 – present · IT R&D, Islington College · ING Tech
The challenge: 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 release readiness stay under control.
My responsibilities:
Led client elicitation and requirements discovery.
Translated business needs into SRS documents, PRDs and acceptance criteria.
Managed scope, change requests and backlog priorities.
Coordinated delivery across engineering, QA and other stakeholders.
Managed release readiness, weighing security (VAPT) findings before release.
Used my development background to bridge technical and non-technical stakeholders.
Key decision: Instead of accepting every institutional request as an immediate development task, I set clearer requirements, acceptance criteria and change-control decisions to protect the shared product roadmap.
Results and impact:
Student portal built from scratch.
8,000+ students using the student portal.
500+ staff and teachers using AttendEase.
Deployed across 5+ educational institutions.
Visuals (illustrative mockups and diagrams, not production screenshots): Portal & app, Staff view, Students, Mobile app, Delivery flow.
I manage product work across the HRMS and Procurement modules of a multi-tenant management information system serving more than ten company tenants.
The challenge is balancing different organisational requirements without creating fragmented, client-specific versions of the same platform.
Role: Product Manager · HRMS and Procurement · Jul 2025 – present · ING Tech
The challenge: Every company on the platform shares one product and one backlog. Their needs differ, but the platform can't fork for each of them: work done for one tenant has to hold up for all.
My responsibilities:
Discovering and analysing tenant-specific requirements.
Prioritising requests across a shared backlog.
Managing HRMS and Procurement features.
Evaluating change requests against platform-wide impact.
Coordinating with development and QA teams.
Managing requirements from discovery through release.
Key decision: Prioritise common business needs as reusable platform features, rather than continuously creating one-off solutions for individual tenants.
Results and impact:
HRMS and Procurement taken from discovery through release.
One platform serving 10+ company tenants.
Payroll salary calculation updated to align better with applicable tax-law requirements.
Visuals (illustrative mockups and diagrams, not production screenshots): HRMS, Multi-tenancy, Employees, Payroll, Procurement.
At Islington College's IT R&D unit, I coordinated large-scale projects across education, marketing and technology initiatives.
With several projects sharing specialist people, delivery needed more than tracking deadlines: feasibility assessment, capacity planning, stakeholder alignment and portfolio-level prioritisation.
Role: Associate Project Manager · Dec 2023 – Jul 2025 · IT Research & Development, Islington College
The challenge: Several large projects ran at once and drew on the same frontend, backend, QA, DevOps and database specialists. Two decisions sat with me: which projects to accept, and how to allocate people so every project kept moving.
My responsibilities:
Project feasibility and effort estimation.
Portfolio roadmap and timeline planning.
Resource allocation across 7+ specialist teams.
Coordination across 50+ team members.
Scope definition and delivery oversight.
Stakeholder and cross-functional communication.
Key decision: Establish feasibility and effort estimates before accepting a commitment, so project scope matched the people available.
Results and impact:
5+ large-scale, multi-tenant projects planned and overseen.
50+ people coordinated across 7+ specialised teams.
A tightly scoped AI Tutor: answers come only from the PDFs and books users upload.
Visuals (illustrative mockups and diagrams, not production screenshots): Roadmap, Timeline, Allocation, Status, Coordination.
How I work: good product decisions start with better questions
My approach to product management is built around understanding the problem, challenging assumptions, making trade-offs visible and helping teams move towards clear decisions.
"A product is only as good as the question it answers."
Discovery: Understand the actual problem.
Questions I ask: Why should this exist? Who is it really for? Which problem, exactly?
I start with elicitation: the client, the people who will use it and the decision a request is meant to support, before anything becomes a ticket.
What it produces: Requirements elicitation, Stakeholder and tenant discovery.
Definition: Translate the problem into clear requirements.
Questions I ask: What does "done" mean? What are we assuming?
Needs become SRS documents and PRDs, functional and non-functional, each requirement with acceptance criteria that engineering and QA can sign off against.
What it produces: SRS and PRDs, User stories, Acceptance criteria.
Delivery: Keep teams aligned on scope and expectations.
Questions I ask: What moved, and who decided? Does every team know?
Changes are logged and decided in sprint and PI planning, one roadmap shows every project, and work is allocated so each team knows what is in and out of scope.
What it produces: Change control in ClickUp, Sprint and PI plans, Portfolio roadmaps, Resource allocation.
Evaluation: Validate outcomes and identify what needs improvement.
Questions I ask: Is this what they need? What happens after launch?
Work is accepted against its criteria, security findings decide whether a release is ready, and what users ask for after release feeds the next round of change requests.
What it produces: Acceptance sign-off, Release readiness (VAPT), Post-release change requests.
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 at one of several companies on a shared platform. Release in two weeks; Sprint already full; One backlog shared by every company.)
Discovery: A stakeholder requests a new dashboard report.
A. Say yes, estimate it and start building. What happens: Two days in, it turns out 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 needs one trend each 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 request escalates, and the real need is still unknown. Why: Protects the roadmap, but leaves the need unknown and the stakeholder unheard.
My call: Understand what business decision the report needs to support before defining the feature.
Scope: One company has requested a feature.
A. Check whether other tenants 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.)
B. 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.
C. Make it fully configurable for everyone, now. What happens: Scope triples, and the board meeting comes and goes. Why: Builds for imagined needs before the real one is confirmed.
My call: Validate whether other tenants share the same need before deciding whether to introduce it as a shared platform capability.
Prioritisation: The deadline is fixed, but the sprint is already 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. 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.
C. Log a change request and show what has to move. What happens: The stakeholder picks a lower-priority item to move. Everyone agrees before work starts. Why: The people who own the priorities decide, with the cost in front of them. (My call.)
My call: Document the change request and communicate the delivery trade-offs.
Delivery: Testing identifies an unresolved security finding before release.
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. Assess the finding, tell stakeholders and decide on readiness. What happens: The finding is serious, so the release moves by two days. Stakeholders heard early, so there are no surprises. Why: A short, announced delay protects users and trust. A minor finding could ship with a documented fix plan. (My call.)
C. Ship the parts that pass and hold the rest. What happens: Can work if the smaller release still meets the need. Here, it doesn't quite. Why: Sometimes right: it depends on whether the smaller release still answers the request.
My call: Assess the finding, communicate the risks and make a release decision based on readiness.
Additional product experience: the Pexus product suite
Own AttendEase and Odoo MIS from requirements to release, and contribute across the Pexus product suite.
Own AttendEase, a biometric attendance tracking and reporting platform used by 500+ staff and teachers; built its student portal from scratch, now serving 8,000+ students across 5+ institutions.
Own Odoo MIS, a multi-tenant MIS for 10+ company tenants, including its HRMS and Procurement modules.
Lead client requirement elicitation and author SRS documents, PRDs and acceptance criteria for engineering and QA sign-off.
Run change control in ClickUp, recording in-scope and out-of-scope decisions in sprint and PI plans.
Coordinate security risk analysis (VAPT), report progress to stakeholders and set launch timelines from the findings.
Plan and schedule data migrations during server and database moves.
Own product definition for a Student Enrollment System, an end-to-end enrolment platform for academic institutions.
Final Year Project Supervisor, Islington College (2024 – Present)
Supervise the final-year theses of 35+ BSc IT students.
Guide students from conceptualisation and research through development, documentation and presentation.
Mentor students, run brainstorming sessions and give feedback that shapes their ideas.
Associate Project Manager, IT Research & Development, Islington College (Dec 2023 – Jul 2025)
Planned and oversaw large, multi-tenant projects across specialist teams.
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.
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)
Built and shipped the AttendEase apps in Flutter.
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 UI from Figma designs at 95% design fidelity.
Earlier, and in the community:
Session Volunteer, Hour of Code · WLiT Nepal fellowship (Jun 2022): Helped students at SOS Hermann Gmeiner School learn programming basics.
Core Organizer / Moderator, Autumn AI · with CodinGame (Aug – Sep 2020): Organised a seven-day AI programming contest and motivated 451 contestants to submit their first AI.
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%.
About: A developer's understanding. A product manager's perspective.
I started my career in software development, building mobile applications and working closely with APIs, backend systems and engineering teams.
Over time, I moved towards product and project management, where I found my strengths in understanding business problems, translating requirements into actionable plans, and coordinating teams to deliver meaningful solutions.
My experience spans educational technology and multi-tenant enterprise platforms, working across product discovery, requirements engineering, roadmap planning, backlog prioritisation and release management.
I enjoy working at the intersection of business, technology and people — particularly where competing priorities, technical constraints and multiple stakeholders need a clear direction.
Capabilities and technical background
Product Management (Deciding what to build, and why): Product discovery, Product strategy, Roadmap management, Backlog prioritisation, Product ownership, Stakeholder management.
Requirements Engineering (Turning needs into something buildable): Business analysis, Requirements elicitation, SRS, PRDs, User stories, Acceptance criteria, Change management.
Project and Delivery Management (Getting it shipped across teams): Agile (Scrum), Sprint planning, PI planning, Resource allocation, Project feasibility, Release management, Cross-functional coordination, Data migration planning, DSDM, Lean Six Sigma.
Technical Background (Why engineering conversations move quickly): Flutter, Dart, Java, Spring Boot API integration, REST APIs, SQL, Application integrations. From building and shipping apps as a developer, and overseeing engineering work since.
Tools (Where the work is planned and shared): ClickUp, Trello, GitHub, GitLab, Slack, Figma, Canva.
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
Research: The relationship between workplace constraints, micromanagement and employee motivation.
This quantitative MBA dissertation examined how tight deadlines and resource constraints relate to micromanagement practices and employee motivation within the IT sector.
Based on survey responses from 316 IT professionals, the research found that both constraints significantly predicted micromanagement. Their direct relationships with employee motivation were not statistically significant. However, the indirect relationships through micromanagement were positive and significant.
Sample: 316 IT professionals
Method: quantitative survey
Theory: Resource-Based View and Self-Determination Theory
Project constraints and micromanagement: Both tight deadlines and resource constraints significantly predicted an increase in micromanagement practices.
Direct effects on employee motivation: The direct effects of tight deadlines and resource constraints on employee motivation were not statistically significant.
The mediating role of micromanagement: Accounting for the project constraints, micromanagement showed a significant positive relationship with employee motivation, and the indirect relationships from both constraints to motivation through micromanagement were positive and statistically significant.
These are statistical associations from a survey; they do not establish cause and effect.
Beyond work
Creative Head & Admin / Senior Swim Teacher, Swimming Everyday Nepal · Jan 2024 – Present. I teach children with special needs, including children with autism and Down syndrome.
I'm always interested in connecting with people building meaningful products, and teams that value thoughtful product decisions, clear communication and effective delivery.
I'm open to Product Manager, Product Owner and product delivery opportunities, particularly within remote-first teams.