Problem Discovery Is the Whole Job, Everything Else Is Scheduling
Problem Discovery Is the Whole Job, Everything Else Is Scheduling
My LinkedIn headline says "Problem Discovery, Problem Solving" and people occasionally tell me that's a strange thing to put where a job title goes. It isn't. After nine years moving from business analyst to technical product manager, I've become convinced that discovery is not a phase at the top of the funnel. It's the only part of the job that can't be delegated, automated, or scheduled around.
Enterprise software hides its real problems
When you own products like FlexNet Operations and InstallShield, nobody walks in and describes a problem. They walk in with a solution already attached, usually one that mirrors whatever their last vendor built. "We need a new licensing model." "We need a toggle here." Behind that request is a finance team trying to recognise revenue differently, or an ops team working around a report that never got built.
If you ship the request, you get an adopted feature nobody uses twice. If you find the problem underneath it, you sometimes discover that four unrelated asks are the same ask, and one change serves all of them. That's how the licensing enhancements I've worked on ended up being about subscription and usage-based models rather than the twelve individual toggles that were originally requested.
The roadmap argument is a discovery argument in disguise
Every prioritisation fight I've sat in, and running a multi-year roadmap across Engineering, QA, Support and Sales means sitting in a lot of them, follows the same shape. Sales wants the deal-blocker. Support wants the ticket generator gone. Engineering wants the architectural debt paid. Everyone is arguing about sequence.
They're not, actually. They're arguing because nobody has agreed on what problem the quarter is for. Once that's written down in one sentence that all four functions can repeat back to you, the sequencing debate mostly evaporates. When it doesn't evaporate, that's real signal, it means there are genuinely two problems and you're pretending there's one.
I've stopped treating roadmap disagreement as a negotiation to be won. It's a diagnostic. Persistent disagreement means my problem statement is too vague to be useful.
Discovery is cheap, being wrong is not
The counterargument I hear is that discovery is slow and enterprise timelines don't allow for it. I used to believe that. Then I watched market research at Flexera go from 10 days to 6 hours once we put AI tools properly into the workflow, and three features shipped in two months off the back of it.
Discovery was never the expensive part. Gathering was the expensive part. The thinking was always cheap, we just buried it under weeks of collection. Compress the collection and you're left with the thing that actually needed a human, which is judgment about which problem is worth solving.
What I actually do now
Before anything enters a roadmap, I write the problem in one sentence with no solution language in it, and I check whether I can name the person it hurts and how I'd know it stopped hurting them. If I can't do both, it isn't ready, no matter how urgent it looks or who asked.
It's an unglamorous filter. It has killed more of my own ideas than anyone else's, which is roughly how I know it works.

Ullas skipped presentations and built real AI products.
Ullas D.P was part of the June 2026 cohort at Curious PM, alongside 20 other talented participants.
