Nagesh Koritala, product manager

Product judgment. Engineering depth. AI-native execution.

I’m a product manager at Kohler, leading work across the conversion funnel. I turn customer insight into clear priorities and align teams to deliver.

Nagesh Koritala in a checked blazer over a black sweater, smiling, beside a cut-paper collage of the product work he does: a chat, a payment form, finish swatches with one circled in red, and charts.

Work

Three product decisions, and the easy path each one set aside.

The quick move was to write a ticket and hand it to engineering. I didn’t. I worked with the people asking to find the real problem, and only then did we build.

Complete your install

For this product

  • Faucet$289.00 (included)

We recommend

  • Drain assembly$34.99 (not included)
  • Supply lines$18.50 (not included)
  • Installation kit$12.75 (not included)
  • Faucet cleaner$9.99 (not included)

Selected (1)$289.00

Add to cart (1)

Illustrative concept

The easy path, set aside:More faucets like this one

Our call:Everything it takes to install this one

LiveRecommendations

What else do I need to install it?

Once a shopper picks a faucet, more faucets don’t help. The parts to install it do.

I noticed customers coming back within days of a big purchase to buy the parts they needed to install it. So I worked with merchandising to put those parts right on the product page.

How we knew it was workingAverage order value and units per order both went up from these recommendations.

See my work access code

Nagesh Koritala in a charcoal sweater, reading a tablet, beside a cut-paper collage of a shopper’s chat and a grid of product facts, with a gap circled in red.

The easy path, set aside:Patch weak answers one by one

Our call:Fix weak answers at the source

LiveAI shopping

Is this the right one for me?

Shoppers need answers they can trust. So we agreed on what a good answer looks like, and we keep checking the agent against it.

My leadership team brought the idea. I’ve been its product manager from the first day through launch, and I still am. I wrote the guardrails, and I keep improving it from what the evals and customers tell us.

How we knew it was workingOur evals showed answer quality improving because we fixed the underlying data gaps.

Full case study: Is this the right one for me? access code

Nagesh Koritala in a navy blazer over a white T-shirt, beside a cut-paper collage of payment cards whose arrows meet at one checkout form, circled in red.

The easy path, set aside:Add more payment methods first

Our call:Fix the failing payment. Then add choice.

LiveCheckout and payments

Why did my payment fail?

A payment that keeps failing breaks trust. So we fixed it first, before adding more ways to pay.

I brought the problem statement to the team. Together we concluded that failing payments had to be fixed before we added new ways to pay, and leadership and stakeholders backed that order. We fixed the systemic errors in our checkout APIs and payment gateway, and rewrote the error messages so customers can fix the problem themselves.

How we knew it was workingFewer payment failures at checkout.

Full case study: Why did my payment fail? access code

Full case studies are shared by access code. All case studies See the prototypes

A short film

Why I start where customers get stuck.

My answer, in 89 seconds.

0:00
Original music, written for this film.
Read the transcript
  1. When we can build more, what is worth building?
  2. AI has increased our ability to build faster than our confidence about what deserves to be built.
  3. So we don’t start with a feature list. We start where customers get stuck.
  4. Not the newest idea. Not the loudest request in the room.
  5. One problem worth solving.
  6. We test a few ways to solve it, and watch what customers do.
  7. The goal isn’t building more things.
  8. The right thing.
  9. When an idea falls flat with customers, we let it go.
  10. We keep looking until one really works.
  11. The next shopper doesn’t stop to ask.
  12. They buy what they came for.
  13. So what’s worth building? The thing that solves the customer’s problem.
  14. Worth building.

How I run product discovery

What I do before we build anything.

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.

Three overlapping circles. Desirable, marked start here: Do people want it? Feasible: Can we build it? Viable: Does it work for the business? The goal is where all three meet: worth building. $ DesirableFeasibleViable Start here Do people want it? Can we build it? Does it work forthe business? Goal Worth building Three overlapping circles. Desirable, marked start here: Do people want it? Feasible: Can we build it? Viable: Does it work for the business? The goal is where all three meet: worth building. $ DesirableFeasibleViable Start hereDo people want it? Can we build it? Does it work forthe business? Goal Worth building

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.

  1. Desirable Start here

    Do people want it?

    First, the customer: what they’re trying to decide, and what’s in their way.

  2. 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.

  3. 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.

Empathize · User research, interviews

Listen first.

I listen for what people are trying to do, in their own words, and where it goes wrong for them.

At work, this meansSorting logged shopper questions to see where the AI agent lets people down.

Nagesh walking in with a coffee.
their words, not mine

Frameworks adapted from the Interaction Design Foundation (interaction-design.org).

How I work

About me

A product manager who started as an engineer.

I’ve worked in digital for 14+ years. Before product, I was an engineer, building the systems behind e-commerce sites, including the one I work on today. That background helps me judge early what’s feasible and work through tradeoffs with engineers. When we’re unsure about an idea, I build a quick prototype so we can test it with customers first.

Learn with me

I teach what I practice.

Free and interactive, for product managers at any stage. Every lesson links its sources.

  1. Course · 15 lessons

    Product basics

    The job itself, from the first customer problem to interview prep.

    Start with: What is product management?

  2. Course · 9 lessons

    AI for product managers

    How AI products and agents work, from a product manager’s view.

    Start with: How an AI product works

  3. Field guide · 13 lessons

    Anatomy of a Checkout

    How card payments and checkout work, one diagram at a time.

    Start with: Improve the checkout

See everything I teach

Say hello

Deciding what’s
worth building?

So am I, every week. I’d love to hear what’s on your list, and what you’re leaving off.

Nagesh Koritala in an olive overshirt, sitting on the edge of a desk with a coffee mug, smiling with an open hand as if mid-conversation, beside a cut-paper collage of two armchairs, a small table with mugs, and a speech bubble.