Technical Product Analyst

MerQube builds the infrastructure and tooling behind index calculation and administration for quantitative markets. We calculate and administer indices across equities, futures, and options, combining research, data engineering, and platform engineering to run calculations, produce client-facing analytics, and maintain auditable pipelines.

The Technical Product Management team sits between business stakeholders, quant research, and Platform Engineering. TPMs define what the platform needs to do and why. Platform Engineering owns how it gets built.

We are hiring a Technical Product Analyst into the Technical Product Management team in Bangalore. The role breaks into three parts of roughly equal weight: core technical product management activities, data analysis, and quality analysis.

You will write and contribute to PRDs, gather requirements from stakeholders, analyse vendor data to define business use cases, and validate that what Platform Engineering delivers genuinely meets the requirement before it reaches business stakeholders. It is a hands-on role with a clear route into a Technical Product Manager position.

The role is based in Bangalore alongside our Platform Engineering team, working hybrid and aligned closely to UK working hours to overlap with the London-based TPM team and business stakeholders.

• Write PRDs for defined product areas, with clear problem statements, functional requirements, and acceptance criteria against each requirement.
• Gather requirements from stakeholders across index production, the data office, quant research, and client-facing teams — turning a stated ask into a specified requirement.
• Own sub-tasks on strategic projects end to end, and contribute your progress and findings into project updates.
• Assess requirements against the Definition of Ready before they are handed to Platform Engineering.
• Help groom requirements: refining scope, sequencing, and dependencies alongside senior TPMs.
• Maintain requirement documentation in Notion so that decisions, open questions, and their owners stay traceable.

• Build a detailed understanding of vendor data: what each field actually contains, how coverage varies by asset class and market, and where vendors disagree with each other.
• Define business use cases from that understanding — translating what a vendor provides into what the business needs and how we get there.
• Compare data sources: run vendor-to-vendor comparisons, quantify discrepancies, and support decisions on source precedence, manual overrides, and instrument-specific rules.
• Produce data mapping analysis — documenting how vendor fields map to platform fields, where no clean mapping exists, and what derivation is required to close the gap.
• Contribute to data validation and tie-out work: reconciling platform output against vendor and independent sources, and investigating breaks through to root cause.

• Validate that delivered functionality and data meet the PRD and the stated requirements, from both a quality and a performance perspective.
• Design and execute test cases against acceptance criteria, and record evidence against the Definition of Done.
• Check requirement traceability: confirm that what was specified is what was built, and surface gaps before business stakeholders encounter them.
• Assess performance against expectation — run times, data delivery timing, and behaviour under realistic load.
• Log, track, and drive defects through to closure, with enough context for Platform Engineering to reproduce them without a second conversation.
• Hand over to business stakeholders once signed off: walking them through what was delivered, what has changed, and what to watch.

Platform Engineering owns design and implementation. This role does not design solutions.

What it does do is stay available and responsive throughout those stages — answering questions on intent, clarifying edge cases, resolving ambiguity in the requirement, and flagging when an implementation decision has drifted from what was asked for. Getting this relationship right is a large part of what makes the role effective: Platform Engineering should never be held up waiting on an answer about what a requirement meant.

• 2–4 years in a technical product, business analysis, data analysis, or quality analysis role — ideally within financial services or on a data-intensive platform.
• Strong SQL. This is a must-have: you will use it daily to investigate data, compare sources, and validate output.
• Proven data analysis capability on large, messy financial datasets — reconciling values across sources, isolating where and why they diverge, quantifying the impact, and reaching a defensible conclusion rather than a list of differences.
• Familiarity with equities, options, and futures: instrument mechanics, market conventions, and the data each of them requires. This domain understanding is critical to the role — you cannot judge whether index data is correct without it.
• Working knowledge of market data and vendor data — how it is sourced, delivered, and where it goes wrong. Exposure to providers such as Refinitiv, FactSet, Bloomberg, RIMES, or Markit.
• Demonstrated experience writing structured requirements — PRDs, functional specs, user stories, or equivalent — with acceptance criteria attached.
• Experience designing and executing test cases, and documenting results as evidence rather than as a status update.
• Able to communicate findings clearly to engineers and to non-technical business stakeholders, adjusting the register for each.
• Detail-oriented, with the confidence to say that something does not meet the requirement.

• Experience with data management platforms — enterprise data management systems or managed data services covering reference data, corporate actions, pricing, and symbology. Understanding how a golden-copy data model is constructed, governed, and validated across multiple vendors is directly relevant to what we are building, and would stand out.
• Experience using Claude, or comparable AI tooling, to accelerate analytical work such as mapping exercises, source comparison, and documentation. Our TPM team works this way daily, and someone who already does will be productive considerably faster. This one counts for a lot.
• Python for data analysis and scripting (pandas, notebooks, light automation).
• Exposure to corporate actions, reference data, index calculation, or benchmark administration.
• Familiarity with JIRA and Notion.
• Understanding of cloud data platforms, APIs, or pipeline architectures.

• Walk us through how you would establish whether two vendors’ versions of the same dataset actually agree.
• A requirement is ambiguous and the engineer has already started building. What do you do?
• How do you decide that a piece of work is ready to hand over to business stakeholders?
• Testing shows the delivered output does not match the PRD, and the deadline is tomorrow. How do you handle it?
• How would you write acceptance criteria for a requirement you do not yet fully understand?
• What is the difference between what a stakeholder asks for and what they need — and how do you find out?