Chintan Shingala

I build the thing,
to decide the thing.

Hi, I'm Chintan. I'm a product manager with eight years' experience across embedded finance, pensions data, and now private markets, where I lead two product squads and report directly to the CEO. I build products in a way that has only recently become possible: prototype early, put working artefacts in front of clients, and let evidence decide what gets built.

This site aims to show how that looks in practice: four pieces of work from throughout my career told through the decisions that shaped them, and five product beliefs formed along the way.

Chintan Shingala
fig. 00 — london, most days
before this: pensions data → embedded finance → risk software.
always B2B. always somewhere between the business and the build.
Currently
PM, private markets fintech — two squads
Looking at
Senior PM roles, fintech & AI
Based
London
Contact
01 / SELECTED WORK

Four pieces of work I keep coming back to — not because they shipped smoothly (they didn't), but because each one turned on a decision that could have gone the other way. That's the part worth showing, so that's what each case study walks through. One note: the visuals throughout are redrawn concept illustrations — the real client work stays confidential, as it should.

CO-INVEST

From a single-client service to a product four GPs are trialling on live deals.

what this one shows
holding the tension between serving a design partner and building something the market will actually buy.
PRE-TRADE

The brief asked for a data room. The answer turned out to be a product line.

what this one shows
reframing the opportunity, not just the solution.
CLEARGLASS

The operational bottleneck that became a revenue line.

what this one shows
seeing the product hiding inside an operational problem.
SALARY FINANCE

The integration that made employment data live.

what this one shows
working at engineering depth — designing the flow, not just writing the spec.
02 / HOW I THINK ABOUT BUILDING

Opinions I hold about the work — formed by doing it, and still being revised by it.

The cost of being wrong has collapsed.

It isn't that prototyping got faster, though it did. It's that finding out you were wrong got cheap — an afternoon's work, not a quarter's. That quietly rewrites the economics of every product decision: ideas we'd once have killed on paper are now worth exploring, and answers can change mid-flight, because being wrong on Tuesday means being right by Wednesday. Most teams have updated their tools. Fewer have updated their appetite.

b.01

A persuasive prototype is a double-edged thing.

The same concreteness that gets everyone aligned also ends the conversation early — a good prototype quietly forecloses the five solutions nobody got the chance to propose. Alignment and premature lock-in are one mechanism seen from two sides, and knowing which one you're getting in the room is the actual job. The counterweight is breadth: a prototype in one room aligns a client; the same prototype in ten rooms reveals a market.

b.02

A prototype shows what could be built. Never what should.

Prioritisation stays a human act, no matter how good the artefact is. The most dangerous moment in prototype-driven work is mistaking momentum for a decision.

b.03

Roles don't disappear. They relocate.

When product produces the first concrete artefact, design's job isn't to rubber-stamp it — it's to raise the ceiling. Engineering's job isn't to recreate it — it's to test it against the constraints the prototype was free to ignore. The half-life of any way of working is short, and getting comfortable re-learning the process is the durable skill. What's permanent was never the workflow. It's judgment.

b.04

Trust is architecture.

In markets where the users manage other people's billions, safety isn't a compliance afterthought — it's a first-class product decision, made at design time. Authentication before access, entitlements before answers, audit by construction. The products I'm proudest of led their pitch with the guardrails, and won because of it, not despite it.

b.05