He stepped in and took the lead, even when it wasn't strictly his area.
Read more
He is strong with stakeholders at every level, including the C-level. He also has a real commercial mindset. When he saw a gap, something nobody clearly owned that could hurt his goals or the business, he didn't wait for someone else to pick it up.

Jose Manuel Huerta GuillénDirector of Product, Vertage · led the HeadFirst Group product team, my direct manager

One of the few people I could give a problem to and simply trust that it would get done.
Read more
When we started building OpenTalent from scratch, he took ownership of the product and so much of the work around it, turning ideas into something real and scalable. Seeing OpenTalent grow from zero to a real business and eventually become part of HeadFirst Group was a fantastic journey, and Sanjib played a big part in making that happen.

Pieter van HerpenFounder, OpenTalent (sold to HeadFirst Group) · worked with me directly

Always open to challenge and quick to get to the heart of a problem.
Read more
We spent a lot of time talking through how the platform needed to work, from the functionality and the data to how it would support talent communities and the wider direct sourcing model. He was a really good sounding board, and he brought a lot of product experience and technical expertise to those conversations.

Adam BarrattGlobal Head of Talent Marketing · senior colleague, didn't manage me directly

Even when things became complicated, he stayed focused on finding a practical solution and keeping the client's needs at the centre.
Read more
I often relied on Sanjib to help me understand not just how the product should work, but also the thinking behind it. We also worked together on the Direct Sourcing Implementation Manual, where we brought together learnings from multiple projects and turned them into a practical, repeatable process for future implementations.

Kristin Bille, PMPSenior Project Manager, SaaS Implementations · project manager on US Direct Sourcing launches

How I work

Read all 6 →

PRDv0.2 draft

How I structure a PRD

A hub document with companion specs, explicit deferrals and an owned open-questions register.

Personas15 personas

Persona library

How I organised 15 user types into one shared reference, and the modelling calls that shaped it.

ComplianceGDPR · AU Privacy Act

Privacy & co-employment

Privacy rules written per persona so legal and design could work in parallel.

About

Problems before features.

I start with discovery, sequence an MVP, prototype early, and use AI where it removes repetitive work.

5+ years in product, after 14 years in customer-facing and commercial roles, including running a $50M truck and bus business in Bangladesh. MBA from ESADE. Based in Bengaluru.

Outside work

PaintingIt nurtures my creativity and pushes me to look beyond what meets the eye, and to see the world from different angles.

WatchesQuartz, automatic or digital, I love the craftsmanship and the stories behind them. There is something calming about the rhythmic ticking.

MentoringI help students pursue master's programmes, including MBAs and MS degrees, at leading business schools and universities around the world.

SadhanaI'm an active member of this NGO, which helps underprivileged children realise their potential and promotes yoga for people of all ages.

FamilyAbove all, I'm a husband and the father of a six-year-old daughter. My family keeps me grounded and reminds me what truly matters.

View full CV/Resume →

Skills & tools

Product

Strategy & 0→1DiscoveryPRDs / BRDsPrioritisationExperimentationPricing & packaging

AI

LLM workflowsAI matchingVector searchSkill extraction & taxonomyEvaluation & guardrailsHuman-in-the-loop QA

Platform

MarketplacesB2B SaaSConfigurable workflowsATS / VMS integrationsAPIs & SSO

Tools

ClaudeChatGPTOpenAI APIFigmaJiraConfluenceSQLPower BIDatabricksPendo

Open to Senior PM / AI PM roles

Hiring for a Senior PM or AI PM? Let's talk.

Based in Bengaluru, open to relocation. Happy to walk you through any case study or prototype.

LinkedIn ↗ CV/Resume (PDF) ↓ View CV/Resume →

Case study 01 · HeadFirst Group

Building a Direct Sourcing platform

Turning existing recruitment technology into a Direct Sourcing product, launched in 6 weeks.

Talent portal prototype · fictional data

Role · periodProduct Manager · May 2025 – present

MarketsUS, UK, Europe, Australia, India

ScopeExisting tech to DS product in 6 weeks, 12 epics, 4 legacy clients migrated

Team6 engineers, 2 designers, 1 QA across Europe and the US

€9MDS business the platform supports

30K+Talents in pool

11Enterprise clients

800–1,000Applications / month

▶ Try the 3 clickable prototypes Read the PRD See the personas

problemEnterprises reached talent through MSPs and suppliers. The platform was built for that model, not for sourcing directly.

my rolePM for the product: vision, discovery, PRDs, 12 epics and delivery with 6 engineers, 2 designers and 1 QA.

key decisionConfiguration over customisation: one stage framework every client configures, instead of a build per client.

resultLaunched in 6 weeks. Now 11 enterprise clients in 5 markets and ~30K talents, supporting a €9M business line.

I turned existing technology built for suppliers and MSPs into a Direct Sourcing product in 6 weeks. It now supports a €9M business line and a talent pool the company owns.

Reading mode

The challenge

Same tech, new business model

The technology existed. The Direct Sourcing product didn't.

Enterprises hired contractors through MSPs (firms that run a company's contractor programme) and their supplier networks. Our platform was built for that model, so most of the placement value went to external suppliers. The job was to let enterprises hire from talent pools of their own.

Before · supplier-led

Enterprise client

↓

MSP Runs the programme

↓

Supplier network Owns the candidates

↓

Talent

After · platform-led

Enterprise client

↓

Direct Sourcing platform Configured per client

↓

Own talent pool 30K+ talents

↓

Talent

The tension: every enterprise hires differently, but we could not afford a custom build per client.

My role

My part, the team's part

My part

Vision, MVP scope and roadmap
Discovery with clients, recruiters, MSP teams and talent
BRDs, PRDs and the 12-epic plan
Clickable prototypes and prioritisation
Release decisions, UAT and the AI extraction quality work

The team's part

6 engineers built and architected the platform
2 designers turned validated prototypes into Figma flows
1 QA owned testing
Implementation project managers ran client set-up and go-lives

Prototypes

Click through the product

3 live prototypes

Built with Claude to test ideas with recruiters before Figma or engineering. They run right here, with fictional data.

Talent onboarding prototype: join-community form for a fictional energy company

Talent · AI

AI-assisted onboarding

Upload a CV, let AI pre-fill the profile, review what it suggested, then choose communities and give consent. This is the flow behind the ~30% faster onboarding.

Open prototype →

Talent · best on desktop

Talent portal

Dashboard, community early access, applications, notifications, consent and privacy.

Open prototype →

Recruiter admin prototype: external jobs synced from the VMS, ready to publish

Recruiter / admin · best on desktop

Recruiter workspace

VMS jobs to publish, talent pool, communities and sub-communities. Pick "Northwind Energy" to sign in.

Open prototype →

Hypothesis→Prototype with Claude→Test with recruiters→Figma→Build→UAT→Release↺

Prototypes put something in front of recruiters before design or engineering time was spent. We shipped on a two-week cadence, and after HeadFirst acquired OpenTalent I also led moving OpenTalent's capabilities and 4 legacy clients onto the new platform.

Discovery & strategy

Problems before features

Interviewed clients, recruiters, MSP teams and talent. Highlighted: the stages that forced them into supplier workflows.

I interviewed enterprise clients, internal and external recruiters, MSP teams and talent, and mapped each persona against the hiring journey. The highlighted stages are where people were forced into supplier-centric workflows.

Job creation→Talent discovery→Sourcing→Screening→Shortlisting→Communication→Submission→Hiring→Onboarding

A competitive scan showed where we could differentiate on what we already had. I turned the findings into BRDs and PRDs (how I structure a PRD), split the MVP into 12 epics and ranked them on customer value, business impact, dependencies, strategic fit, MVP necessity and delivery cost.

★ North Star: fill rateDo a client's open roles actually get filled?

About half of my objectives tied directly to business KPIs underneath the fill rate.

Key decision

Configuration over customisation

One stage framework, many client workflows.

Each enterprise had its own candidate stages, approvals and service levels. The easy path was to build whatever each client asked for. I pushed for a stage library that every client configures: switch stages on or off, rename them, and run on one shared product.

Try it · click a stage to switch it on or off for that client

LibraryAppliedScreenedShortlistedApprovalSubmittedInterviewHired

Client A

Client B

Client C

Illustrative clients. Applied and Hired are fixed: every pipeline needs a start and an end.

Tested early: sales wanted a custom build to win one client. It went live on the standard product, with no custom code.

The pushback

The decision was tested early. Our sales and account team wanted a client's own pipeline stages built as a custom feature to win the deal. I showed that the configurable stage framework already covered almost everything they asked for, and turned the one genuinely new need into a configuration option every client can now use. The client went live on the standard product, with no custom code.

The same principle ran through the rest of the product: talent onboarding, the recruiter workspace, integrations with each client's VMS (the system where enterprises post contractor jobs) and ATS, and messaging, all configured rather than custom-built.

AI & growth

Fixing onboarding

~55% of talent dropped off at account creation.

Account creation, before the redesign

~45% continued~55% dropped

Funnel analysis showed the biggest leak came before talent even had a profile, partly because they had to retype their CV. I put AI extraction into the flow and ran experiments on messaging, question order and where consent was asked.

Before

Upload CV→Type it all again→Profile

After

Upload CV→AI extraction→Review→Profile

+~40%Onboarding completion after the redesign

−~30%Time to complete onboarding

−~25%Drop-off from moving consent later in the flow

▶ Try the onboarding prototype

Impact

What changed

11Enterprise clients in 5 markets, one product

30K+Talents in pools the company owns

€9MDirect Sourcing business line the platform supports

~80%Less time from application to hire

~10 secTo surface relevant candidates, at 90%+ precision*

15–20 → 3Days to onboard a supplier, with AI-enabled workflows

~$400KAnnual technology savings from replacing a third-party tool

* Precision = share of AI-suggested candidates in the top results that recruiters shortlisted. "~" figures are rounded internal estimates.

What I learned

Four takeaways

Platform change is not feature work.The hard part was reshaping an existing foundation without piling up one-off customisations.

Configuration is a strategy.In enterprise SaaS, designing for configuration early is what makes the next client cheap to launch.

AI earns its place inside a workflow.The best AI opportunities were the places people spent time on repetitive work.

If I did it again.I'd instrument the onboarding funnel before launch, not after. We found the ~55% drop-off later than we should have.

Case study 02 · OpenTalent → HeadFirst Group

AI talent matching

From a build-or-buy decision to matching that enterprise recruiters trust.

One CV line → skills, with evidence

“Built Power BI dashboards for the finance team and automated monthly reporting in Python (pandas). Some exposure to Azure.”

✓ Power BI✓ pandas! Azure · low depth✕ SQL · no evidence

Illustrative extraction · fictional data

RoleProduct lead, Search & Match

PeriodOpenTalent launch, then HeadFirst (2025 – present)

DomainAI · Search · Talent data

Worked withEngineering, Data/AI, recruiters

~40%Better matching · OpenTalent

~70%Faster to proposal · OpenTalent

90%+Precision* · HeadFirst

~10sTo relevant matches · HeadFirst

* Precision = share of AI-suggested candidates in the top results that recruiters shortlisted.

problemAs the OpenTalent pool passed ~25K talents, recruiters needed automatic matching. Manual search no longer scaled.

my roleProduct lead for Search & Match: build-vs-buy, extraction quality, taxonomy, guardrails and the review loop.

key decisionBuild in-house and accept ~3 extra months, so we controlled how skills were understood and how quality was measured.

resultOpenTalent: ~40% better matching, ~70% faster to proposal. HeadFirst: matches in ~10s at 90%+ precision.

Matching is only useful if recruiters believe the shortlist. I treated trust in the output as the product, and the model as one part of it.

Reading mode

The problem

Finding people was the slow part

At ~25,000 talents, recruiters still searched by hand, and a wrong match cost them credibility with the client.

About a year and a half into OpenTalent, with roughly 25,000 talents on the platform, recruiters told us what they needed: a way to manage their talent pool, post jobs and get candidates matched automatically. Searching by hand did not scale with the pool.

The data made it hard. CVs and job descriptions describe the same skill in many different ways, and a wrong match costs a recruiter credibility with the client. For one key enterprise client, the time from spotting a candidate to proposing them was the metric that mattered.

Key decision

Build, not buy

We took three extra months to own the matching.

Buy

Faster to ship. But a generic engine could not be tuned to our talent data, our clients' requirements or the way recruiters actually shortlist.

Build in-house

About 3 months of extra development. In return: control over how skills are understood, how results are ranked and how quality is measured.

I evaluated both and chose to build. Customisation and control mattered more than the head start, because matching quality was the thing clients were paying for.

How it works

From documents to a shortlist

1IngestCVs from talent, job descriptions from clients and VMS feeds

2ExtractSkills pulled into a fixed output schema

3EvidenceEach extracted skill tied back to the source text

4NormaliseMapped to a controlled taxonomy with rules

5EmbedProfiles and jobs turned into vectors

6SearchVector search finds candidates in seconds

7ReviewRecruiter checks and shortlists

8 ↺QA loopHuman review feeds fixes back into extraction

A hybrid: LLM extraction, vector search for recall, rules for predictability. I owned what counted as a correct extraction; engineering owned the search.

The result is a hybrid: AI and LLM extraction, vector search for recall, and rule-based controls for predictability. I owned the product side of steps 2 to 4 and 7 to 8: what counted as a correct extraction, the taxonomy, the guardrails and the review loop. Engineering owned the embeddings and vector search, and we worked on matching quality together.

Quality

Making the output trustworthy

Quality came from a fixed set of controls around the model, so recruiters could trust what reached them.

Controlled taxonomyOne name per skill, so "React.js" and "ReactJS" match the same jobs

Output schemasExtraction returns a fixed structure, not free text

Evidence-basedNo skill without a line in the CV to back it

Rule-driven normalisationPredictable mapping that people can audit

GuardrailsCatch empty, invented or out-of-schema results

Human QAReviewed errors become the next round of fixes

How I measured it

Candidates matched→Candidates proposed→Match-to-proposal conversion·Precision and true-positive quality

Example

What extraction actually does

Illustrative

A simplified walk-through of one CV line through extraction, evidence, normalisation and the guardrail. Fictional data; it shows the method, not real output.

Input · CV snippet

Senior Data Analyst, 2019–2024. Built Power BI dashboards for the finance team and automated monthly reporting in Python (pandas). Some exposure to Azure.

Output · structured, with evidence

Extracted skill	Evidence quoted from the CV	Normalised to
Power BI	"Built Power BI dashboards"	Power BI · BI & visualisation
pandas	"in Python (pandas)"	Python › pandas
Report automation	"automated monthly reporting"	Reporting automation
Azure	"Some exposure to Azure"	Microsoft Azure · flagged: low depth
SQL	none	Dropped: no evidence in the text

The last row is the guardrail at work. A model will happily infer "SQL" from "Data Analyst". Evidence-based extraction drops any skill it cannot quote, and recruiter review catches what slips through.

Impact

Two companies, one capability

OpenTalent · launch

Matching effectiveness: +~40%
Identification to proposal: ~70% faster for a key enterprise client
Client-reported savings: ~80% vs. traditional recruitment

HeadFirst Group · scale

Time to matches: ~10 seconds
Precision*: 90%+ (recruiter-shortlisted)
Clients: 11 enterprise clients, 5 markets
Talent pool: ~30,000 Direct Sourcing talents

After HeadFirst acquired OpenTalent, I led the same extraction-quality work on the Direct Sourcing platform, where CV extraction also became part of talent onboarding.

What I learned

Four takeaways

Quality is a product decision.What counts as a correct match has to be defined by the PM with recruiters, not left to the model.

Clean data comes before clever models.Matching can only be as good as the skill data underneath it, so taxonomy and normalisation got as much attention as the search.

Keep a human in the loop on purpose.Recruiter review was what made the output trustworthy, and it produced the data to improve it.

If I did it again.I'd put recruiters into the quality loop from the first prototype, not after launch.

Case study 03 · OpenTalent

Monetising a two-sided talent marketplace

Building paying products for talent and recruiters, then fixing what made people leave.

Talent Premium · three prices tested

€2.99€4.99 ✓€9.99

Referral reward · interview selection

€5001.0×

€1,0003.1×

From the pricing and referral A/B tests

RoleLead - Product Management & BizOps

PeriodOct 2021 to Jun 2025

MarketNetherlands first, then DE, BE, LU

Scale40,000+ users, 6,000+ recruiters

~€50KMRR

~2,000Paid talent users

~800Paying recruiters

2×Year 2 MRR target

problem40,000 users across talent and recruiters, but little revenue from either side, and talent churned.

my roleLead - Product Management & BizOps, working directly with the founder from discovery to pricing.

key decisionA separate paid product for each side of the marketplace, each priced by experiment rather than guesswork.

result~€50K MRR from ~2,000 paid talents and ~800 recruiters; 2× the Year 2 MRR target.

OpenTalent had users on both sides and little revenue from either. I built a paid product for each side, priced them with experiments, and fixed the churn driver underneath.

Reading mode

Context

A marketplace that needed a business model

OpenTalent connected freelance and contract talent with recruiters and companies. The target customer was a company of 100+ employees with recurring freelance or contract hiring, starting with scale-ups and mid-market in the Netherlands, then Germany, Belgium and Luxembourg. UK entry waited on post-Brexit regulation. Direct competitors were Grensend and SourceRight; LinkedIn, Indeed, Upwork and Fiverr competed for the same attention. I joined as an intern and grew into the product and BizOps lead, working directly with the founder.

Role progression

Strategy & BD intern→BizOps & Customer Success→BD lead→Lead - Product Management & BizOps

I segmented 40,000+ users and 6,000+ recruiters with interviews, surveys and behavioural data to find where acquisition, engagement and monetisation were breaking.

Talent side

A freemium subscription

Priced by testing three price points.

Tested€2.99/ month

Chosen€4.99/ month · €50 / year

Tested€9.99/ month

About 5% of the talent base converted: ~2,000 paid users and ~€10K MRR.

I defined the value proposition, packaging and UX for a free tier and a Premium tier. Premium added a full member profile, messaging, CV downloads, advanced search, early feature access and eligibility for Talent Matcher. I tested three monthly prices and landed on €4.99 a month with a €50 annual option. About 5% of the talent base converted, reaching ~2,000 paid users and ~€10K MRR.

Recruiter side

A recruiter marketplace

MVP in a month, six iterations, 800 recruiters.

After about a year and a half and ~25,000 talents, recruiters needed three things: talent-pool management, job posting and automatic matching. I validated the idea with prototypes and customer feedback, shipped an MVP in about a month and ran six iteration cycles.

Prototype→MVP · ~1 month→6 iteration cycles→500+ recruiters · 8 months→~800 recruiters

At ~€50 a month per recruiter, it became the larger revenue line: ~€40K MRR.

At about €50 a month per recruiter, it became the larger revenue line: ~€40K MRR, four times the talent subscription. Two higher tiers sat on top: Talent Matcher, paid sourcing with finder's fees of up to 50%, and Talent Partner, with a supplier account, client access and faster payment.

Experiment

Pricing a referral

The bigger reward paid for itself.

We surveyed about 2,500 users and ran an A/B test with 750 to 800 of them: a €500 referral reward against €1,000.

Referrals (€500 = 1.0×)

€500

1.0×

€1,000

1.6×

Interview-selection rate (€500 = 1.0×)

€500

1.0×

€1,000

3.1×

€1,000 became the live incentive: 2,000+ referrals and 50+ placements.

In the test, €1,000 drove ~60% more referrals, and those candidates were 3.1 times as likely to be selected for interview. We dropped €500 and made €1,000 the live incentive. The programme reached 2,000+ referrals and 50+ placements.

Retention

Fixing why people left

Talent left because there was nothing to apply to.

Churn analysis pointed to job inventory as a root cause. A talent opening the app saw 8 to 10 jobs. I attacked it from several sides: an external jobs API, community initiatives, referrals, and about 35 partners offering 35 to 40 member perks.

Visible jobs, before~8–10

Visible jobs, after3,000–4,000+

Separately, customer research, funnel analysis and experiments lifted monthly active users and repeat logins ~25% within 3 months.

Enterprise

Private talent pools

The idea that led to Direct Sourcing.

Repeat hirers paid high agency fees and lost warm candidates, so we offered them a private talent pool.

Companies hiring the same kinds of roles again and again, about 15+ similar positions a year, were paying high agency fees and could not keep candidates warm in their ATS under GDPR. We offered them a private talent pool in two models.

Self-service

The client runs its own pool on OpenTalent, with product, training and support from us.

Managed service

OpenTalent builds the pool and sources candidates, then brands it as the client's after a trial.

What didn't work

A feature we had to pause

We started building before we checked the law.

Engineering had already started on a platform communication feature when Legal flagged significant compliance complexity. We paused it. The sprint time already spent was lost, and the roadmap slot went to work we could ship.

Bring Legal into discovery

Compliance has to be checked at the idea stage, not after design. I now run a privacy and legal screen on every feature before it enters the roadmap.

Test the riskiest assumption first

I validated that users wanted it, when the riskiest assumption was regulatory. I now rank assumptions by risk before deciding what to test.

Impact

From users to revenue

~€50KMRR: ~€10K talent Premium, ~€40K recruiter marketplace

€50KYear 2 MRR, double the €25K target

~€100KSaaS revenue from 16 retail and 2 enterprise accounts

4US enterprise client launches, all on schedule

I also supported a ~€1.5M pre-seed round and was the main contact during HeadFirst Group's acquisition of OpenTalent, which led into the Direct Sourcing platform.

What I learned

Four takeaways

Each side of a marketplace needs its own paid product.Talent and recruiters valued different things, so they got different offers at different prices.

Test the price, don't guess it.The pricing and referral tests both ended somewhere other than where we started.

Liquidity comes before features.Talent left when there was nothing to apply to, so job inventory became a product priority.

If I did it again.I'd check what the law allowed before what users wanted. I learned that the expensive way, with a lost sprint.

How I work

How I think on paper

Six documents from the Direct Sourcing platform, and the thinking behind each one. The documents stay internal; these are short write-ups with small redacted samples.

Jump to any document

Written by me · AI-assistedReviewed with eng, design & legal

Reading mode

PRD

One hub, many companions

The PRD stays the hub: problem, scope, decisions, open questions. Depth lives in companion documents, each answering one question.

A single PRD for a 12-epic platform becomes unreadable. I kept the PRD as the hub (problem, scope, decisions, open questions) and moved depth into companion documents that each answer one question the PRD would otherwise get wrong.

Companion	The question it answers
Persona library	Who are we building for, and what does each of them need?
Acceptance criteria register	How will we know each story is done?
Handoff register	Where does work pass between people, and what breaks there?
Unhappy paths	What does the product do when things go wrong?
Privacy & consent	What may we collect, on what legal basis, and for how long?
Co-employment chain	How does a legal risk become product behaviour?
Success metrics	How will we know it worked, and when to worry?
Architecture decision records	Which technical decisions are settled, and why?

Every document uses the same story IDs (e.g. REC-07, HM-05), so a single requirement can be traced from persona to acceptance criteria to metric.

Writing down the no's

Most scope fights are about what is not being built. I wrote every deferral down with its reason, so the same argument did not happen every sprint.

Deferred from MVP	Why
Gamification	Core flows must work first. Data fields reserved now so it needs no rebuild later.
Self-service configuration UI	Database config is enough for the first clients; build the UI once patterns settle.
Advanced client reporting	Ship attribution and data export first; dashboards need real data to design well.
One client's sector-specific requirements	Run as a separate project so they cannot override standard MVP decisions.

Redacted sample: four of the deferrals, client names removed.

Owning the unknowns

Every open question names what it blocks and who owns it. By v0.2: 21 open, 6 resolved.

"We're waiting on legal" is not a plan. Every open question named what it blocked, who owned it and its priority. By v0.2 the register held 21 open and 6 resolved questions, about half owned jointly by legal and product.

Priority	Question	Blocks	Owner
Blocking	Is a DPIA required for the AI matching engine in EU deployments?	AI matching cannot go live in the EU	Legal / Product
Blocking	Which email service provider?	No notification can be delivered	Engineering
High	Calendar integration: one provider or two?	Hiring manager interview scheduling	Product

Redacted sample: three of the questions, reworded.

Personas

One shared language

"The user" meant something different to everyone, so I built one persona library every spec, story and metric points to.

A direct sourcing platform serves talent, recruiters, hiring managers, programme managers, procurement, admins and, eventually, AI agents. In early discussions "the user" meant whoever the speaker worked with most. I needed one reference that every spec, story and metric could point to.

What the library settled

Community member is a state, not a userIt sits beneath candidate, contractor and freelancer, so the relationship survives whatever role someone is in.

MoSCoW and MVP are separatePriority describes the full vision; a separate MVP flag decides first go-live. That stopped "must have" from meaning "this sprint".

Design for agents nowAI agents got a persona before any agent feature existed, so permissions and audit trails accounted for them.

The working deck

Interactive persona deck showing the Community Member persona

Talent personas

Goals, journeys, failure states and stories per persona

The working deck I used with design and engineering. Switch persona, then flip between overview, a six-stage journey map, failure states and user stories.

Open the deck →

Journeys & handoffs

Where work passes between people

The worst bugs appeared where work passed between people, and no single team owned those moments.

Each epic had its own spec, but the worst bugs appeared where work passed from one person to the next: a shortlist sent with stale data, feedback that never came back, a notification that never fired. No single team owned those moments.

Approach

I mapped a six-stage journey for each key persona, then listed every point where work passes between personas. For each handoff the register records what is handed over, the state it must be in, what the receiver sees, what breaks if it fails, and how severe that is. It became an input to sprint planning, because most handoffs cross two epics and two teams.

Sample journey · recruiter

ReceiveRequisition arrives and is claimed

SearchCommunity first, warm signals

OutreachPersonal message, risk check

ScreenAssessments, interviews

ShortlistSubmit to hiring manager

Prove ROIPlacement and savings logged

Rules it produced

Compute at the handoffStatus that can change (like compliance risk) is recalculated when work is handed over, never cached from earlier.

Lock what was sentA shortlist locks on submit, so the reviewer sees exactly what the sender intended.

In-platform is the safety netEmail and SMS can fail; the in-platform status must always show the truth.

Redacted: the full register covered 12 handoffs with severity ratings; specifics omitted.

Privacy & consent

Written before design started

Privacy rules written per persona before design, so legal and design could work from the same document in parallel.

The platform holds talent data across the EU, the UK and Australia, under GDPR and the Australian Privacy Act. Legal could not review a design that did not exist yet, and design could not wait for legal. I wrote the privacy rules down per persona first, so both could work from the same document.

What it changed in the product

Layered consentService, marketing, sensitive data and third-party checks are consented to separately, never one "accept all" box.

Floors, not just defaultsClients configure retention, but cannot go below legal minimums; the settings screen blocks it.

Screen before the roadmapEvery feature gets a privacy check before it is prioritised, the lesson from a feature I had to pause.

Co-employment risk

A legal risk as product behaviour

Re-engaging the same contractor can make them an employee in law. I specified that risk as one chain of product behaviour, not six features.

When an enterprise keeps re-engaging the same contractor, the law can treat that person as an employee. The risk sat in spreadsheets and showed up in legal filings. It touched recruiters, hiring managers, procurement, admins and client leadership, so building it as separate features would have produced six inconsistent answers.

I specified it as a single chain: configuration (thresholds per client and jurisdiction), one authoritative data record, a small state machine, what each persona sees and can do, alerts, and where the pipeline enforces it.

ClearNo restrictions

WarningSoft confirmation

ThresholdLogged exception needed

CoolingNew placements blocked

Re-engageInvited back

The calls that mattered

Computed, never storedThresholds change, so status is calculated at query time; a stored status goes stale.

Block early, not lateGates fire when adding to a shortlist, not at offer stage, where a block is far more disruptive.

Right detail per roleRecruiters see the individual; client leadership gets programme-level alerts only.

Redacted: thresholds, data fields and escalation rules omitted.

Metrics & failure states

Floors, not just targets

OutcomeDid the persona reach their goal? Read over 6 to 12 months.

LeadingAn early signal, actionable within 30 to 90 days.

HealthIs the experience sustainable, not just busy?

Every metric has a baseline, a target and an alert floor. The floor matters more: it tells you when something is wrong.

Each metric has a comparison cohort (community vs agency), a baseline recorded before go-live, a target and an alert floor. The floor matters more than the target: it tells you when something is wrong, not how far you are from perfect.

Unhappy paths, designed

Failure states designed up front: be specific, always give a next step, never lose entered data.

I listed the failure states across talent, operations, integrations and go-live: trigger, impact if unhandled, MVP response and design requirement. The principles held across all of them: be specific, always give a next step, never lose entered data, never show stale data as current, and block early.

Sample: CV parsing is unsure

Low-confidence fields stay blank instead of being filled with a guess, and the candidate sees exactly what could not be read. Parsing is an enhancement, never a prerequisite.

Redacted: metric targets, thresholds and the full failure list omitted.

Sanjib
Deka

Product Manager
AI / GenAI · Platforms & marketplaces · B2B / B2B2C

Bengaluru, India · open to relocation Looking for Senior PM / AI PM roles linkedin.com/in/sanjibdeka1989 ↗ Download CV/Resume (PDF) ↓

At a glance

5+Years in product

14Years commercial

€9MDS business the platform supports

30K+Talents on it

~€50KMRR built at OpenTalent

90%+AI match precision

Strengths

0→1 productsProduct strategyDiscoveryPRDs / BRDsAI matchingLLM workflowsAI evaluationMarketplacesPricingExperimentationFunnel analyticsATS / VMS / SSOEnterprise GTM

Tools

ClaudeChatGPTOpenAI APIGeminiSQLPythonPower BIDatabricksFigmaJiraConfluenceHubSpotPendo

Education

Full-Time MBA, General ManagementESADE Business & Law School · 2020–2022

B.Tech., Electrical & ElectronicsNIT Silchar · 2008–2012

Certificate in Product ManagementIndian School of Business · Oct 2026

Six Sigma Yellow Belt · Python for EverybodyCertifications

Profile

Product manager with 5+ years in product and 14 years in customer-facing and commercial roles. I take products from discovery and 0→1 through strategy, roadmap, experimentation, launch and monetisation, and I am strongest at turning messy customer and business problems into scalable product capabilities with engineering, design, AI/data and enterprise stakeholders.

Career

ProductEducationCommercial

HeadFirst Group2025 – now

OpenTalent2021 – 2025

ESADE MBA2020 – 2022

Eicher · Bangladesh2018 – 2020

Eicher · fleet product2018 – 2020

Eicher · India2016 – 2018

Tata Motors2014 – 2016

Signode India2012 – 2014

20122015201820212024Now

Experience

Product Manager, Direct Sourcing

May 2025 – Present

HeadFirst Group · Bengaluru

AI-enabled Direct Sourcing platform across 5 markets.

Own vision, roadmap, discovery, PRDs and KPIs for a platform with ~30,000 talents, 11 enterprise clients and ~€9M annual revenue.
Turned existing tech into the DS product and launched it in 6 weeks; migrated 4 legacy clients.
Cut onboarding time ~30%, job-posting effort ~80% and application-to-hire time ~80%.
Found a ~55% sign-up drop-off; onboarding redesign and experiments lifted completion ~40%.
Led AI quality for CV/JD extraction and matching: matches in ~10s at 90%+ precision.
Supplier onboarding from 15–20 days to ~3; ~$400K annual technology savings.

Case study: Direct Sourcing platform →

Lead - Product Management & BizOps

Oct 2021 – Jun 2025

OpenTalent (acquired by HeadFirst Group) · Amsterdam / Bengaluru

Talent marketplace with 40,000+ users and 6,000+ recruiters. Intern to product lead.

Launched a freemium talent subscription: ~2,000 paid users, ~€10K MRR.
Launched a recruiter marketplace in ~1 month: ~800 recruiters, ~€40K MRR.
Took AI Search & Match from build-or-buy to launch: ~40% better matching, ~70% faster to proposal.
Referral A/B test: ~60% more referrals and 3.1× interview selection.
2× the Year 2 MRR target (€50K vs €25K); supported a ~€1.5M pre-seed round.

Case study: OpenTalent marketplace →

Country Manager, Sales & Product Development

2018 – 2020

Eicher Trucks & Buses (VECV) · Bangladesh

First product role: discovery to MVP for a connected fleet-management product, alongside running the country business.

Shaped a connected fleet-management product; MVP piloted with 3 fleets of 500+ vehicles.
Ran a 140-person organisation: ~$50M a year, share 29% → 35%, key accounts $11M → $15M.

Channel Sales Manager, Northeast & Bhutan

2016 – 2018

Eicher Trucks & Buses (VECV) · India

Bus market share 9% → 16%; expanded into 6 states.

Territory Sales Manager

2014 – 2016

Tata Motors · India

~$10M a year across 8 dealers; share 47% → 51%.

Area Sales Executive

2012 – 2014

Signode India

Regional revenue up 28%; PepsiCo account up ~20%.

More of my work

AI talent matching →Build vs buy, extraction quality, evaluation.

AI Context Optimizer →Personal prototype on LLM cost and quality.

How I work →PRD, personas, journeys, compliance.

Clickable prototypes →Built with Claude, tested with users.

Personal project · 2026

AI Context Optimizer

Sending less to an LLM without losing what the answer needs, and proving it.

Tokens sent · full → trimmed

Noisy dump · 186 notes 46,573 → ~4,500 · −90%

On-topic dump · 76 notes 13,651 → ~8,000 · −40%

✓ Every must-keep fact kept

Claude tokenizer · answer quality within noise

RoleSolo: problem, design, build, evaluation

Built withNode, Express, React, Claude API (Haiku, Sonnet, Opus)

TypeWorking prototype

Tested on9 PM scenarios, up to 47K tokens

▶ Try the optimizer

problemPMs paste whole context dumps into LLMs. That costs money at scale and may not improve the answer.

my roleSolo: problem, pipeline, build and evaluation.

key decisionMeasure what the answer needs, not what the prompt lost: hand-labeled must-keep facts, plus a judge that sees the full context.

resultEvery must-keep fact kept across 9 scenarios. 40% fewer tokens on a realistic on-topic dump, 90% on a noisy one, with answer quality within noise.

"Smaller prompt" is only a win if the answer holds up, and my first way of checking that was wrong.

Reading mode

The problem

We paste everything

PMs paste whole context dumps into LLMs because it is faster than deciding what matters. My question: can you tell, cheaply, what a piece of context adds before you pay to send it?

How it works

Classify, compress, route, evaluate

1ChunkSplit the dump into notes, drop duplicates

2ClassifyHaiku lists the evidence the question needs, then scores each note

3Compress & routeKeep core and supporting notes; pick Haiku, Sonnet or Opus

4CostEach model's tokenizer and prices, net of the filter call

The first version scored notes by keyword overlap (TF-IDF). It still runs free with no API key; the current one asks Claude Haiku 5.5.

Try it

Run the optimizer

Live in your browser

The free keyword version of the pipeline. Pick a sample or paste your own notes. Nothing leaves your browser.

Sample

Question Context (separate notes with a blank line)

Tokens: estimated until the tokenizer loads.

0input tokens, before → after

0%context removed

0%question key terms still present

cheaprouting

Model tier	Cost / call, before	After	Saved

Price per million tokens, input / output: Haiku 5.5 $0.10 / $0.50, Sonnet 5.5 $2 / $10, Opus 5.5 $4 / $20, with a 500-token answer. Tokens use an OpenAI tokenizer; Claude counts about 1.6x more, so real costs run higher.

Show the optimized context

Read the result critically

Keywords can keep an irrelevant note and drop the one that matters, as shown below. That is why the prototype now uses Claude, which needs an API key.

Version 1

Where keywords break

Question: What caused the enterprise churn spike last quarter and what should we prioritize to reduce it?

High0.151Enterprise churn rate rose from 2.1% to 4.7% quarter over quarter, concentrated in accounts under 50 seats.

High0.056Exit survey theme (12 of 19 responses): not enough ROI to justify renewal.

Medium0.042Facilities note about the office move to a new floor.✗ Irrelevant, but kept

Low0.007The most-requested feature shipped in beta, but adoption is 8% among at-risk accounts because it is buried three clicks deep.✗ The most actionable note, dropped

Keyword overlap cannot see that "buried three clicks deep" explains churn. The cheap key-term check read 38% before and after, so it reported no loss.

Key decision

Check the checker

My first LLM judge was fooled.

Haiku answered with full and trimmed context, and Haiku judged both. The trimmer had dropped the root cause, a vendor's new CAPTCHA step, yet the judge preferred the trimmed answer in two of three runs. It never saw the source.

Full context→Answer 1·Trimmed context→Answer 2→Judge, with the full source

Must-keep factsHand-labeled per scenario, checked free and deterministically

Full source, blindGraded against all the notes; answer order alternated

Stronger judgeOpus 5.5 grades answers written by Haiku

Rebuilt, the judge scored the trimmed answer 19 of 25 against 22 to 23 for the full one, and named the missing CAPTCHA step. The fact check became the gate: a change ships only if every must-keep fact survives every run.

Results

Claude as the filter

One Claude Haiku 5.5 call fixed it. The model lists the evidence the question needs, then scores each note against that list, so a root cause that shares no words with the question still counts.

5 small scenarios	Must-keep facts kept	Judge gap, full vs trimmed
Keyword scoring	50–75%	5.2 of 25
Claude Haiku 5.5	100%	0.5 of 25

Then real-size dumps:

Scenario	Tokens, full → trimmed	Facts kept	Judge, full / trimmed
Root cause: a quarter of notes, tickets, interviews and Slack (76 notes, mostly on-topic)	13,651 → ~8,000 (−40%)	100%	20.0 / 19.7
Prioritization: four initiatives, one squad (186 notes, mostly background)	46,573 → ~4,500 (−90%)	100%	20.5 / 22.0

Claude tokenizer. Judge out of 25, averaged over 2 to 3 runs; gaps under 2 points are noise. The 47K dump's background notes are Claude-generated; evidence and traps are hand-written, so treat 90% as the optimistic end.

It pays for itself at real size, not on toy inputs

The filter call costs about $0.003 on the 14K dump and $0.008 on the 47K one. Net of that, input cost fell 8%, 24% and 32% (Haiku, Sonnet, Opus answering) on the on-topic dump, and 65%, 78% and 84% on the noisy one. On 250-token samples it cost more than it saved.

Routing

Most questions don't need the biggest model

The filter call also picks the answering model. To check its picks, the judge graded all three models on every scenario.

Policy, 9 scenarios	Avg score / 25	Answer cost, all 9
Always Opus 5.5	24.2	$0.190
Always Sonnet 5.5	23.8	$0.083
Haiku for lookups, Sonnet otherwise	23.8	$0.060
Always Haiku 5.5	22.5	$0.006

Sonnet tied Opus on "stakeholders disagree" questions at half the price, so Opus is now reserved for evidence the notes can't settle. Haiku for lookups and Sonnet otherwise lands within half a point of always-Opus at under a third of the cost.

What didn't work

Tried, measured, left off

Token budgets

Cut real evidence even at 50%
The model rates many must-keep facts "supporting", not "core"

Splitting long notes

Dropped a fact in 1 of 3 runs
Little headroom: few long notes carry facts

Caching the dump

Cheaper for follow-up questions
Once kept 45K of 46K tokens; fact checks couldn't see it

Caching also fooled the gate: unscored notes are kept to be safe, so every fact survived while the trim did nothing. The benchmark now flags skipped notes.

What I learned

Four takeaways

Check the checker.Each blind spot in my evaluation showed up as a result that looked too good.

Savings depend on the dump.40% on-topic, 90% noisy, a loss on toy inputs. Quote savings on real inputs only.

Model choice is the bigger lever.Decide which questions need a frontier model before compressing anything.

If I did it again.I'd try to break my first good result instead of believing it. My first judge told me what I wanted to hear, and I nearly did.