Defining the Future of Supplier Management
From platform replacement to supplier experience strategy
Product Design Lead
8-month initiative with Kroger Technology & Digital
Supplier Hub continues to meet core functional needs for downstream systems and sourcing data, but research revealed opportunities to improve the experience, reduce manual processes, and ensure data remains fresh throughout the supplier lifecycle.
As design lead, I helped define the vision for a next-generation supplier master data solution- exploring how to replace aging infrastructure, address fragmented processes, and better support sourcing, compliance, and supplier management while preserving critical operational integrations.
The current supplier management platform had become increasingly difficult to maintain due to legacy infrastructure, extensive customization, and limited scalability.
While it supported supplier profile data, compliance workflows, and onboarding across multiple internal teams, the platform no longer aligned cleanly with current business and user needs.
The organization was beginning to explore alternative SaaS solutions—but before evaluating vendors, the team needed to establish a clear baseline of what the business and its users actually needed.
Extensive customization created challenges around scalability, supportability, and long-term flexibility.
Different teams—including sourcing, compliance, supplier management, and onboarding—had different requirements for supplier profile management.
The organization didn't yet have a clear picture of which supplier data was essential, optional, unnecessary, or missing.
Before evaluating alternative solutions, the team needed evidence-based requirements and evaluation criteria to understand what a future platform would need to deliver.
I served as the design lead for discovery, responsible for helping the team understand the current experience, define user and business requirements, and create a research-backed foundation for evaluating future solutions.
My focus was not to design the replacement. It was to help the organization understand what the replacement needed to be.
We needed to learn
People
Users
Work
Workflows & use cases
Data
Required and future-state
Systems
Dependencies
Evaluation
To understand the needs of both internal teams and external suppliers, I led a mixed-method discovery effort combining qualitative research, quantitative surveys, and data requirement analysis.
40
External Supplier Participants
30+
Internal Business Users
6
Business Functions Represented
Sourcing · Finance · Operations · Marketing · Compliance · Supplier Management
Research Activities
Stakeholder Interviews • User Interviews
Internal Surveys • External Surveys
Jobs-to-be-Done Analysis
Data Requirement Analysis • Opportunity Mapping
We started with a data problem.
Early assumptions suggested that the future solution needed to address gaps in the supplier data being collected.
Research revealed a bigger problem.
The biggest problem wasn't the data itself.
It was keeping supplier information
accurate, current, and accessible
through the workflows where people needed it.
Users didn't describe supplier information as something captured once during onboarding. They described it as information that continuously changes throughout the supplier relationship.
Internal and external users encountered disconnected tools, duplicate data entry, unclear ownership, and manual workarounds.
The value of supplier data depended on whether users could find and act on the right information at the right point in their workflow.
Supplier management wasn't a one-time setup task. It was an ongoing relationship.
Many existing processes treated supplier setup as a discrete event. Research showed that supplier information continued to evolve throughout the relationship, creating a need for ongoing maintenance, visibility, and support.
Different users, same underlying need
External suppliers
Complete onboarding
Maintain organizational information
Submit compliance documentation
Resolve operational issues
Access performance/reporting information
Pain Points
Multiple systems · Limited visibility · Manual processes · Unclear escalation · Redundant work
Internal teams
Onboard suppliers
Maintain accurate information
Verify compliance
Resolve operational issues
Access supplier information & monitor performance
Coordinate across departments
Pain Points
Data quality · Manual work · Fragmentation · Conflicting information · Limited automation/visibility
Shared underlying job
Maintain a healthy supplier relationship with reliable information available when needed.
One of the most valuable outcomes of discovery was distinguishing between information that should remain relatively stable and information that changes as part of day-to-day operations.
This distinction gave the team a clearer way to think about future platform capabilities, ownership, and the boundaries of the supplier master data solution.
Where could we make the biggest difference?
Make supplier information easier to maintain over time.
Improve visibility into contacts, relationships, and organizational structures.
Create clearer workflows for managing requirements and compliance information.
Reduce friction through more centralized and transparent support pathways.
Improve visibility into supplier information and business performance.
Discovery changed the question.
From
which features should we build?
to
which capabilities and experiences are necessary to support the supplier lifecycle?
This reframing set the stage for the next phase: turning a complex ecosystem into a shared model of the future solution.
Discovery gave us a clearer picture of the supplier ecosystem—but it also surfaced a deeper problem.
Stakeholders could describe their workflows and needs, but they didn't yet share an understanding of what the future system should actually manage, where its boundaries should sit, or how the pieces of the ecosystem related to one another.
Before we could define requirements, we needed to define the system itself.
Was the future solution a supplier master data platform, profile management tool, contact management system, compliance platform, supplier support experience—or some combination?
Stakeholders could describe workflows, but struggled to determine which data belonged where, which system should own it, and which capabilities belonged together.
"Supplier," "vendor," "organization," "facility," "location," and "contact" were sometimes used interchangeably, creating hidden assumptions in requirements conversations.
The team needed to distinguish vendor-owned, internally maintained, third-party, and downstream operational data—and determine what actually belonged in the future solution.
These weren't interface questions. They were domain-model questions.
Requirements gathering wasn't resolving the ambiguity.
We already had user research, stakeholder interviews, Jobs-to-be-Done, use cases, and process maps. Yet stakeholders were still debating fundamental questions about the future solution:
What exactly are we managing?
Which concepts should be first-class objects?
Which information belongs in the future system?
Who owns each piece of data?
How do the different entities and workflows relate?
Rather than asking stakeholders to generate another list of features, I reframed the conversation around the underlying business model: what entities exist, how they relate to one another, and where they belong within the broader supplier ecosystem.
OOUX gave us a framework for making those assumptions explicit and discussing them systematically.
I translated research into a shared model.
I synthesized stakeholder research, Jobs-to-be-Done, use cases, known system dependencies, and data requirements into a set of concrete business objects and relationships. I then facilitated working sessions that challenged assumptions, clarified boundaries, and helped stakeholders determine what was foundational to the future solution.
Connected research findings, jobs, use cases, data, and system dependencies.
Surfaced assumptions and asked whether something was actually an object, an attribute, or even part of the future system.
Helped stakeholders distinguish critical, must-have, nice-to-have, and out-of-scope capabilities.
Created a shared model that connected business needs with technical thinking.
The workshop turned a collection of questions into a model the team could reason about
Before
"Should contact management be part of profile management?"
"Is industry an object or an attribute?"
"Does facility compliance belong here?"
"Who owns this data?"
After
Core
Supplier master data · Profile management · Identity & organization records · Critical compliance data
Adjacent
Relationship management · Contact management · Support experiences
Potentially outside the boundary
Operational purchasing processes · Certain downstream workflows · Data maintained elsewhere
Rather than treating requirements as disconnected feature requests, the team could now trace them back to the jobs and use cases they supported—and to the underlying objects, attributes, and relationships that made those experiences possible.
The result wasn't just a list of requirements. The result was a traceable path from user need to system structure to product requirement.
We had defined the problem. Now we needed to understand the solution landscape.
Following discovery research and domain modeling, the team reached a critical decision point. Leadership needed to determine whether to continue investing in the existing supplier management ecosystem, modernize portions of it, or pursue a new platform altogether. With upcoming budget planning requiring a clearer understanding of the market, potential solution approaches, implementation risks, and investment required, the team initiated a structured RFI process.
Before shaping the RFI, I conducted Gartner and broader market/vendor research to understand how the supplier management landscape was evolving, what solution categories existed, and where commercial platforms appeared strongest or weakest against the needs identified during discovery.
We knew
Where users struggled
Where processes were fragmented
Where data ownership was unclear
What the supplier lifecycle required
We didn't know
Could commercial platforms address those needs?
Which capabilities were truly foundational?
What implementation risks would we inherit?
How did vendors model the supplier lifecycle?
Which strategic path represented the best investment?
With the core user needs, use cases, and domain model established, I worked with product, technology, and sourcing partners to translate discovery findings into a structured approach for evaluating potential solutions.
Rather than evaluating vendors against a disconnected list of feature requests, we developed questions grounded in the problems and requirements uncovered during discovery. This allowed the team to assess how different solutions approached the underlying needs, where they aligned with the future-state vision, and where significant gaps or implementation considerations remained.
What we already knew
User needs • JTBD • Use cases • Domain model • Data Requirements
A research-backed evaluation criteria
Enabled
Compare solution approaches • Identify gaps • Surface risks • Align stakeholders
We evaluated the model—not just the features.
Previous discovery had revealed fundamental disagreements around supplier data ownership, lifecycle boundaries, master versus operational data, governance responsibilities, and system relationships. A conventional feature-based RFI could easily reproduce those ambiguities.Instead, I helped shape questions around the underlying business model: how vendors represented supplier entities and relationships, how ownership and governance worked, how lifecycle changes were managed, and how the solution connected to the broader supplier ecosystem.
Path
What it could solve
Key tradeoff
Maintain
Lowest immediate disruption
Doesn't address structural problems
Modernize
Targeted improvement
Continued legacy constraints
Replace
Modern platform foundation
Migration + implementation risk
Orchestrate
Connect fragmented systems
Added architectural complexity
Broader supplier experience
Addresses lifecycle holistically
Larger organizational investment
I helped facilitate the conversations that allowed stakeholders to compare these options against user needs, data governance, technical complexity, organizational readiness, cost, and long-term strategic value.
From feature requests → business capabilities
The RFI gave stakeholders a shared vocabulary for evaluating what actually mattered.
From vendor comparison → strategic evaluation
The team could assess not only whether vendors offered functionality, but how their approaches aligned with the organization's data model, lifecycle, governance, and experience needs.
From replacement mindset → ecosystem strategy
The evaluation process moved the conversation beyond simply replacing Supplier Hub. Stakeholders began considering a broader future-state supplier experience centered on unified supplier interactions, lifecycle management, centralized governance, visibility, and integration across the ecosystem.
We started by asking which system to replace. We ended by asking what experience we wanted to create.
The original goal of the initiative was to evaluate options for replacing a legacy supplier management platform. Through discovery research, domain modeling, and vendor evaluation, we developed a broader understanding of the underlying problem: the platform itself wasn't the primary issue.The larger challenge was a fragmented supplier experience spanning multiple systems, teams, and processes. Research consistently showed that both suppliers and internal teams struggled with disconnected workflows, unclear ownership, duplicated effort, and limited visibility across the supplier lifecycle.As a result, stakeholders recognized that replacing a single system would address only part of the problem.
To support funding discussions and future planning, I helped translate research findings, OOUX outputs, and vendor learnings into a future-state experience strategy. Working closely with product leadership, I contributed to the vision, storytelling, and artifacts used to communicate the business case for a more unified supplier experience.
Unified supplier entry experience
Orchestrate across existing systems
Create a cohesive supplier journey
Modernize the ecosystem over time
Visibility · Support · Lifecycle management · Long-term modernization
From
Which system should we replace?
to
What experience are we trying to create?
The proposed strategy shifted the focus from replacing individual systems to creating a more cohesive supplier experience across the ecosystem—allowing modernization to happen incrementally rather than requiring every underlying system to be replaced at once.
Stakeholders aligned around a broader supplier experience strategy rather than a direct platform replacement. The resulting direction established a multi-year vision centered on a unified supplier experience, phased modernization, and improved visibility across the supplier lifecycle.While competing organizational priorities ultimately prevented the broader investment from progressing to the next stage, the work changed the conversation from "which system should we replace?" to "what experience are we trying to create?"The strategy provided a shared foundation for future investment decisions and gave stakeholders a clearer path for modernizing the supplier ecosystem over time.
This project expanded my understanding of what product design can contribute in complex enterprise environments. I entered the initiative focused on replacing a legacy platform; I left having helped shape a broader product strategy spanning research, domain modeling, vendor evaluation, stakeholder alignment, and investment planning.The biggest lesson was that the most valuable design outcome isn't always a new interface.
Sometimes it's helping an organization see the problem differently—and giving people a shared framework for deciding what to do next.
