At a Glance
- Business problem: Multidisciplinary teams across IBM struggled to define solid analytic, ML, and AI requirements, slowing delivery and producing weak or contested specs
- My role: Identified the systemic gap, invented the approach, and championed it into a scalable, repeatable method across teams
- Recognition: The method was captured in a patent — Rapid Development of User Intent and Analytic Specification in Complex Data Space (US P202007466)
- The approach: A "Mad Lib" model that structures how teams articulate user intent and translate it into analytic specifications
- Why it worked: It gave people from different disciplines a shared language and a fast path from fuzzy intent to a prioritized, vetted spec
- Strategic impact: Changed how IBM teams develop requirements for model-driven experiences — turning a recurring bottleneck into a reliable process
The Challenge
Complex data spaces are where good product teams go to get stuck. The value is obvious, but the path to it is not. What exactly should the model do? For whom? What counts as a good answer? These questions sound simple, yet they collapse the moment a room full of specialists tries to answer them together.
I watched this happen again and again. Data scientists framed problems in terms of what the data could support. Designers framed them around user needs. Product leaders framed them around business outcomes. Each view was valid, but none of them connected. The result was slow alignment, requirements that drifted, and models built on assumptions no one had truly agreed on.
There were really two problems to solve:
- Cut through the silos. Understand what clients actually needed from their data insights without letting each discipline pull the conversation in its own direction.
- Make it repeatable. Create a process any team could use to rapidly design, vet, and prioritize analytic, ML, and AI requirements — not a one-time workshop that depended on me being in the room.
That second point mattered most. A single good outcome helps one team. A repeatable method changes how an entire organization works.
The Approach: A Shared Language for Intent
I designed the solution around a deceptively simple idea: if teams can't agree on requirements, give them a structure that forces clarity and shared understanding at the same time.
The Mad Lib model. The heart of the approach is a fill-in-the-blank structure — a "Mad Lib" — that guides a team to articulate user intent and translate it directly into an analytic specification. By constraining how people express a requirement, the model does something powerful: it strips away discipline-specific jargon and surfaces the real intent underneath. A data scientist and a designer end up filling in the same blanks, and suddenly they're talking about the same thing.
That structure did three jobs at once:
- It exposed assumptions early, before they got baked into a model.
- It created a common language that let specialists collaborate without translating across silos.
- It made prioritization fast, because requirements arrived in a consistent, comparable form the team could vet and rank together.
Built to scale. I intentionally designed the method to work without me. It wasn't a facilitation trick or a personal skill — it was a model teams could pick up and run on their own. That's what made it worth patenting, and what made it valuable to the broader organization: a repeatable path from fuzzy ambition to a specification a team could actually build.
Key Insights
Building and scaling this method taught me lessons that now shape how I lead product and design organizations.
- The requirements stage is where AI products quietly succeed or fail. Most attention goes to models and interfaces, but the costliest mistakes happen upstream, in how intent gets defined. Fixing that stage pays off everywhere downstream.
- Silos aren't a people problem — they're a language problem. Smart, well-meaning specialists stall not because they disagree, but because they lack a shared structure. Give them one, and collaboration follows.
- A method beats a moment. Solving one team's requirements is useful. Giving every team a repeatable way to solve their own is transformational. The leverage lives in the process, not the single outcome.
- Structure creates speed. Constraining how people express intent felt counterintuitive, but it dramatically accelerated alignment. The right structure removes friction rather than adding it.