Oracle · Oracle · conventional enterprise Product Management
Building a 0→1 enterprise workflow Product: policy, evidence, exceptions, and decisions
Creating Supplier Qualification from scratch meant defining a configurable enterprise workflow across policy, evidence, evaluation, approvals, exceptions, decisions, and lifecycle state.
Approximately 6.5 years in Product Management
90-second case
- Problem
- Supplier qualification had to support different evidence, policies, categories, business contexts, evaluators, approvals, exceptions, and reassessment needs.
- Mandate
- Create a new Supplier Qualification Product from scratch inside Oracle Procurement after earlier Product Management work in Middleware, Self-Service Procurement, and Sourcing.
- Decision
- Model the qualification decision and its lifecycle rather than reduce the Product to a static questionnaire.
- What happened
- The 0→1 assignment became Fusion Supplier Qualification, and the Product category continues in Oracle Procurement today.
- Why it matters now
- It is the conventional enterprise Product foundation beneath the later Experience, transformation, and AI Product story.
My role
How I contributed.
I created the Supplier Qualification Product from scratch after earlier Product Management work across Middleware, Self-Service Procurement, and Sourcing.
I partnered with Engineering, Design, QA, documentation, release, platform, and customer-facing teams to translate the domain into a coherent enterprise capability.
Current reconstruction
The core mechanism.
A present-day visual of the system described in the case.
Judgment under constraint
Decisions that shaped the work.
Decision
Design around the qualification decision and its lifecycle—not the questionnaire alone.
- Why it was hard
- Questionnaires are concrete, but enterprise qualification also involves customer-specific criteria, requested evidence, evaluators, approvals, exceptions, validity, history, and reassessment.
- My judgment
- Model the durable Product objects and states, then make the right policy variation configurable rather than treating configuration as an escape from Product judgment.
- Consequence
- The work established the foundation for a new Supplier Qualification Product within Oracle Procurement.
Historical enterprise Product
The assignment began with a new Product definition, not a feature extension.
Oracle was Jessie's first full-time job. She worked in Product Management for approximately six and a half years, beginning in Middleware for about a year before moving into Procurement, first in Self-Service Procurement and then Sourcing. The culminating assignment was to create a new Supplier Qualification Product from scratch.
The work combined sustained enterprise domain depth with a greenfield Product assignment that became Fusion Supplier Qualification.
Current reconstruction · Product reasoning
Qualification is a changing decision with evidence and history.
A useful Supplier Qualification Product has to connect supplier and business context, requested evidence, customer-configured criteria, evaluator roles, approvals, exceptions, a decision record, and the conditions that reopen the decision.
This present-day reconstruction shows the Product reasoning behind the qualification lifecycle.
- 01Supplier + business context
Category · initiative · risk · relationship
- 02Questions + evidence
Requested proof · responses · documents
- 03Configured criteria
Customer policy · thresholds · rules
- 04Evaluation
Roles · review · approval · exception
- 05Qualification record
Decision · rationale · status · history
- 06Lifecycle trigger
Change · expiry · exception · reassessment
Product leadership
Enterprise Product judgment lives in the trade-off between a coherent platform and legitimate customer variation.
Too little flexibility would make the capability irrelevant across customer policies. Too much would make behavior unpredictable, difficult to test, and costly to maintain. The Product job was to decide which logic should remain stable and where configuration represented real domain variation.
Product Management also had to translate that logic into testable requirements and work with Engineering, Design, QA, documentation, release, and customer-facing stakeholders.
Reflection
Find the decision beneath the interface.
This work established a Product habit I carried into later Experience and transformation roles: identify the durable decision, actors, evidence, state, exceptions, and lifecycle before allowing the interface to define the Product.
Oracle does not need an AI retrospective to be strategically relevant. It establishes the enterprise Product discipline underneath everything that came later.