Build v. Buy Discovery
Replacing software that intakes 28B worth of product, yearly
Overview
My focus for this project was to make a recommendation for replacing a piece of 35+-year-old software called ChainTrack. ChainTrack is used across the enterprise for receiving certain types of products through the docks at Kroger stores, a process called Direct Store Delivery, or DSD, where products like Coke, Fritos, and alcohol come into the store. Kroger DSD intakes ~28 billion dollars of products using this software.
“We've never seen a proposal this thoroughly researched.”Panel of Kroger VPs
This was a three-person team: a Product Manager, a Tech Lead, and myself, tasked with researching and understanding enough to recommend building our own or purchasing a replacement product. I drove the research and recommendation work.
Role
Product Designer
Scope
Eight weeks (team of three, made up of a Product Manager, a Tech Lead, and myself)
Tools
Axure, Sketch, Documentation
Approach
Problem Statement
The problem I needed to solve was how to replace an antiquated piece of technology with something more robust. One business requirement was that the replacement product must work on TC-52 Zebra devices so Kroger maintains a single device type across all stores.
The next iteration of this product must:
- Make data more accessible
- Reduce printing and invoice storage costs
- Support DSD Receivers to intake products at a lower cost
Goals
- To understand and document the existing DSD Receiving process and use of the ChainTrack product
- Run observations and workshops with my team, stakeholders, and software vendors to collect information
- To conceptualize what would be needed in a replacement product
- Evaluate competitor products that could function as a replacement
- Create and visualize concepts like feature timelines, product flows, existing state click-through prototypes, and other deliverables to share with others and support a build or buy decision
- Support change management
Process
With no prior experience in product receiving or the DSD process, I had to build that ground-level understanding myself before I could design anything: researching the DSD process, surveying users, trainers, and managers for their needs and pain points, then leading the team through in-store observations of DSD Receivers working directly with ChainTrack.
I turned that research into two product flows: one mapping how DSD Receivers actually worked within ChainTrack today, and a second mapping what an in-house replacement would need to do instead. The second flow wasn't just about scoping a possible build, it set the criteria I used to judge off-the-shelf alternatives against.
From there, I took the recommended vendor's product from sketches through wireframes to an InVision click-through prototype myself, since the team didn't have hands-on access to the real thing yet, then mocked up the specific updates that product would need to fit Kroger's workflow, giving stakeholders something concrete to react to instead of a hypothetical.
- User Observations
- Product Flows
- Sketches
- Wireframes
- Prototypes
- Usability Testing
Findings
Turning everything we'd learned into an actual recommendation meant knowing what mattered most, so I ran a workshop with my team to vet the order of priority for the business and user requirements behind a build or buy decision. That produced a product timeline, broken into four priority tiers: MVP, Secondary, Third, and Fourth, and a vendor report card scoring each option as can-do-out-of-the-box, cannot-do, or needs-to-be-built, with parity to ChainTrack, user experience improvements, and unmet business goals as the top priorities. I used that report card directly in vendor meetings to assess their software against Kroger's requirements, and the scoring surfaced real tradeoffs: going fully paperless would have been a major cost saving, but state-to-state alcohol retention laws made it more complicated than a simple digitization effort, and a fully-branded, "skinned" interface got pushed down my own priority list, since matching Kroger's visual brand wouldn't have made the product more usable.
I built four personas from that research: DSD Receiver, Grocery Manager, Admin, and Systems Operations. Systems Operations' own pain points summed up the core problem: ChainTrack was antiquated, difficult to modify, and needed the vendor on-site just to test a fix.
We also ran usability testing in a secure environment inside a Kroger store with real DSD Receivers, timing how long intake took on ChainTrack against the recommended replacement product head-to-head.
Solution
Not only was there a clear path on which company to move forward with, but the software provider we recommended also expressed interest in meeting many of our requirements, asked for clarity on others, and offered to build the solutions we needed throughout our partnership.
It was obvious to the team and me that there was no clear differentiator in building our own solution. Additionally, over at least five years, partnering with the vendor would be less expensive and more rewarding for Kroger and the users than if we were to build the product ourselves.
Once the recommendation was approved, I stayed engaged directly with the vendor, mapping our requirements against their existing product and calling out the gaps a Kroger implementation would need filled. That included working through detailed requirements together and aligning on a shared path forward, so the partnership started from a specific, agreed-upon plan instead of a general intent to work together.
Impact
Results
I supported the creation of my team's presentation deck: six slides to present, backed by an appendix of more than 250 slides of my research. We presented our findings to a panel of Kroger VPs, who approved our buy recommendation before we'd even finished presenting it, telling us: "We've never seen a proposal this thoroughly researched."
Achievements
- My work for this project provided a wealth of research that supported our recommendation to buy a third-party replacement
- I advocated for the UX process throughout the project, including a training presentation to Kroger's own Product Design group on the flow-mapping and prototyping approach used here, a method many of them hadn't encountered before
- I facilitated workshops with my team and cross-teams to capture information and align our understanding
- Turned the approved recommendation into an actionable plan by mapping requirements directly with the vendor and closing the gaps a Kroger implementation would need filled
Takeaways
What would I do differently?
The team had ~85% confidence in our direction by the end of week three. The remaining five weeks weren't idle, they went into meeting with more users, capturing additional information, and iterating through requirements, building the deeper research record that helped get the recommendation approved so quickly once we presented it. Still, if I could do this project again, I'd push harder to shorten the eight-week timeline to four weeks: the direction was already right early on, and a shorter timeline would have let the contract process begin sooner, moving the team into the next phase more quickly.
How did I grow?
This project introduced me to a new industry, Direct Store Delivery. Going into the project without prior knowledge helped me approach solutions from a fresh perspective while still applying my understanding of the UX process.
Another lesson I learned is that, regardless of business size, industry, team type, or how long co-workers have worked in SaaS, many people still don't understand the role of a User Experience Designer or Product Designer. What I like about the constant advocacy approach is that there is always room to help others learn and to surprise team members through my transparent process, helping to change the mindset that "designer" = "visual design".
