How I work
A few things I’ve come to believe about building products.
These aren’t rules. They’re habits I’ve learned to trust, from shipping, from breaking things, and from rebuilding with teams I’m grateful for.
Decision
A product page isn’t a document. It’s a decision.
Most product pages just list information. The good ones make the decision smaller.
Customers rarely show up wanting more content. They show up with a question they may not be able to put into words: is this the right one for me, and what happens if I get it wrong?
So I ask the same thing of everything on the page. Is it helping someone choose, or just sitting there?
Evidence
Plans get people moving. Prototypes make ideas testable.
Roadmaps are good for getting people moving the same way. They’re less good at telling you whether that way is right.
The most honest test I’ve found is to build a small version and watch someone actually try to use it.
It doesn’t need polish. It needs to be real enough that people react to the thing itself, not to their own picture of it. That’s where the interesting disagreements show up, early and cheap.
Judgment
AI hasn’t replaced product judgment. It’s made it easier to see.
When building took weeks, process felt like a comfortable place to live.
Now an afternoon can produce something real. So the question moves from whether we can build it to whether it’s worth building at all.
Making things got cheaper. Knowing what to make, and what to leave alone, got more valuable.
Conviction
Conviction comes after the evidence.
Confidence before the evidence is a risk. Confidence after it is conviction.
A prototype helps me get from one to the other, and customer behavior settles it. It’s the small piece of reality that shows the difference, to me first, then to the people I’m asking to share the bet.
How I run product discovery
Three lenses, one loop, and a team that learns as it builds.
You can’t decide what’s worth building from a conference room. So I go find out. I talk to customers, put rough prototypes in front of them, and watch what they do. It keeps the customer first, and it keeps all of us honest about what we actually know.
Every idea has to get past three lenses.
I start with people. Then I check that we can build it and that it works for the business. The ideas worth building sit where all three meet.
Desirable Start here
Do people want it?
First, the customer: what they’re trying to decide, and what’s in their way.
Feasible
Can we build it?
This is where my engineering background helps. I check the data, the systems, and the integrations early, often with a working prototype.
Viable
Does it work for the business?
It has to be something the company can sustain and make money from, not just something customers like.
The work is a loop, not a line.
Five steps, but rarely in a straight line. What we learn while testing often sends us back to the start. That’s not the process failing. That’s it working.
- 01 · User research, interviews
Empathize
User research and interviews: find out what people are trying to do, in their own words.
- 02 · Problem framing
Define
Frame the problem worth solving, and agree on who decides.
- 03 · Options, not one answer
Ideate
Open up lots of ways to solve it before picking one.
- 04 · Working prototypes
Prototype
Build the smallest working version that lets us test the idea.
- 05 · User testing
Test
User testing: put it in front of people, then watch what they actually do.
- Empathize → Define. Empathy helps define the problem.
- Prototype → Ideate. A prototype sparks a new idea.
- Test → Prototype. Tests create new ideas.
- Test → Define. Tests can redefine the problem.
- Test → Empathize. Testing teaches us about people.
It fits how teams already work.
Design thinking and agile get along better than people expect. They share four habits, so discovery and delivery can run on the same beat.
Iterative
Small steps, and learn from each one.
User-centered
The customer decides when it’s done.
Collaborative
Design, engineering, data, and business, all at one table.
Adaptable
Plans change when the evidence does.
Frameworks adapted from the Interaction Design Foundation (interaction-design.org).
Watch · about 2 minutes
What shoppers see is just the tip of the iceberg.
Say “user experience” and most of us picture screens, websites, and apps. That’s only what sits above the water. Here’s how I work through the five layers underneath.
Read the transcript
- Captain’s log: every product starts as a voyage. Out on open water, the captain keeps watch for what lies ahead. “Iceberg ahead!”
- Through the binoculars: from the deck, it looks small. Only the tip shows above the water. A good captain knows most of an iceberg sits below.
- When we hear “user experience”, we picture screens, websites, and apps. That’s only what shows above the water.
- A shopper sees a product page. That’s all they see. Most of the work sits under the water.
- In The Elements of User Experience: User-Centered Design for the Web (2002), Jesse James Garrett describes five layers: strategy, scope, structure, skeleton, and surface. I build from the bottom up.
- Strategy, who: who is it for, and what do they need? Before we build anything, research tells us who’s shopping and where they get stuck. This is product discovery: user research, user interviews, personas, and empathy maps. A shopper asks, “Will this valve work with the trim I already have?” Research completed.
- Strategy, why: does it work for the business too? If it doesn’t make money, the business can’t keep it going. Every idea goes through three lenses: desirable (human, start here), feasible (tech), and viable (business). We aim for where they meet. Goals identified.
- Scope, what: what will we build to answer it? Features, functionality, and product data, chosen together: design, engineering, data, and the business. “I strongly recommend focusing on the foundational layer before bringing in any kind of shopping agent.” (Me, in The CMO Wire, May 2026.)
- Structure, how: how does it work? The blueprint: how the system works behind the scenes, and how shoppers move through it, with the product facts behind each answer. Flows and information architecture.
- Skeleton, where: where does everything go? The first interfaces, and the first tangible version of the experience. Where the answer sits, so it’s easy to find. Layout, navigation, and wireframes.
- Surface, feel: what does the shopper see and touch? The most visible layer: the look, the words, the moment of confidence, resting on everything below. Visual design and words.
- Every layer affects the others. Change one layer, and the ones above it change too. Add a new feature, and the structure, skeleton, and surface all move with it.
- It works both ways. Users surprise us. When people use a product in ways we didn’t expect, it can send us all the way back to rethink the strategy.
- Into the unknown: some things only show up later. Technical challenges or budget limits can surface mid-build and send us back to earlier decisions. That’s why I test early, with research and prototypes.
- I start at the bottom, with the customer, and work up: from the abstract to the concrete. Product discovery lives in the lower layers, and the work keeps changing for as long as the product is live. Research, interviews, prototypes, user testing.
Product discovery, step by step
Why I prototype.
Why prototypes, user research, interviews, and testing? Because those three lenses need real answers, not opinions, and what we learn at any step can send us back to an earlier one.
Start here
Three lenses, and people come first.
What do people want? Can we actually build it? And can the company make money from it? I only push an idea forward when all three answers are yes.
01 · Empathize
User research and interviews
Listen first.
I learn what people are trying to do, in their words, and what gets in their way. Before anyone argues about the answer, I get us all looking at the same question.
At work, this meansSorting logged shopper questions to see where the AI agent lets people down.
02 · Define
Problem framing
Frame the decision first.
Before any design work, I ask: what’s the customer unsure about? What’s the business risk? Who owns the call? Answer those, and the work has a direction.
At work, this meansNaming the real checkout question: payments were failing, not missing.
Empathy helps define the problem.
03 · Ideate
Options, not one answer
Open up options with the room.
Before we choose, I sit down with design, engineering, analytics, legal, and the business, and we sketch several ways to solve it. It’s much cheaper to hear a concern now than after it’s built.
At work, this meansRanking payment options and mapping each one across web, mobile, and order management.
04 · Prototype
Working prototypes
Make the idea testable.
I build something rough that actually runs. Once people can click it, the argument gets shorter and the question gets specific.
At work, this meansA vanity configurator prototype, so leadership could try it, not imagine it.
A prototype often sparks a new idea.
05 · Test
User testing
Test, and let go when an idea falls flat in user testing.
I put it in front of people and watch what they do. Not every idea earns the next sprint. The job is choosing, and being OK letting go of what the evidence doesn’t support.
At work, this meansGrading the AI agent’s answers by product line, and improving it from what the evals and customers show.
Tests can redefine the problem, create new ideas, and teach us about people.
Watch · about 1½ minutes
From discovery to delivery.
How a product manager’s role changes as an idea grows: steering a small crew through discovery, then sailing with the whole team through delivery.
Read the transcript
- From discovery to delivery. How a product manager’s role changes as an idea grows.
- AI changed the first mile. A small crew can now turn an idea into a working prototype much faster.
- Discovery: I steer with a small crew. A UX designer, an architect, and me. We prototype quickly with AI, test with real users, and do the research.
- We find our North Star: the problem worth solving, and what success looks like.
- Leadership says yes. Now the idea is ready for the whole team.
- The crew grows: the whole team comes aboard. Engineers, QA, and a Scrum Master join UX, the architect, and me. We build the development plan together.
- I share what we learned: who it’s for, why it matters, and what good looks like.
- Delivery: now I sail with the team. I set direction, clear the blockers, and make the path. The team builds it.
- If I kept prototyping alone, the team would drift.
- We reach the first harbor together: something real customers use. Then we watch what they do with it.
- And then, back to discovery. While the team keeps improving it from what customers do, I start steering the next idea.
- As the idea grows, the crew grows. So does the product manager’s role. How does yours change from discovery to delivery?
How I work
Build with purpose.
Learn what matters.
I usually start by asking what we’re really trying to learn. Then I frame the decision, look at what customers actually do, and build a small version that could prove it. That gives the team something concrete to push on.
Frame the decision first.
Start with what the customer isn’t sure about, the business risk, and who owns the call. Once those are clear, the rest of the work has a direction.
Make the idea testable.
A prototype makes an idea testable. Customer behavior tells us whether it creates value. Even a rough working version settles arguments that slides never would.
Align the room around it.
Bring design, engineering, analytics, legal, and business partners to a shared picture of the problem. Then tradeoffs show up before they turn into rework.
None of these are finished. They keep getting sharper each time a customer, a teammate, or a prototype proves me wrong.
Read the thinking behind themSee the prototypesProduct basics, for new PMs
Say hello
Got a decision customers
keep stalling on?
I’m interested in where shoppers hesitate and what helps them move forward. If you’re thinking about similar problems, I’m always glad to compare notes.
nagesh@nageshkoritala.com
