Intro: 

The shift to agent-driven systems isn’t just a UX evolution — it’s a product rethink. Just as "Jobs to Be Done" gave us a lens for outcome-based design, "Agentic Product Thinking" provides a new framework to guide product leaders through the transition to intent-first, outcome-driven systems.

This post introduces the foundational principles of agentic product thinking — not from a technical implementation standpoint, but from the perspective of how software products will change in form, function, and experience.


Section 1: From Interfaces to Outcomes 

For decades, software has been structured around interfaces — users navigate screens, fill out forms, and click buttons to get things done. Agentic systems flip this model. The user declares an outcome. The agent determines the best way to accomplish it. The interface is no longer the product — the outcome is.

Example: Instead of navigating to the HR portal and entering new hire data, the user simply says "Add Jillian Hunt to the marketing team." The agent orchestrates the workflow — data collection, compliance checks, provisioning — with minimal friction.

Section 2: The Handoff Zone

From Intent to Input Once a user expresses intent, the agent needs supporting information. This creates a critical handoff: does the system collect input via chat-style prompts, or present structured UI?

This is where the concept of the agentic UI node comes in — a temporary, agent-triggered UI element that gathers structured input contextually, within the flow of conversation.

Use dialogue when:

  • The data is minimal (1–2 fields)
  • You want to preserve flow
  • The user may improvise

Use an agentic UI node when:

  • There are 3+ fields
  • Validation is required
  • A visual structure enhances clarity

Agentic UI nodes aren’t screens or modals — they’re transient, contextual, and owned by the agent.

These nodes can also be persisted as part of a "tabbed" interaction model — allowing users to return to tasks that are in-progress or paused due to missing information, dependent events, or user prioritization. The agent remains responsible for helping manage and return to these partially completed outcomes.

Section 3: Implications for Product Design 

Agentic systems reshape how we design, measure, and structure software products:

  • Flows become outcomes. You don’t design screens — you define success states.
  • Navigation becomes suggestion. The user doesn’t go places — they ask for results.
  • Interfaces become ephemeral. UI is invoked only when needed, and discarded when done.
  • Success metrics shift. Completion rates, trust levels, confidence thresholds become primary KPIs.

Section 4: Toward a Framework for Agentic Product Thinking 

Just as JTBD helped product managers shift away from feature-thinking, agentic product thinking helps PMs focus on:

  • Intent clarity: What does the user want, and how does the system know?
  • Trust modeling: When should the agent act, ask, or escalate?
  • Orchestration: How does the system break outcomes into coordinated actions?
  • UI injection: When should structure interrupt conversation?

This is not a chatbot UX strategy. It’s a new product surface area — one where actions feel intelligent, timely, and invisible.

Closing: 

Agentic systems don’t just change what users do — they change what software is. Product leaders need new tools, new language, and new mental models to navigate this shift. Agentic product thinking is a call to design with outcomes, not pages. To measure trust, not clicks. To orchestrate actions, not interfaces. Because the future of software isn’t a screen. It’s a system that gets things done.