Parents and students
Find the right mapped products, understand the order lifecycle, and get help without repeatedly chasing support.
StudentKare · Product case study
Turning a fragmented school-supply platform into an operating system people could trust
StudentKare looked like an e-commerce product from the outside. In practice, every parent order depended on a much larger system: school mappings, POS counters, warehouse planning, physical handovers, approvals, reporting, and support. My work was to connect those moving parts into clearer product decisions and buildable workflows.
- Role
- Product owner · Senior Executive Product
- Company
- StudentKare · Hubblehox
- Timeline
- 2023–2025
- Scope
- B2C · POS · Handover · Procurement · Reporting
The product behind the storefront
A parent-facing marketplace was only the visible edge of the system
StudentKare served several connected models at once: direct B2C shopping, school and business partnerships, student-specific B2B2C commerce, seller operations, and internal administration.
A partner school could onboard students and employees, control which products each person was eligible to buy, take assisted orders at a school POS counter, plan kits against student strength, move stock between centres, and monitor fulfilment. A parent experienced one order. The organisation had to make the entire chain work.
That distinction shaped my role. I was not prioritising isolated screens. I was translating operating problems into a coherent product model: who could do what, which data each step needed, where approvals sat, which exceptions were safe, and how the teams would know whether the system was working after release.
One platform, four jobs
I framed the work as four connected product layers
The layers gave design, engineering, operations, procurement, finance, and leadership a shared picture of what we were actually fixing.
POS and school teams
Process a queue quickly, verify student context, capture special orders, and hand over kits with fewer workarounds.
Warehouse and procurement
Translate student strength into kit and SKU demand, compare it with inventory, and act on shortages or surplus.
Operations, finance, and leadership
See what is delayed, reconcile money and stock, spot exceptions, and make decisions from the same operational truth.
What the workflow revealed
We were forcing an operator to shop like a parent
The turning point came from watching POS executives work at school counters, then connecting those observations with support tickets, parent feedback, and operational discussions.
Around 70% of the observed workflow involved operators copying SKU IDs from the indent form a parent brought with them. They were not browsing. They already knew the student and the required items. Yet the product pushed them through a consumer journey: search, product listing, product detail, variant selection, cart, and checkout—repeated for every item.
A normal order could contain 8–12 products. The old flow took roughly 3–5 minutes per student, loaded too much catalogue data at once, and made the operator manually calculate cash change while handling a queue. The interface was not merely untidy. Its mental model was wrong for the job.
Intervention 01 · Execution
The product decision was to optimise for processing, not browsing
We reduced the flow from five or six screens to two and made student context the organising principle.
A consumer storefront at a service counter
- ×Full e-commerce navigation and product grids
- ×A product-detail step for every size or colour variant
- ×Repeated add-to-cart loops across 8–12 items
- ×Large catalogue loads that slowed peak-hour work
- ×Manual cash-change calculation at checkout
A student-first processing tool
- ✓Search by enrolment, application, guardian, or student details
- ✓Mapped products and SKU variants visible in one list
- ✓Inline quantity and selection with persistent checkout
- ✓Pagination limited the first load to 50 SKUs
- ✓Cash received and change due calculated automatically
Small details that protected the flow
Speed was not the only requirement
The simplified route still had to handle the messy realities of school commerce.
Sticky student details
Student information stayed visible while the operator scrolled through SKUs, so faster processing did not remove the verification step.
Custom-size orders
Measurements, acknowledgement, editability, longer delivery expectations, and non-returnable rules were captured inside the same POS flow.
Real counter scenarios
Cash, card, credits, partial discounts, write-offs, and special cases needed clear reasons and traceable behaviour—not a single ideal checkout.
Post-launch signal
The redesigned POS made the daily task materially faster
The project record reported a checkout time below one minute after rollout, down from roughly three to five minutes in the earlier flow.
Reported POS checkout time
after the redesigned two-screen flow
Core order route
student and SKU selection, then checkout
Initial page load
a deliberate performance constraint
A product judgment worth making explicit
“Make it like Amazon” was a familiar brief—and the wrong product model
Amazon assumes broad choice, interchangeable sellers, and a customer free to buy almost anything. StudentKare depended on enrolment-led mappings. A parent with three children could have three different catalogues. A Grade 5 CBSE student and a Grade 8 ICSE student were not choosing from the same supply pool.
I framed the pushback as a structural mismatch, not a preference about UI. Copying a general marketplace would expose unavailable products, weaken school controls, and create demand that operations could not fulfil. The better principle was controlled relevance: show the right person the right catalogue, then make the valid action fast.
Intervention 02 · Physical fulfilment
A stalled handover decision was resolved by following the operator’s mental model
Two senior stakeholders had competing ideas: start from warehouse stock, or start from product-to-student mapping. Both contained part of the truth, but neither covered the full handover reality alone.
School teams needed to receive kits, hand over a full kit or selected components, handle returns, and preserve who received what. The same people already used the POS. Reusing its language and interaction patterns gave us a third answer: keep inventory truth underneath, but let the user work through familiar student and product relationships.
That decision did more than settle a design review. It reduced the learning burden, made partial handovers and returns natural extensions of existing flows, and gave leadership a user-grounded reason to align. It was a useful reminder that stakeholder compromise is not always the best outcome; a better product model can make the disagreement obsolete.
Intervention 03 · Planning and control
We connected demand planning, procurement, and organisational buying
The internal product had to move from broad modules to clearer decisions, definitions, and handoffs.
NSS → kits → SKUs
Net Student Strength created the demand baseline. Kit planning compared predicted need with available BOMs; SKU planning translated that demand into stock, open purchase orders, commitments, and actual availability.
Separate structure from mapping
I proposed merging BOM creation with child-SKU management while keeping school, grade, board, term, and subject mapping separate—reducing duplicate work and accidental edits.
Design around integration limits
Manual NSS upload reduced API dependency. Stock transfers and returns were defined with history, permissions, and acknowledgement, while SAP updates stayed manual where direct integration was not available.
Organisation procurement
A shopping list became a controlled purchase request
The requester and approver journeys were designed as one state machine, not two unrelated pages.
- 01
Choose the buying context
Users could switch between self-purchase and organisation purchase, with products filtered to the applicable catalogue.
- 02
Build a compatible shopping list
Categories could be combined only when they shared an approval flow, preventing a request from entering contradictory matrices.
- 03
Route by policy
Matrices supported standard or amount-based approval, sequential or parallel routing, single/multiple/everyone rules, and escalation windows.
- 04
Keep the state traceable
Requesters could see pending, approved, rejected, and withdrawn states. Once every required level approved, the system could place the order automatically.
Intervention 04 · The decision layer
The dashboard started with decisions, not available data
Reporting was fragmented across ERP data, spreadsheets, and verbal updates. Instead of asking stakeholders which columns they wanted, the work started with a harder question: what decision are you trying to make?
Where is work getting stuck?
Centre-wise performance, order states, processing time, fulfilment ageing, and TAT exceptions made bottlenecks visible.
What needs reconciliation?
Payment status, pending amounts, centre-level revenue, returns, and transaction traceability gave finance an actionable view.
What needs attention now?
High-level KPIs, trends, and exception flags replaced broad data dumps with signals leadership could investigate.
A dashboard earns its place when it changes a decision, not when it displays more data.
Product principle from the StudentKare work
One view tracked the ten most-returned products. A clear outlier led the team to investigate product quality and replace the vendor. That was the value of visibility: a problem that had been absorbed as operational noise became specific enough to act on.
The customer layer
Parents were not only frustrated by delays. They were frustrated by silence.
Order delays were sometimes constrained by sourcing and fulfilment. The lack of communication was a product choice we could change. Clear lifecycle states, proactive delay notifications, simpler return and support routes, and student-level order context gave parents something they had not had before: a trustworthy explanation of what was happening.
The same thinking shaped the next support layer. A planned StudentKare assistant was scoped around real jobs—order tracking, FAQs, product help, and escalation into a General Inquiry or Parent Service Request—rather than a chatbot added for novelty.
Results across the system
The useful outcomes appeared at different layers
Post-launch figures below are drawn from the published project record. They are presented as directional evidence alongside the operational decisions they enabled.
POS checkout time
reported down from roughly 3–5 minutes
Fewer tickets breaching TAT
after clearer status and support handling
Customer satisfaction
reported after the connected improvements
Structured decision views
for operations, finance, and leadership
What I would carry forward
The hardest work was keeping one product truth across many teams
The visible screens were the last part of the problem. Before them came definitions: what counted as available stock, when a request became an order, which student could see which product, how a partial handover changed inventory, and which metric meant a team needed to act. If those definitions drifted, every surface drifted with them.
If I were restarting the work, I would establish baseline instrumentation and data ownership earlier. Several outcomes were validated through operational reports and user feedback after the fact. A clearer measurement plan at the start would have made prioritisation sharper and separated shipped impact from directional feedback more confidently.
The lesson I keep is simple: in workflow-heavy products, the PM’s job is not to make every module look connected. It is to make the underlying decisions, states, and responsibilities genuinely connect.