unique candidates since launch
Monthly joining throughput grew from roughly 1.7K in Q1 to 2.1K by July–August, with the peak month crossing 2.2K joins.
~1.7K / month→~2.1K / month+27%
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.
THE 30-SECOND VERSION
Executive Project Briefing
01
CONTEXT
Jio was rebuilding off-roll hiring across 6,000+ Jio Points and Centres, replacing fragmented, high-friction recruitment workflows.
02
MY ROLE
I joined QuickHire during 0→1 as Product Designer, then transitioned into day-to-day Product Management after launch.
03
WHAT I DID
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.
04
OUTCOME
Since launch, QuickHire has served 26.9K+ unique candidates, increased monthly joining throughput and improved post-approval and onboarding turnaround while operating at production scale.
↓ THE FULL STORY
26.9K+Unique candidates processed since launch
+27%Monthly joining throughput · ~1.7K/month Q1 → ~2.1K/month Jul–Aug
22% fasterHAS Approval → Ready-to-Join average turnaround · 3.95 days Jul → 3.07 days Aug
41% fasterRTO / BetterPlace handoff → DOJ average turnaround · 9.2 days Dec → 5.5 days Aug
Operational improvements observed across the QuickHire workflow after launch and during subsequent development.
More candidates moved through the system—and the slowest parts of the funnel got faster.
The strongest evidence is operational: scale increased while post-approval movement and downstream onboarding improved. The figures below use July, August and September MTD for Approval → Ready-to-Join, and December-to-August comparisons for RTO / BetterPlace handoff → Date of Joining.
reached RTJ within two days by September MTD
That share rose from 51.0% in July. Average turnaround fell from 3.95 to 3.07 days by August, while P90 fell from 8 to 5 days by September MTD.
average turnaround by August
Down from 9.2 days in December. The share joining within seven days rose from 67.3% to 78.5%, and the P90 reduced from roughly 21 to 12 days.
What the evidence supports
QuickHire’s clearest demonstrated impact is on recruitment workflow scale, approval speed, onboarding execution, SLA movement and long-tail delay. Thirty-day retention remained in the high-80% range as volume grew, but longer-term retention did not improve consistently, so I treat retention as downstream context rather than direct product impact.
From designing the experience to owning what happened after launch.
PHASE 01: PRODUCT DESIGNER
Simplified the product.
140 → 30 fields
Research, flows, prototypes and candidate/recruiter experience.
PHASE 02: DEC 2025
Helped get it live.
Worked through pilot, implementation constraints and launch readiness.
PHASE 03: FEB 2026
Took day-to-day ownership.
Requirements, PRDs, engineering coordination, operations and production issues.
PHASE 04: 1→10
Started fixing what launch exposed.
Architecture, self-service, integrations, operational visibility and system rules.
The product changed. My job changed with it.
At first, my job was to make a complicated process usable.
140 → ~30
candidate inputs
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.
USER RESEARCH
FLOW DESIGN
PROTOTYPING
USABILITY
DESIGN SYSTEM
WHAT I LEARNED
Simplification is mostly deciding what not to ask yet.
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
Before launch, I designed the intended experience. After launch, I had to deal with the actual one.
A PRODUCT PEOPLE COULD DOWNLOAD
QuickHire reached candidates through the app stores.
The iPhone and Google Play listings show the candidate app in the wild, alongside the job discovery, applications, language selection and assessment steps candidates used.
The Google Play capture shows 10K+ downloads, 54 reviews and a 4.0★ rating; the iPhone listing shows 3 ratings and 5.0★. These are store snapshots, separate from QuickHire’s 26.9K+ unique candidate workflow count.
The hardest problems appeared only after real people started depending on the system.
01 — OPERATIONS
A product can work and still create work.
Repeated emails, corrections and manual interventions showed me where the product was pushing effort onto Operations—and where cases were accumulating in the long tail.
MY RESPONSE
Move recurring actions into self-service, bulk controls and system integrations. As volume grew, RTO → DOJ average turnaround improved from 9.2 to 5.5 days and its P90 reduced from roughly 21 to 12 days.
02 — ARCHITECTURE
Some UX problems aren't UI problems.
Duplicate job journeys were caused by how positions were modeled—not by how the cards looked.
MY RESPONSE
Work with engineering to move candidate intake from position-based to role-based.
03 — DATA
Anecdotes weren't enough.
Support conversations told us what was noisy, but not necessarily where the funnel was slowing down.
MY RESPONSE
Use operational data and status reconciliation to isolate stage-level delays. This showed the most measurable movement after approval: Approval → RTJ and RTO → DOJ.
04 — OWNERSHIP
Every request cannot become a feature.
Business, Operations, recruitment and technology often saw the same problem differently.
MY RESPONSE
Translate requests into the underlying problem, surface edge cases, and work toward a solution that could survive production. Joining throughput increased while post-approval speed improved.
WHAT THE DATA CHANGED
HAS approval was already consistently fast, with more than 90% approved within two days. The measurable bottleneck had moved later in the funnel, so the product focus shifted toward Approval → Ready-to-Join and RTO → Date of Joining.
HAS approval was already consistently fast, with more than 90% approved within two days. The measurable bottleneck had moved later in the funnel, so the product focus shifted toward Approval → Ready-to-Join and RTO → Date of Joining.
Three decisions that changed how I think about product.
DECISION 01 · SYSTEM DESIGN
Stop exposing internal position logic to candidates.
Problem
Multiple vacancies for the same role could create duplicate-looking candidate journeys and repeated evaluation.
What I did
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.
MANY POSITIONS
→
MANY JOURNEYS
↓
ONE ROLE
→
ONE JOURNEY
→
POSITION ASSIGNED LATER
The best UX decision I made here was an architecture decision.
DECISION 02 · OPERATIONS
If the same support request keeps happening, it probably belongs in the product.
Problem
Hiring managers and teams repeatedly depended on central Operations for routine corrections and state changes.
What I did
I converted recurring operational requests into self-service actions, bulk controls and clearer system states across the February and July releases.
Examples
HM WITHDRAW / REJECT
CANDIDATE CORRECTION
REQUISITION EDITING
BULK POSITION ACTIONS
Support volume became one of my most useful forms of product discovery.
DECISION 03 · INTEGRATION
Stop using humans as middleware.
Problem
External staff-allocation data was still travelling through recurring Excel uploads.
What I did
Worked with the teams involved to replace the manual file dependency with direct Better Place API synchronization.
BETTER PLACE
→
EXCEL
→
PERSON
→
QUICKHIRE
↓ becomes ↓
BETTER PLACE API
→
QUICKHIRE
Automation matters most when it removes an entire dependency, not just a few clicks.
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.
BUSINESS
"We need candidates mapped to vacancies."
TECHNOLOGY / PRODUCT
"Position-first intake creates duplicate journeys and brittle state management."
OPERATIONS
"We still need flexibility to allocate candidates where vacancies exist."
MY ROLE
Reframe the problem from "Which position should the candidate apply to?" to "At what point does the system actually need a position?"
POSITION ASSIGNMENT → MOVED DOWNSTREAM
Pushback works better when you bring an alternative model, not just an objection.
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.
LEARNING
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.
LEARNING
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.
LEARNING
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.
01
Design the system, not just the screen.
A better interface cannot rescue the wrong state model.
02
Production is research.
Repeated workarounds reveal where the product is asking humans to compensate for it.
03
Push back with an alternative.
Stakeholder disagreement becomes productive when you can show a stronger model and its trade-offs.
04
Launch is the beginning of evidence.
Before launch, most decisions are hypotheses. After launch, the system starts telling you where you were wrong.
QuickHire taught me how a product changes when people stop reviewing the prototype and start depending on it.
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.
Operational Signals We Tracked
| Signal | Observed movement | What it told us |
|---|---|---|
| Candidate scale | 26.9K+ unique candidates; peak monthly joins above 2.2K | The platform had moved beyond pilot conditions. |
| Monthly joining throughput | ~1.7K in Q1 → ~2.1K by Jul–Aug | Throughput increased by roughly 27%. |
| Approval → RTJ average | 3.95 days in Jul → 3.07 in Aug | Post-approval movement became about 22% faster. |
| Approval → RTJ median | 2 days in Jul–Aug → 1 day Sep MTD | The typical candidate was moving through the stage faster. |
| Approval → RTJ within 2 days | 51.0% in Jul → 62.9% in Aug → 72.4% Sep MTD | More candidates moved through the operational SLA window. |
| Same-day Approval → RTJ | 12.1% in Jul → 17.2% in Aug → 20.0% Sep MTD | The share completing the stage without a day of delay increased. |
| Approval → RTJ P90 | 8 days in Jul → 7 in Aug → 5 Sep MTD | The slowest cases improved, not only the average case. |
| HAS Generated → Approved | >90% within 2 days across Jul, Aug and Sep MTD; more than half approved same day | Approval responsiveness held while volume scaled. |
| RTO → DOJ average | 9.2 days in Dec → 5.5 in Aug | Downstream onboarding turnaround reduced by roughly 41%. |
| RTO → DOJ median | 5 days at launch → 4 days in Aug | Typical onboarding turnaround improved by 20%. |
| RTO → DOJ within 7 days | 67.3% in Dec → 78.5% in Aug | More candidates joined inside the first operational SLA window. |
| RTO → DOJ within 14 days | 84.2% in Dec → 94.8% in Aug | More candidates completed onboarding inside a predictable window. |
| RTO → DOJ P90 | ~21 days in Dec → ~12 in Aug | Long-tail onboarding delay reduced by approximately 45%. |
| Retention context | 30-day retention stayed in the high-80% range; 60-day retention reached ~80.5% for the Jul cohort after ~78.7% across Q2; 90-day retention did not consistently improve | These are observed downstream outcomes. The evidence supports workflow and onboarding impact, not a claim of long-term retention impact. |
2026 Release Details
Feb 20, 2026 — Stabilize
- 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.
Jul 2, 2026 — Restructure
- 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.
What happens when interaction moves beyond the screen?
Project visuals
