Building the Right Product in an Unknown Domain

Clients received test results as PDFs manually attached to emails. Oritain had no product or design function, but wanted to build a data insights platform. Leadership, Sales, Science, and Operations all had different ideas about what that meant.

I joined as UX Lead alongside a Product Manager with a mandate that was broad: determine what data product Oritain should build.

There was no roadmap, no prior customer research, and no shared definition of success. We had four months to reduce uncertainty and recommend a direction to present to the Board of Directors.

Before discussing solutions, I needed the organization aligned on what it believed to be true, what it knew, and what it was merely assuming.

× ‹ ›

An Oritain teammate contributes to an assumption mapping workshop—helping establish a shared baseline and shape the research plan.

Before talking to clients, I ran a workshop with Sales, Operations, Science, and Technology to map what the organization believed. We sorted assumptions by confidence and consequence. One rose above everything else: our solution solves the client’s problem. The team marked it high risk, unknown. That became the question the research had to answer.

× ‹ ›

An assumption map created during an internal workshop I facilitated—used to surface existing beliefs and guide early research.

I spoke with 14 supply chain experts from 9 clients over 3 weeks. Testing speed was the most critical pain, but after confirming the science couldn’t move faster, I had to think differently. Clients had no visibility into where their test was in the process and no idea when it would arrive. They had resorted to emailing account managers to manage their timelines. The solution wasn’t speed, it was transparency. They needed delivery estimates they could build a production schedule around.

× ‹ ›

A service blueprint I created to map complex client workflows and clarify how Oritain’s testing fit into their broader processes.

The synthesis meant delivering two uncomfortable messages to leadership: PDF test results weren’t fully meeting client needs, and the data insights product they were excited to build wasn’t what the research indicated clients needed next.

It created a sequencing decision. Clients were interested in deeper insights, but they were still struggling with capabilities they considered basic. Delivering advanced analytics before solving those fundamentals would have increased frustration rather than value.

The research synthesis and resulting product strategy aligned leadership around a fundamentals-first direction: first establish trust through transparency, then build toward higher-value analytical capabilities once the foundation existed.

× ‹ ›

The research revealed three Jobs to Be Done, and more importantly that they were sequential. That hierarchy became the organizing principle for the product strategy.

The CEO asked for a condensed version of the synthesis for board conversations, signaling that the work had moved beyond informing product decisions. For an organization with no prior research practice, it had become something rare: a shared language for understanding their own clients.

× ‹ ›

The fundamentals-first direction produced a platform built around transparency. Clients could see every test in progress, track delivery estimates, and surface high risk findings without contacting Oritain. Design lead: Ryan Shafer, execution in collaboration.

After the strategy was defined, a significant implementation risk emerged. Oritain’s internal systems were organized around Collection Events, a structure that made operational sense but didn’t match how clients thought. Clients worked in SKUs, material references, and supplier relationships.

I worked with Product and Engineering to evaluate three options:

• Replatform the underlying architecture
• Build a translation layer between internal and external models
• Preserve the existing structure while improving discoverability

The first two carried too much delivery risk for an MVP timeline.

× ‹ ›

Clients didn't organize around Oritain's internal taxonomy. My Identifiers surfaced their own references directly in the navigation and IA.

We kept the existing architecture and focused on surfacing client identifiers throughout the experience. We initially labeled them “Custom Identifiers,” but testing told us clients didn’t see them as custom at all. We renamed them “My Identifiers” and built a path toward customer-configurable organization into the roadmap.

The biggest discovery wasn’t a UI problem. Testing revealed that results data carried legal implications we hadn’t fully accounted for, and that clients needed strict control over what was visible, to whom, and under what conditions.

× ‹ ›

A feedback session aimed at validating client expectations, but led to a major issue with our MVP strategy.

Notifications were the most immediate casualty. Getting clients aware of new results quickly was central to the product strategy, but a simple notification solution wasn’t viable. Clients needed granular control over role level permissions, determining what each person could receive and what those notifications could contain. That complexity pushed notifications to a post-MVP release.

Tier 1 clients were onboarded within 90 days, which required a significant data cleaning effort before they could go live. While we waited for production cycles to complete before running follow-up research, we moved up the Jobs to Be Done hierarchy and prototyped a risk modeling tool to answer the question I kept hearing in research: now that my tests are complete, where should I focus next?

× ‹ ›

The risk ranking prototype let clients benchmark their facilities against global data. Legal teams raised concerns before it could ship. Simply having access to the data was enough to create liability, whether they used it or not.

Users wanted it shipped as soon as possible. But when we attempted a beta rollout, their legal teams raised serious concerns we needed to address. The interface made supply chain risk visible, and visible data that went unacted on was a liability. If the system showed a problem and the client couldn’t demonstrate they had responded to it, they were exposed.

× ‹ ›

The map view made geographic risk patterns immediately visible, giving clients a country level understanding of risk that could inform their vendor strategy.

The legal blocker reframed the design problem entirely. The question was no longer how to surface data insights, but how to help clients answer “what next” without letting them see the underlying data in a way that created a discoverable record.

Once it became clear that any persistent view of risk created legal exposure, I needed an interaction model that could deliver guidance without creating a durable record.

Help me decide what to do next—without increasing my exposure.

My solution was a RAG-based conversational interface. Rather than displaying data patterns directly, clients could query their own testing history through a private session, receive contextual guidance on where to focus their next round of testing, and book that plan with a single click. Each session was stateless by design, leaving no trace of what was asked or surfaced. Clients got the strategic guidance they needed without the liability of having seen data they could be expected to act on.

While at concept stage, this direction opens the door to a premium AI offering that delivers strategic insight without increasing client exposure.

• Tier 1 clients onboarded within 90 days, including a significant data cleaning effort
• Test result delivery reduced from days to seconds
• Zero contractual disruptions at launch
• Research synthesis became a tool the CEO used in board conversations
• Continuous research uncovered a liability problem that redirected the product roadmap and led to an AI concept worth pursuing.

Client Feedback:

The feedback said it better than any metric could.

Suppliers report the portal being easy to navigate, with timely guidance and efficient troubleshooting. We are very pleased with this demonstration of commitment to the customer experience… [Redacted Client] has high standards, and we appreciate your partnership in easing the supplier compliance burden.

[Redacted Client] was extremely impressed– they used “bravo” and “excellent” to express themselves. They were asking who built it for us and how they can get in touch with them.

The most important decision in this project wasn’t a design decision. It was telling leadership to build something different than what they wanted.

Users needed fundamentals before insights. Delivering in the wrong order would have undermined what the leadership was trying to accomplish with the business. Understanding that distinction, and having the research to back it up, was what made redirecting an entire organization’s strategy possible.