OptiSol Business Solutions & O2V Private Limited Looking for AI Product Manager

AI Product Manager: Supply Chain & Procurement · Chennai (Hybrid) · 5–8 years

Role: AI Product Manager — Supply Chain & Procurement

Product: elsai (elsai.ai) — OptiSol’s enterprise AI agent platform

Experience: 5–8 years, with at least 3 in product management for a B2B software product

Location: Chennai — hybrid, 3 days a week in office

Reports to: CEO, OptiSol

Travel: Customer sites across India; occasional overlap hours for international accounts

About elsai elsai is OptiSol’s enterprise AI agent platform. It sits on top of the systems an enterprise already runs — it does not replace them — and gives business teams agents that execute real work under governance: human-in-the-loop gates bound to the stage of the workflow, evidence and a confidence score behind every recommendation, override-with-reason recorded, and a full audit trail of what the agent did and what the human changed. It runs in our cloud, in a customer VPC, or on-premise with open-weight models when data cannot leave.

We are building depth in two verticals: Healthcare, and Supply Chain & Procurement. This role owns the second one.

Why this role exists

Over the past year we have run more than a dozen enterprise procurement engagements across manufacturing, metals, EPC, aerospace and process industries. The positioning lands. The proof is what is missing.

Procurement heads keep asking the same things — configure our approval matrix and delegation of power, track what happens after the award, connect to the ERP we already run, show me what the agent did versus what my team did — and we keep answering them one deal at a time instead of once, in the product. The other objection we hear, in almost the same words each time, is that the product is too heavy and shows too much. That is not a polish problem either.

We need one person who sits with those customers, hears the same requirement for the third time, and turns it into a platform capability instead of another custom configuration. That person writes the spec, defends the cut, and stands in front of the customer when it ships. That is this job.

This is a build-and-sell-and-build role. Roughly half your week is customer-facing: discovery, demos, debriefs, replaying real procurement cycles through the product. The other half is product work: briefs, acceptance criteria, prioritisation, sitting with engineering. If you want only one of those halves, this is not the role.

What you will own

1. Customer connect — be in the room, not downstream of it

- Run discovery and demo sessions with Heads of Procurement, Supply Chain and Materials directly. You should be able to hold that room without a sales engineer beside you.
- Write the note from every session against one fixed theme taxonomy, so that fifteen conversations produce a count, not fifteen anecdotes.
- Own the customer-voice loop end to end for this vertical: listen, count how many accounts asked for a thing, decide what that means for the roadmap, ship it, and go back and tell them.
- Keep the record straight. Every engagement gets a CRM entry with the real stage. Without a denominator we cannot tell nine accounts from one loud one.
- Run a structured win/loss review after every demo cycle, and be willing to write the qualification finding nobody wants to hear — including “this customer’s process is not broken enough to buy.”

2. The supply-chain agent portfolio

- Own the roadmap for our procurement agents — supplier risk, contract and obligation management, tender and bid evaluation, BOM and specification handling, document drafting — from brief through prototype to a shipped, priced product.
- Mark every agent honestly as live, in build, or roadmap. We do not demo designs as delivered.
- Design for composition, not a flat catalogue. Where one agent consumes another’s output, that dependency is our best proof the platform is real — make it visible.
- Push generalisable requirements into the platform and keep customer-specific logic out of the core. The third time we hand-build the same configuration, it becomes a feature.

3. Product UX — make the agent usable by the person who actually does the job Our most repeated objection is not accuracy. It is that there is too much on the screen. A buyer raising an indent, an approver clearing a value band on a phone between meetings, and a supplier who touches our system once a quarter are three different users with three different tolerances — and today they largely get the same dense interface.



Simplifying that is a product decision and it is owned in this role. It is not a visual clean-up handed to design at the end.

- Define the interaction model role by role — buyer and category manager, approver in the delegation-of-power chain, materials and planning, contract owner, finance, and the external supplier — and cut each default surface to what that person needs in order to act. Where a simpler industry needs a third of the complexity of the heaviest one, that is an architecture decision made once, by policy, not renegotiated in every deal.
- Minimise what a human has to type, above all on the supplier side. An external supplier has no reason to learn our system, and every field we add is a reason not to respond.
- Design the approval experience for how approvals actually happen — in a queue, often on a phone, between other things — with the recommendation, the evidence behind it and the override path visible in a single glance.
- Make the agent’s reasoning legible, not merely present. Wherever we show a confidence score, a risk number or a ranking, the user must be able to see how it was arrived at without asking us. “How is that calculated?” is a question we get in the room and cannot yet answer inside the product.
- Design the unhappy path with as much care as the happy one: what a person sees when the agent is unsure, what they see when they disagree, how they say so, and what the system does with that disagreement afterwards.
- Write the flows, sit in usability sessions with real procurement users, and defend the cut when a stakeholder asks to put one more field back on the screen. You will be paired with a designer and will not be doing the craft work alone — but the interaction model is yours, and you are accountable for it.

4. Prototype with AI tools — argue with something a customer can click We expect this role to use AI tools to think. A rough, clickable prototype of a screen or a flow, produced in an afternoon, settles an argument that three rounds of written debate will not — and put in front of a procurement head on the second call, it turns a vague discussion into specific feedback. The standard we care about is speed to a testable idea, not craft; the designer takes it from there.

- Use AI prototyping and generation tools fluently to produce clickable mockups, concept screens and pitch visuals — whichever tools you prefer, and whatever replaces them next year. We care that you reach for them by reflex, not which logo is on them.
- Take a prototype into a customer conversation rather than a slide, and treat what happens in that conversation as the real requirement-gathering.
- Use the same tools to pitch internally: make the idea visible to engineering, design and leadership before anyone commits a sprint to it.
- Know what a prototype is not. It is a question you are asking, not a specification and not a commitment — so it never becomes the demo, and it never goes to a customer labelled as something we have built.

5. Translate procurement reality into platform requirements

- Approval chains, delegation-of-power matrices, value bands, payment-term variants and mid-cycle changes — turn these into configuration a customer administrator can change without a release, not into hard-coded logic.
- Post-award tracking, SLAs, escalation and delay attribution: who caused the delay — the agent, the internal team, or the counterparty. Specify the primitive, not a one-off report.
- Specify the business rules as declarative, versioned, testable policy, so an auditor can see the rule, its version, and every run it fired on.
- Own the integration requirement: define and drive one live ERP round trip as a reference customers can verify, and specify connector health as a product surface rather than a support conversation.

6. Evidence, pricing and packaging

- Define the efficiency benchmark a buyer will accept — cost, cycle time and effort against the customer’s own baseline — and make sure the number we publish is the same number everywhere.
- Contribute to packaging: a module list a buyer can price, and a first engagement small enough to say yes to.
- Gate releases against a simple test:



can a customer verify this claim without us in the room? If not, it is not

What we are looking for

Must have

- 5–8 years of experience, with at least 3 years as a product manager on a B2B enterprise software or SaaS product that real customers paid for.
- Genuine domain fluency in procurement or supply chain: source-to-contract and procure-to-pay, RFQ and tender cycles, vendor onboarding and risk, approval matrices and delegation of power, contracts and obligations, PO/GRN/invoice matching. You have either built for this domain or worked inside it.
- Hands-on product experience with AI/ML or LLM-based features shipped to production — agents, retrieval, evaluation, human-in-the-loop design, confidence and hallucination controls, prompt and version management. Practitioner understanding, not vocabulary.
- Working knowledge of enterprise ERP landscapes (SAP, Oracle, Ariba, Coupa or equivalent) and what integrating with them actually costs.
- A record of simplifying enterprise software rather than only adding to it. Point us at a workflow you cut down — fewer screens, fewer fields, fewer decisions demanded of the user — and tell us what you removed, what it cost, and how you knew. Wireframe-level fluency and the confidence to run a usability session yourself. You will be paired with a designer, so we are not asking you to be one.
- Fluency with AI tools as part of how you work — prototyping and generation tools to get to a clickable screen or a concept pitch in hours rather than a sprint. Bring an example to the interview. We do not mind which tools; we do mind whether reaching for them is a habit.
- Strong customer-facing presence: you can run discovery with a senior procurement leader, take an objection live, and come back with a written point of view.
- You write clearly and often. Briefs, acceptance criteria and meeting notes are the artefacts of this job, and vague ones cost us weeks.
- Comfort with ambiguity and with saying no. Much of this role is deciding what we will not build.

Good to have

- Time spent inside manufacturing, EPC, metals, energy or aerospace — or consulting into them.
- Experience with on-premise or VPC enterprise deployments, data residency requirements and enterprise security reviews.
- Exposure to open-weight models, model routing, and the accuracy/latency/cost trade-offs between them.
- Prior work on workflow, approval or rules-configuration engines.
- Experience designing for infrequent, non-technical, external users — supplier portals, vendor onboarding, self-service — where there is one attempt and no training.
- Experience designing AI or recommendation interfaces where trust, explanation and override are the design problem rather than a footnote.
- Experience selling or supporting a platform to both business buyers and enterprise IT — they are different audiences and need different arguments.

Who this role is not for

- Someone who wants to administer a backlog that other people fill.
- Someone who wants to be a full-time presenter, or a full time writer of specs, but not both.
- Someone who treats user experience as design’s problem and product’s afterthought.
- Someone who needs a mature product, a settled roadmap and a research team upstream. None of those exist yet — building them is the job.

How we will interview

- Introductory conversation on your background and why this problem interests you. (30 min)
- Domain and product discussion: walk us through a procurement or supply-chain workflow you know well, and where an agent should and should not sit in it. (60 min)
- Take-home exercise: a short product brief for one capability, from a real anonymised customer requirement we will share — plus a rough prototype or concept screen of how the person who has to use it experiences it. Use any AI tool you like; we expect you to. We read for judgement, clarity and how fast you got to something we could react to — not for polish or length.
- Customer simulation: run a discovery conversation with one of us playing a Head of Procurement. (45 min)
- Closing conversation with leadership on ways of working, ownership and compensation.

What we offer

- Direct ownership of a vertical at the point where it converts from demos to revenue, reporting to the CEO, with direct access to customers and to every decision that affects the product.
- A platform and an engineering team already in production, so your specs ship rather than queue — and a designer paired with you on the experience.
- Hybrid working from Chennai, three days a week in office.

📌 AI Product Manager (Chennai)
🏢 Optisol Business Solutions
📍 Chennai