Skip to case study
← All workSelling the big idea, shipping the smallest oneOverview
Product design·HPE·Agentic AI for ML pipelines

Selling the big idea, shipping the smallest one

Leadership asked for an AI feature. Ten out of ten interviews pointed somewhere else: data scientists felt guilty, not stuck, when an expensive pipeline failed and they couldn't tell the engineer why. I reframed the brief, won leadership over with a prototype of the full idea, and shipped its smallest form in one week. The following week, the whole department was laid off.

Role
Product designer, solo
Team
One developer intern, one language model wired to live pipeline logs
Timeline
A pitch for the full idea, then a 1-week build
Research base
10 user interviews, 1 cross-functional workshop
The Pachyderm job log viewer: a failed job's timestamped logs in the center, and an Explain Logs panel open on the right showing a GPT-3.5 chat that identifies a schema mismatch between the GlotusDB source and the KryptonProcessor pipeline, and recommends checking the data contracts.
Fig. 01The smallest version.An Explain Logs panel, right where the failure already is. It tells a data scientist whether the fault is theirs to fix or the engineer's, so they arrive at the engineer's desk with an answer instead of a question.
01

An ask for AI, and a team feeling guilty

Running a machine learning pipeline could cost $10,000 or more a day, and a typical run lasted four to seven days. When one failed, a data scientist usually had to ask a machine learning engineer to find out why.

The old right panel during the same failure: pipeline name, job ID, and roles at the top, then a Subjob Summary reporting the job Failed: 106 total datums, 45 processed, 32 skipped, 19 failed, 10 recovered, with no explanation of what went wrong or what to do next.
Fig. 02A count, not an answer.The old panel reported that 19 of 106 data items failed. It never said why, or what to do next.
A simplified diagram of the two roles around the AI model: the data scientist supplies business context, datasets, tuning, and training; the ML engineer builds and maintains the infrastructure, feature engineering, and scaling underneath a model running at $10,000 or more a day.
Fig. 03Two roles, one expensive pipeline.The data scientist supplies context and data, the engineer keeps the infrastructure running, and each side only sees half of a pipeline costing $10,000 or more a day.

Leadership arrived with a reasonable ask: ship an AI feature. The team had just invested in expanded documentation and a ChatGPT assistant wired to it, hoping people would learn to build pipelines that failed less.

All ten interviews named the same problem without being asked: miscommunication between data scientists and engineers. Data scientists didn't say they lacked tools. They said they felt guilty, that they were letting a teammate down. One wanted "a translator to go between us."

That's a relationship problem, and a documentation chatbot answers a different question. So I reframed the brief from "build an AI tool" to "help people see into AI systems and infrastructure they can't read."

A research synthesis board: Pain Points quotes about HPE's steep learning curve on the left, a bank of open-ended AI Implementation Value ideas on the right, and a Reframe panel below crossing out 'Build an AI tool.' and replacing it with 'Build a tool that helps users gain clarity into opaque AI systems and infrastructure.'
Fig. 04Crossing out the brief."Build an AI tool" became a tool that helps people see into AI systems they can't read. AI stayed the answer. The question changed.
02

Selling a bigger idea than we could build

The strongest concept was a passive agent that watched pipelines in the background and alerted people when something broke. It scored high on what people wanted and low on what we could build. It also fit how people actually used the product. Once a pipeline was stable, they checked on it about once a week, so nobody would be watching when it failed.

A Big Ideas workshop board: a mocked-up 'Welcome back' events screen listing failed pipelines on the left, and on the right an idea note reading 'It's like concierge for my work: take the pressure off of having to find where this has gone wrong, and provide me ways to fix the problem,' scored Feasibility: Low and Desirability: High.
Fig. 05The big idea, scored honestly.A "welcome back" screen listing what failed while you were away, described by one participant as a concierge for their work. High on what people wanted, low on what we could build.

Leadership had doubts, and the scope was the reason. So I built a prototype of the full agent, a north star for where the product could go, and presented it to leadership, development, and design together. Seeing it won everyone over, and the one-week build started from there.

The call
Keep the vision. Ship the smallest piece of it.
With a week to build, I scaled the agent all the way down, and that had a real cost. The agent's value was that people wouldn't have to watch their pipelines so closely, and the smallest version couldn't do that. What shipped is an Explain Logs button, right where a person already is when a pipeline fails. One tap returns a plain-language summary, including the one thing that used to take a conversation: whether the fault was in the pipeline itself or in the infrastructure underneath it. It also suggests a next step, such as checking the data contracts, and the person decides whether to act on it.

I argued for building it in code, wired to a live language model reading HPE's real pipeline logs. The riskiest unknown was whether people would trust an automated explanation of their own failure. A mocked-up answer can't test that, because trust depends on the answer being right, and only a real model reading real logs can be wrong in the ways that cost it.

01The pipeline dashboard for TRAIN_DATA_queries, showing a healthy pipeline next to a failed subjob, with View Logs and Pipeline Actions in the panel beside it.
02The job's log screen, listing the failed extraction steps, with the cursor clicking the Explain Logs button in the panel on the right.
03The Explain Logs setup panel, asking for an OpenAI API token, or for teams with their own LLM, a model URL and token instead.
Fig. 06One tap from the failure.The dashboard shows which step failed, one click opens the explanation on the same screen, and teams can connect their own language model instead of sending logs outside the company.
03

What happened

The proof of concept shipped on a Friday. Within the week, the entire AI Solutions department, this team included, was laid off. The user test that would have proved or challenged the idea never ran. What the week did settle is that it could be built on real logs, by one designer and an intern.

04

Looking back

The most valuable things this project produced weren't the prototype. They were the reframe and the insight behind it. If I'd known how little runway was left, I'd have spent less of the week polishing the build and more of it writing the research down so it could travel without the team. On every project since, I've written the research readout as if the team might not be there to present it.