How to Use Product Thinking in The Age of AI

In 2026, AI has made the judgment component of product thinking more important than ever. Building products, from prototypes and requirements to interfaces and code, is much faster now. But faster output doesn’t guarantee better outcomes. Getting value from understanding and applying product thinking requires a shift away from using it as a one-off workflow.

Instead, it’s time to apply product thinking as a decision-making tool applied regularly.

As the Head of Product Design at Userpilot, I do that every day. Here, I’m sharing that experience to show you how to apply product thinking to significantly improve the processes around your product. To do that, I’ll go through the core principles and mental models I use to make those decisions, where that judgment gets difficult in practice, and what product thinking looks like during an ordinary week.

What is product thinking? Hint: not a fixed workflow

Product thinking is the judgment a team applies to frame a problem correctly, weigh what it’s worth solving, choose what evidence to trust, and make informed decisions about what deserves real investment. It recurs across the product lifecycle rather than appearing as one stage you complete before delivery. That distinction is important because too many teams view product thinking as a fixed workflow instead of a way to make regular decisions.

When product thinking becomes merely a set of steps we can run through more quickly than ever with AI, a rethink has never been more necessary. That doesn’t mean a linear process can’t still give product work structure:

• Define the problem.
• Size the opportunity.
• Connect it to a business goal.
• Choose a solution.

The problem is treating those steps as if each one settles the question before the next begins. New evidence can change the problem you thought you were solving, reduce the size of the opportunity, expose a constraint, or make the proposed solution no longer worth pursuing.

For example, look at a store trying to move conversion from 2% to 7% because it’s “leaving $35,000 on the table” every month it doesn’t. The arithmetic can show what a five-point increase would be worth under those assumptions, but it can’t tell you that 7% is achievable, that your proposed change would cause the increase, or that the opportunity is worth the investment.

Product management frameworks exist to expose assumptions, risks, and trade-offs so you can make a better decision with the evidence you have. They give you structure without replacing judgment.

An example of applying product thinking at Userpilot

A recent clarifying example came when I encountered a funnel for Userpilot’s email feature that showed a sharp drop-off around domain verification. Within a few hours, I built a targeted in-app message that highlighted the correct steps without waiting for an engineering release or a sprint.

The behavioral evidence told me where users were getting stuck, but it didn’t prescribe the solution. I still had to decide whether the problem called for an engineering change, clearer guidance, or something else.

In 2015, UX designer Nikkel Blaase argued that features are fragile potential solutions and that the more important questions concern user needs: the problem, the job, the goal, and the value the product creates. He didn’t invent product thinking, but his essay captured an important shift from features to the underlying concept behind them, the problem itself.

The best operational model for product thinking

Taking product thinking beyond a basic way to make decisions requires a structured way of continuously applying it. The clearest operational model I use for product thinking comes from Marty Cagan, founder of Silicon Valley Product Group.

He separates product development into two continuous activities: product discovery, where you figure out what solution is worth building, and delivery, where you build and deliver the product well. They happen in parallel rather than as sequential phases you finish and move past.

Inside discovery, Cagan identifies four risks you need to investigate:

• Value risk: Will customers buy it, or will users choose to use it?
• Usability risk: Can users figure out how to use it?
• Feasibility risk: Can your engineers build it with the time, skills, and technology available?
• Business viability risk: Does the solution work for the business, including areas such as sales, monetization, legal and compliance requirements, partner constraints, and the brand?

Different ideas have different risk profiles, so some risks will deserve more attention than others.

Cagan’s broader point is that a user-centric approach still has to survive feasibility and business viability, beyond customer value alone. That balancing act takes critical thinking and judgment. The four risks only give you a checklist for where to look. You still have to decide which risks matter most, what evidence is strong enough, and when you know enough to move forward.

In my day-to-day work at Userpilot, that evidence often starts with behavior: funnel movement, feature usage, and session replays can tell me where something is breaking down. I still need judgment (and often direct customer feedback) to decide what that evidence means and which risk I’m looking at.

How to make Continuous discovery a part of product thinking

Continuous discovery turns product thinking into a regular habit instead of an occasional user research phase, building a deeper understanding of the problem as new evidence arrives.

The goal is to keep customer evidence close to everyday decisions. This helps you explore why a problem matters and what might solve it before you commit to when it ships or who builds it.

Integrating user behavior and user needs into product management

Teresa Torres, founder of Product Talk and author of Continuous Discovery Habits, defines continuous discovery as at least weekly touchpoints with customers by the team building the product. I pair that direct customer contact with the behavioral evidence I already have in Userpilot.

Interviews and surveys help me hear how customers describe the problem, while funnels and session replays show me where friction appears and how users behave around it. The two sources answer different questions, and I get a stronger picture when I use them together.

Her Opportunity Solution Tree makes that work visible. It connects a desired outcome to customer opportunities, possible solutions, and the assumptions you need to test before deciding what to build.

You test those assumptions because new evidence can send you back through the tree. A failed assumption test might change the solution you pursue, the opportunity you prioritize, or even how you understand the outcome.
Torres also warns against using discovery to justify a decision the team already made instead of shaping the decision itself.

To illustrate an application of Torres’s model, say you want to reduce the time sales leaders spend identifying at-risk accounts. Instead of jumping straight to a dashboard, you interview sales leaders to dig deeper into how they identify risk today, map the needs and friction you uncover, explore several possible solutions, and test the riskiest assumptions before committing to one.

Use product and project thinking together

Shreyas Doshi, a former product leader at Stripe, Twitter, Google, and Yahoo, draws a useful distinction between product thinking and project thinking. Product thinking focuses more heavily on motivations, possible solutions, and the effects you want to create. Project thinking focuses more heavily on expectations, plans, coordination, people, and resources – the work of keeping a team on the same page once direction is set.

According to Shreyas, product thinking is “a mindset and a process that, once you see, you cannot unsee it.” He also argues that growing teams tend to drift toward project thinking because coordination becomes increasingly important. Once you have that product thinking mindset, coordination pressure doesn’t erase it, but competes for your attention instead.

One prompt he picked up at Stripe and still teaches is WAYRTTD: “What are you really trying to do?” It forces you to step behind the requested output and clarify the underlying objective before deciding how to execute it.
Shreyas is equally clear that teams need both modes. Product thinking helps you decide what is worth doing and why; project thinking helps you coordinate the work required to make it happen.

Apply discovery tools to improve your decisions

Several useful tools can help you gather or structure the evidence behind those decisions. You can use them as inputs in your decision-making process.

• The Mom Test: Rob Fitzpatrick’s approach to customer conversations reduces bias by asking about concrete behavior and real experiences instead of pitching an idea or collecting polite, hypothetical approval.
• Jobs to be done: The Christensen-Moesta tradition examines the progress someone is trying to make in a particular circumstance, including the functional, social, and emotional forces shaping their choices.
• Value Proposition Canvas: Strategyzer’s canvas maps customer needs, in the form of jobs, pains, and gains, against the products and services, pain relievers, and gain creators intended to address them.
• Connextra user stories: The “As a…, I want to…, so that…” format, traced to Connextra in 2001, helps name the user, desired capability, and underlying motivation.

Why product thinking in 2026 faces an AI bottleneck

The bottleneck in 2026 is that building solutions for customers is getting cheaper, while selecting, testing, and governing the right one still takes judgment. For AI-powered products, that judgment also has to cover failure behavior, evaluation criteria, human oversight, and whether the problem needs an autonomous agent in the first place.

AI accelerates output, but what about direction?

Marty Cagan calls this the AI Productivity Paradox: teams are visibly shipping faster with AI without seeing a corresponding improvement in outcomes. He argues that many teams are using AI to accelerate the artifacts of the old project model (roadmaps, requirements, prototypes, and code) without improving the decisions behind them. Greater output doesn’t correct a poor choice of what to build.

In that piece, AI product leader Hilary Gridley says:

“It’s never been faster to build, which means it’s never been easier to run 10 times faster in the wrong direction.”

I call one common way teams run in the wrong direction the feature-wrapper fallacy. This is when you bolt an AI chat box onto an existing screen without reconsidering the underlying job, workflow, or risk the feature is supposed to address.

Cursor shows a different approach. Their team forked VS Code instead of building an extension so it could shape the product surface around AI-assisted coding rather than work within the constraints of an existing extension. In Cursor 3, they built a new interface from scratch around agents, creating a unified workspace for coordinating their work instead of treating agents as another panel inside the traditional IDE.

Why “does it work” isn’t the question you should be asking

Once a feature depends on a model rather than deterministic code, “does it work” becomes a more complicated question. You need to understand how performance varies across cases and which kinds of failure matter, instead of relying on one pass-or-fail acceptance test.

Anthropic’s agent-evaluation guidance shows what this approach looks like in practice. Evaluations can inspect things such as outcomes, individual tool calls, multi-step trajectories, intermediate behavior, and whether the system reaches the correct state after acting. Agents operate across multiple turns, use tools, modify state, and adapt as they go, so evaluating only the final answer can miss important failure modes.

Be specific about the target audience for an AI feature, because “the user” often represents several different roles. The person operating an agent, the person paying for it, the person approving its actions, and the person experiencing its consequences may all be different people, and a product decision that accounts for only one of them is incomplete.

I treat every product idea I get, whether it’s from AI, customer feedback, or a teammate, as an experiment. It might be right, it might be wrong, so I still have to test it in the product before I trust it.

Choose the simplest architecture that solves the user need

Before reaching for an autonomous agent, ask whether the problem is predictable enough for deterministic software or a simple prompt-response interaction to handle it. Anthropic recommends starting with the simplest workable approach and adding agentic complexity only when simpler approaches fall short, and the added flexibility improves outcomes.

Picture a support system designed around that principle:

• Route predictable requests through predefined workflows: Known question categories follow controlled paths rather than asking an agent to decide everything from scratch.
• Constrain what the model can use and do: It retrieves approved policy content and handles only actions you’ve decided are low risk.
• Escalate when the consequences get larger: A refund above a defined threshold requires human approval, while unfamiliar or uncertain cases move to a person instead of forcing the model to guess. Then, evaluate the system at each point where it can fail: whether it gives the correct answer, follows policy, chooses the right tool, escalates when required, and recovers when something goes wrong. The architecture itself is a product decision. Skipping that decision in favor of “just add an agent” is project thinking wearing product thinking’s clothes.

How Klarna’s approach to product thinking led them to optimize the wrong metric

Klarna’s AI assistant launched in February 2024 and was handling roughly two-thirds of customer service chats within its first month, doing work the company described as equivalent to about 700 full-time agents.
In May 2025, CEO Sebastian Siemiatkowski described the downside of optimizing so heavily for cost and efficiency:

“As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality.”

Klarna committed to always giving customers a path to a human and began rebuilding that part of the user experience alongside its continued AI use. This was a course correction rather than an abandonment of AI: the company kept using automation while changing what it optimized for.

Ryan Singer’s appetite concept, from Basecamp’s ShapeUp, is a positive counter-example. Instead of starting from a design and estimating how long it will take, you first decide how much time the problem is worth, then let that constraint shape the solution you’re willing to build.

From Klarna, I learned that efficiency is only useful when it improves the outcome you care about in the first place. Execution speed isn’t the same thing as issue resolution, and if your product metrics only capture the first, you’ll find out the hard way that you missed the second.

How to put product thinking into practice in 2026

When a metric moves in the wrong direction, I work through the same basic questions:

1. Define the outcome that should change.
2. Instrument the behaviors that indicate progress toward it.
3. Use a funnel to find where progress stops.
4. Review session replays and qualitative feedback to understand what may be causing the friction.
5. Choose the lowest-cost intervention that tests your current explanation.
6. Measure what happens and decide whether the product itself needs to change.

Running that loop regularly is how I cultivate product thinking day to day.

The domain-verification example from the beginning of this article followed that pattern. We used a checklist to support the broader email-feature activation journey, then added a targeted in-app message when the data showed users were still getting stuck around verification.

By my read of the behavior afterward, it reduced friction, but I didn’t have a clean conversion number to attach to it. That kind of directional signal is still a valuable asset, even without a hard number attached. The underlying verification experience could still need a more durable product change.

This is where Userpilot fits naturally into the process. Funnel analysis, session replay, and surveys connect so you can find a pain point in the funnel, inspect the sessions where it happened, and hear directly from affected users.

Only then should you decide whether the next move is a message, a redesign, or no change at all. Userpilot also connects analytics with in-app experiences, so you can act on what you learn without automatically turning every problem into an engineering project.

If your team is trying to close the gap between what you’re tracking and what you do about it, book a demo to see how Userpilot helps you turn behavioral evidence into the decisions that build a successful product.