01
Product Requirements Documents (PRDs)
Full-scope feature and product PRDs covering user stories, acceptance criteria, edge cases, and technical dependencies. Built for engineering teams to execute without ambiguity.
product management
Product Management shaped
how I build systems.
Before AI Authority and Conviction OS became public products, Subham worked across product documentation, APIs, stakeholder alignment, workflows, compliance-heavy systems, and technical product delivery.
PM identity
What kind of PM.
Subham is a technical product manager someone who can read and write an API spec, understand system architecture, coordinate engineering delivery, and still translate all of it into a business document a non-technical stakeholder can act on.
That dual fluency technical depth and business communication is the product. It is not common. Most people are one or the other. The ability to sit in a room full of engineers and then go write a stakeholder proposal is a specific skill that comes from both ends: years of engineering execution and years of product ownership.
Technical Product Manager
Business Analyst → APM → TPM arc
BFSI / AML / RegTech
GenAI systems
API coordination
Stakeholder management
the arc
BA → APM → Technical PM.
The path was not linear. It started in execution building, debugging, integrating. Then moved into documentation and analysis: writing specifications that engineering teams could build from, writing reports that leadership teams could decide from.
The associate PM and then technical PM roles came with real ownership: roadmaps that needed to ship, features that needed scoping, systems that needed governing. The BFSI and compliance exposure particularly AML and RegTech added precision to the thinking. In regulated domains, ambiguity is a risk. You learn to be specific.
GenAI came next not as a trend to follow, but as a domain to engineer for. That meant understanding what LLMs can and cannot do in production, how to build guardrails, and how to document AI-assisted systems so compliance and stakeholders can trust them.
what he actually did
Deliverables, not job titles.
02
Functional Specification Documents (FSDs)
Low-level design documents for compliance-critical systems AML platforms, RegTech workflows, and GenAI deployment specifications. Precision was non-negotiable.
03
API Coordination
Integration scoping, API contract definition, and coordination between engineering, vendors, and internal product teams. Including GenAI API integration planning and prompt architecture documentation.
04
UAT Management
User acceptance testing planning, test case definition, bug triage, and sign-off coordination. Bridging QA, engineering, and business stakeholders across delivery cycles.
05
Stakeholder Management
Communication across engineering, compliance, business, and leadership layers. Translating technical tradeoffs into business language and business requirements into technical scope.
06
Product Architecture
System architecture thinking applied to product scoping understanding how features connect at a systems level, not just in isolation. This is what makes roadmaps survivable.
industries & domains
Where the product work ran.
BFSI
Banking, financial services, and insurance where systems must be accurate, auditable, and defensible. No room for vague specifications.
AML / RegTech
Anti-money laundering system documentation. Writing specifications for compliance systems that flag and investigate suspicious financial activity.
GenAI / Enterprise AI
Product specification and deployment documentation for GenAI platforms including AI-assisted workflows, LLM integration, and guardrail architecture.
the connection
What PM taught him about AI systems and authority.
Product Management teaches a specific lesson: good systems need documentation, governance, and review cycles. Without those three things, even the best intentions produce inconsistent output.
That same principle runs through Conviction OS. The governance-first structure is not corporate bureaucracy it is what makes authority systems trustworthy and repeatable. Ground truth. Generation. Review. Distribution. Feedback. That loop is a PM's playbook applied to content and authority infrastructure.
AI Authority Protocol is equally PM-influenced. Before you can make an entity readable by AI systems, you need to define what the entity is, what it does, what it claims, and what proof exists. That is requirements documentation applied to identity architecture.