Senior Product Manager

Compensation: ₹15L – ₹25L • No equity

This is two jobs sharing one skill set, and we’d rather say so in the first line than let you find out in month two.

Most weeks you’re the product manager on client work, where the product belongs to someone else, the roadmap is contested, and your authority comes from argument rather than from an org chart. The rest of the time you’re building our own products, where the decisions are ours to make and ours to get wrong.

We’re a design studio first. Research before assumptions, design before code, systems before scale — that’s how work actually runs here, not wall decoration. You’ll spend as much time in design critique as in a backlog, and a PM who treats design as a service function will struggle.

Some of what we build has AI in it and some doesn’t. Knowing which is which is part of the job rather than the whole of it.

What you’ll actually do

Own discovery — talk to users, synthesise what you heard, frame the actual problem. Before you have a roadmap, not after. Turn a client’s vague ambition into something scoped and sequenced a team can build. “We need to modernise onboarding” is the start of a conversation, not a brief. Write the PRD: what we’re building, for whom, why, what success looks like numerically, and what’s explicitly out of scope. Work with design as a partner rather than a supplier. You’ll be in critique, you’ll argue about flows, and you’ll sometimes lose that argument and ship the better thing for it. Break work into user stories with acceptance criteria an engineer can build against and a tester can verify. Run the delivery rhythm — backlog, sequencing, scope control, and the recurring conversation where a client adds something and you decide whether that’s a change request or a favour. Decide what doesn’t get built, including telling someone who’s paying us that their idea is wrong. Judge where AI genuinely belongs. A good share of what clients ask for is a pilot that demoed well and won’t survive production, and an equally good share shouldn’t involve a model at all. Own go-to-market for our own products — positioning, pricing, launch, the first hundred users. Hand over documentation the client’s own team can work from after we leave, because on most engagements we do leave.

What we need you to know

Concepts over tools, but these are requirements rather than preferences.

Product craft

Around eight years in product management or a closely related technical role, including at least three taking products from conception to launch. Discovery and research you run yourself, rather than commissioned and received as a deck Prioritisation you can defend — a real account of why this and not that, given a fixed budget and a fixed date. PRDs, user stories and acceptance criteria precise enough to build and test against.

Design partnership

Fluency in the design process — what research, wireframing, prototyping and critique each produce. Design systems as a product concern: components, consistency, and why a one-off screen is more expensive than it looks. Accessibility and inclusive design as build constraints, not polish.

Data and technical depth

SQL at working depth. You should be able to pull and check your own numbers rather than queueing behind an analyst. Metric definition and experiment design — sample size, what a confidence interval tells you, when a difference is noise. System and data architecture at a working level, and why an integration that looks trivial takes three weeks. Enough depth to challenge an engineer’s estimate credibly. You don’t need to write production code.

AI product judgement

Knowing when not to use a model. A rules engine often beats a weak model on cost, latency and explainability. Evaluation: what the eval set is, where labelled examples come from, what counts as a regression — decided before launch. What the system does when it’s wrong: confidence thresholds, fallbacks, when an automated step hands to a person.

Commercial

Scoping work that has to be profitable, and handling change requests without eroding the margin. Go-to-market: positioning, pricing, launch, and finding the first users for something nobody has heard of.

Good to have

Agency or consultancy product work — several products at once, for people who aren’t your colleagues. Having taken a services business toward a product, or been early on a product built inside one. A product you took from zero to one and then operated afterwards, rather than launched and handed off. Design background, or having worked closely enough with designers to be trusted in critique.

Who this is wrong for

If you want one product, one roadmap and a quarter to think, this is the wrong seat — you’ll carry several at once and the context switches weekly.

If your experience sits entirely inside a company with a research function, a design system someone else maintains and a data team on call, you’ll find much less around you here.

If you treat design as a service that produces screens from your requirements, you won’t enjoy working at a design studio and the designers won’t enjoy it either.