Discovery for a Product People Already Depend On

Improving a mature product is harder than building a new one. Every user already has a workaround, and every workaround is holding something up. Good discovery on a product like that finds the specific break in a workflow people run every day, fixes that break, and leaves the rest alone until the evidence says otherwise. Here's how I do it, and the two engagements that taught me most of it.

Go watch the Monday morning

At The Home Depot, through Pivotal Labs, I paired with two client PMs on the tools 50,000+ supplier employees used to reach their reports, support and 100+ vendor apps. We started with six weeks of Discovery and Framing, and most of that time was spent with suppliers, watching them work.

The persona that came out of it was Alyssa, at a cabinet company in Atlanta. 8am Monday: she's reviewing inventory shortages, chasing fill-rate discrepancies, and prepping holiday promos against last year's numbers. Every one of those tasks started with a login that might not work and a contact list that was probably wrong.

The journey we mapped was painfully consistent. Setup, then business as usual, then something breaks, then the supplier tries to fix it alone (docs, a ticket, a webinar, their merchant), and the issue often stays broken. "People just want a person" was the line I heard over and over.

Here's the part that surprised the client. The vendor experience survey they had been using to judge supplier happiness was old and neglected. It said things were fine. An hour beside one supplier said otherwise.

Scope to the breaks, not the wishlist

Discovery on a mature product surfaces everything. By the end of framing we had eight capability work streams on the wall: support, the portal, reporting, account management, orders, selling more, accounts payable, item management. Every one was real. Rebuilding all of it would have taken years and shipped nothing a supplier could feel.

So we held to the three things blocking suppliers daily. One login across Home Depot's supplier apps, replacing roughly 550 login configurations. A contact directory suppliers could keep current themselves. Content and tools they could actually find. We shipped to the team first, then a test group, then retired the old systems. Authentication and access tickets went down, and Supplier Hub went live.

The other five work streams didn't disappear. They went on a roadmap with evidence attached, which is a very different conversation from "we'll get to it."

Let customer evidence pick the fight

Early this year I led an enhancement inside an existing product: the Asset Library for a public learning platform, via Artium, replacing a legacy Video Library within the platform's established design system.

The planning process had 15+ RICE-scored initiatives, with scores ranging from 175 to 842, and many of them carried 50% confidence. The precision of the scores had outrun the evidence behind them. So I went to the customer record: 15+ recorded customer interviews, synthesized into a per-customer diagnosis. Content scale came out as a structural churn driver, cited in 32% of 2025 churn and at-risk signals, with 429 support tickets in that category.

That settled which problem to fight. It also shaped the launch. Existing beta customers got it first, with a stated goal of 50% adoption in 30 days and a 20% asset reuse target. Every user story carried its own analytics events and performance traces, so the team could see whether the change worked without a separate instrumentation project afterward.

On a mature product, nobody cheers for a new feature. They cheer when the thing that annoys them every Tuesday stops.

Measure where the work happens

NPS and CSAT answer different questions. NPS tells you how someone feels about the company. A satisfaction check right after a task tells you which workflow made them feel that way. On a mature product I lean on the second kind, plus the behavior around it: support tickets per workflow, time to finish the job, how often people fall back to a spreadsheet.

The trap is arguing about which number is the true one. My rule is one primary number per workflow, written down with the reason you chose it, then back to shipping. You can change it later. You can't get the quarter back.

How I run it now

The core hasn't changed since Pivotal, where I learned to pair, test early and ship small. The tools have.

1. Map the service, then the journey. A service blueprint shows the people and systems behind each step, which is usually where the real break lives.
2. Interview to find the break. Watch people do the task, in their own setup. Ask about the last time it went wrong, not what they'd like.
3. Prototype at about 85%. I build working prototypes with Claude Code, real enough that a user can try the actual workflow and engineers can see what to harden.
4. Ship to the people who feel the pain first. A test group, a beta cohort, one division. Then widen.

This is also how I think about adding AI agents to an existing product. An agent that does the data entry nobody wants to do is a gift. An agent that hides the record people need to check is a new workaround waiting to happen. The same discovery applies: find the step people hate, and keep the step they trust.

Teresa Torres frames discovery as a weekly habit rather than a phase in Continuous Discovery Habits, and that's the right shape for a mature product. The users are already there, every day. Go see them.

If you're working on a product like this, I'd love to compare notes on where your breaks are hiding.

Related: Discovery Is Not a Phase, How I Whiteboard Product Interviews Live, Journey Maps That Actually Change Decisions, and Centralized B2B Vendor Portal for Home Depot.

Sources

• Teresa Torres, Continuous Discovery Habits: discovery as a continuous practice