QuickHire
I joined QuickHire to design the product. I ended up learning how to own one.
QuickHire is Jio's off-roll hiring platform across its distributed operations. I worked on it first as a Product Designer during its 0→1 journey, then transitioned into day-to-day Product Manager ownership after launch—moving from flows and usability to requirements, engineering, operations, stakeholder decisions and platform evolution.
Jio was rebuilding off-roll hiring across 6000+ Jio Points and Centres, replacing fragmented, high-friction recruitment workflows.
I joined QuickHire during 0→1 as Product Designer, then transitioned into day-to-day Product Management after launch.
I simplified the candidate journey from roughly 140 inputs to ~30, then used production evidence to reshape job-role architecture, turn recurring operational support into self-service capabilities, and replace manual data movement with system integrations.
QuickHire launched in December 2025 and became the operating platform I now manage and evolve. Production shifted my work from designing flows to making product and system decisions at scale.
From designing the experience to owning what happened after launch.
The product changed. My job changed with it.
At first, my job was to make a complicated process usable.
candidate inputs
The early candidate journey asked for roughly 140 inputs. My work focused on understanding what was actually necessary at application stage, what could move downstream, and how the flow could work on mobile for distributed hiring.
We brought the initial experience down to roughly 30 essential inputs while retaining the information needed to move candidates forward.
Launch changed the product. It also changed my role.
After QuickHire launched in December 2025, the existing PM moved to broader recruitment systems. Production issues, operational exceptions and new requirements still needed an owner.
I began handling that work—and by February 2026, it had become day-to-day Product Manager ownership.
Before — Designer
- Research
- Flows
- Prototypes
- Usability
After — PM
- Requirements
- PRDs
- Engineering
- Operations
- Releases
- Data
The hardest problems appeared only after real people started depending on the system.
A product can work and still create work.
Repeated emails, corrections and manual interventions showed me where the product was pushing effort onto Operations.
Move recurring actions into self-service, bulk controls and system integrations.
Some UX problems aren't UI problems.
Duplicate job journeys were caused by how positions were modeled—not by how the cards looked.
Work with engineering to move candidate intake from position-based to role-based.
Anecdotes weren't enough.
Support conversations told us what was noisy, but not necessarily where the funnel was leaking.
Use operational data and status reconciliation to identify recurring failure points.
Every request cannot become a feature.
Business, Operations, recruitment and technology often saw the same problem differently.
Translate requests into the underlying problem, surface edge cases, and work toward a solution that could survive production.
Three decisions that changed how I think about product.
Stop exposing internal position logic to candidates.
Multiple vacancies for the same role could create duplicate-looking candidate journeys and repeated evaluation.
I worked with the technology lead to challenge the position-first model and push candidate intake toward Job Role + Location, with specific position allocation happening later in the funnel.
Why it mattersThe solution required changing the underlying model—not redesigning the interface.
If the same support request keeps happening, it probably belongs in the product.
Hiring managers and teams repeatedly depended on central Operations for routine corrections and state changes.
I converted recurring operational requests into self-service actions, bulk controls and clearer system states across the February and July releases.
ExamplesStop using humans as middleware.
External staff-allocation data was still travelling through recurring Excel uploads.
Worked with the teams involved to replace the manual file dependency with direct Better Place API synchronization.
Product ownership meant disagreeing without blocking the product.
QuickHire sits between senior HR leadership, national recruitment teams, Operations and engineering. Those groups often approach the same issue from different constraints.
My job is not to "win" those discussions. It is to make the trade-off visible, identify edge cases early and translate a business direction into something the system can actually support.
The useful lessons came from what kept breaking.
Operations became the analytics layer
We did not begin with a mature product-analytics setup. For a period, production queries and manual reconciliation were the clearest signal of where the system was struggling.
Instrumentation should be designed before you need it.
Manual work survived the digital product
Even after digitizing hiring, some critical processes still depended on Excel, email and central Ops.
Digitizing the interface does not mean you've digitized the system.
Launch did not mean "done"
Several of the most important structural decisions came months after the product was already live.
0→1 proves something can exist. 1→10 proves it can survive.
What I actually own.
I Drive Day-To-Day
- Requirement discovery
- PRDs / BRDs
- Product solutioning
- Stakeholder coordination
- Engineering clarification
- Operational triage
- Release coordination
- Workflow/data analysis
Shared
- Technical architecture
- Engineering implementation
- QA / SIT
- Integrations
- Production rollout
Leadership Sign-off
- Final strategic prioritization
- Major policy decisions
- Executive approvals
- Business rules requiring senior approval
My role sits between business intent, engineering reality and what Operations encounters every day.
I came into QuickHire thinking mostly like a designer. I leave each release thinking more like a product owner.
Design the system, not just the screen.
A better interface cannot rescue the wrong state model.
Production is research.
Repeated workarounds reveal where the product is asking humans to compensate for it.
Push back with an alternative.
Stakeholder disagreement becomes productive when you can show a stronger model and its trade-offs.
Launch is the beginning of evidence.
Before launch, most decisions are hypotheses. After launch, the system starts telling you where you were wrong.
Want the actual product mechanics? Open full case study →
The portfolio story above focuses on my contribution. The full case study covers the hiring architecture, workflow changes, February and July releases, validation logic, operational visibility and upcoming platform work.
The Hiring Journey
QuickHire connects workforce demand, candidate discovery, assessments, recruiter actions, hiring-manager decisions, approvals, position allocation and downstream onboarding. A state change in one part of the system can determine what several other users are allowed to do next.
2026 Release Details
- Rejection traceability: Added structured rejection-reason capture across dashboards.
- Approval context: Enriched candidate cards with contextual business attributes.
- Candidate correction: Built a dedicated self-service interface to modify erroneous data.
- Pipeline controls: Enabled hiring managers to execute withdrawals directly.
- Role-based intake: Prevented duplicate applications and simplified candidate discovery.
- API Synchronization: Deprecated manual Excel uploads for Better Place sourcing data.
- Bulk operations: Shipped bulk position-locking and state-override capabilities.
- Requisition self-service: Granted hiring teams self-service editing privileges.
Upcoming Platform Work
Auto-Approval Rule Engine: Defining rules that allow standard cases meeting approved criteria to pass automatically while routing exceptions for manual review.
Background Verification: Bringing verification status and compliance visibility closer to the core hiring workflow.