About this episode
In this second part of my three-part series (catch Part I via episode 182), I dig deeper into the key idea that sales in commercial data products can be accelerated by designing for actual user workflows—vs. going wide with a “many-purpose” AI and analytics solution that “does more,” but is misaligned with how users’ most important work actually gets done.
To explain this, I will explain the concept of user experience (UX) outcomes, and how building your solution to enable these outcomes may be a dependency for you to get sales traction, and for your customer to see the value of your solution. I also share practical steps to improve UX outcomes in commercial data products, from establishing a baseline definition of UX quality to mapping out users’ current workflows (and future ones, when agentic AI changes their job). Finally, I talk about how approaching product development as small “bets” helps you build small, and learn fast so you can accelerate value creation.
Highlights/ Skip to:
Continuing the journey: designing for users, workflows, and tasks (00:32)
How UX impacts sales—not just usage and adoption(02:16)
Understanding how you can leverage users’ frustrations and perceived risks as fuel for building an indispensable data product (04:11)
Definition of a UX outcome (7:30)
Establishing a baseline definition of product (UX) quality, so you know how to observe and measure improvement (11:04 )
Spotting friction and solving the right customer problems first (15:34)
Collecting actionable user feedback (20:02)
Moving users along the scale from frustration to satisfaction to delight (23:04)
Unique challenges of designing B2B AI and analytics products used for decision intelligence (25:04)
Quotes from Today’s Episode
One of the hardest parts of building anything meaningful, especially in B2B or data-heavy spaces, is pausing long enough to ask what the actual ‘it’ is that we’re trying to solve.
People rush into building the fix, pitching the feature, or drafting the roadmap before they’ve taken even a moment to define what the user keeps tripping over in their day-to-day environment.
And until you slow down and articulate that shared, observable frustration, you’re basically operating on vibes and assumptions instead of behavior and reality.
What you want is not a generic problem statement but an agreed-upon description of the two or three most painful frictions that are obv
