I've been in that roadmap meeting a hundred times. The customer says they need something. The data suggests it matters. Engineering says it will take longer than you thought. You nod, you push back, someone suggests a compromise, and you all leave the room with a plan that everybody knows is missing something.
The problem isn't that people are bad at their jobs. The problem is that product discovery - figuring out what to build - is fundamentally incomplete without two pieces of information that are almost never in the same room.
One: real signals about what customers actually do. Not what they say in interviews. What they actually do, measured.
Two: real understanding of what your codebase can actually deliver. Not estimates. Not general software engineering knowledge. What your specific system can handle, in what timeframe, at what cost.
When you're missing either one, product discovery becomes guesswork. You end up shipping things nobody actually needs, or shipping the right things three months late because you didn't understand the technical reality until you started building.
AI is changing that. Not by replacing product judgment - that's still where the real work happens. But by making both signals visible in a single discovery process.
What Product Discovery Actually Is (And Why Most Teams Skip It)
Let me define what I mean by product discovery. It's not user research. It's not design thinking. It's the process of figuring out: Given our customers, our strategy, and our constraints - what should we actually build next?
That process has three parts. Understanding what customers need (customer reality). Understanding what we can build (technical reality). Understanding what matters to the business (strategic reality). Then synthesizing all three into a decision.
Most teams shortcut this. They gather customer feedback, build a roadmap in a spreadsheet, and hand it to engineering. Then they act surprised when it takes twice as long, or when the customer says "that's not what we needed."
Why does this happen? Because full product discovery is hard. Customer research is time-consuming. Engineering estimates are imprecise. And honestly, most teams don't have a structured process for doing it. You rely on intuition, judgment, and whoever talks loudest in the meeting.
That works when you're small. When your whole company is 20 people and everybody knows everybody else's constraints, discovery happens naturally through conversation.
When you scale, it falls apart. Product and engineering stop talking. Customer signals get lost in Slack. Technical constraints get communicated through estimates that are really just guesses. You end up making strategic decisions about what to build without the information you need.
The Two Gaps That Kill Product Decisions
OK, so most teams skip real discovery. That's already a problem. But there's a deeper issue.
Even when teams do discovery well, they're working with incomplete information. Two kinds of gaps, specifically.
The first gap: customer signal. Your team has a sense of what customers want, but it's usually filtered. You hear from your largest customers in sales calls. You see patterns in support tickets. You might run surveys. But you're missing the long tail. You're missing the customers who are quiet but frustrated. You're missing what people actually do versus what they say they need in interviews.
Tools exist for this. Pendo, Amplitude, Intercom - these are companies that solved the problem of making customer behavior data visible. If you're a modern product team, you're probably using something in this space. The data shows you where people get stuck, what features they actually use, where they drop off. That's customer reality, finally visible.
That's huge. For the first time, you're not guessing what customers need - you're seeing it.
But here's the thing. Even with perfect customer data, you're still missing half the picture.
The second gap: technical reality. When a customer says they need something, or when your data shows they're dropping off at a particular point, you still have to ask - can we actually build this? How long would it take? What would it cost? What would it break?
Right now, you answer those questions by asking an engineer. You get an estimate. The estimate is usually wrong because it's made without full context. You push back. They push back. You end up with a guess.
Or you just accept the estimate and deprioritize work because you assume it's too expensive, without ever testing whether that's actually true.
Or - and this happens a lot - you start building, and halfway through, you hit a constraint that nobody saw coming. Some architectural decision made three years ago means your elegant solution won't work. Now you're redesigning on the fly.
All of this happens because technical reality - what your specific codebase can actually do - is invisible during discovery.
Closing the Customer Signal Gap (Not Glue's Territory)
Let me be honest about what's already being solved and what isn't.
Customer signal: this is increasingly visible. Behavioral analytics tools have made enormous progress. You can see not just what customers say, but what they do. You can identify churn signals before customers leave. You can see exactly where the friction is in your product. You can quantify which features actually matter.
This is genuinely powerful. I've seen teams completely repriorize their roadmap based on behavioral data that contradicted their assumptions about what customers needed. That's customer reality, finally grounded in fact instead of intuition.
The tooling here is good and getting better. If you're not using behavioral analytics to inform discovery, you're doing it the hard way.
But here's where it stops. These tools tell you what's happening with your product. They don't tell you what's happening in your codebase. And they definitely don't tell you what's possible in your codebase when you try to solve the problems the data reveals.
Closing the Technical Reality Gap (This Is Where AI Comes In)
This is where things get interesting. Codebase intelligence - the ability to ask your actual codebase what's feasible - is the missing piece.
When your behavioral data shows that customers are dropping off at the import step, you don't just need to know that. You need to know: why are they dropping off (customer reality). And: what would it actually take to fix it in our system (technical reality).
Right now, you get the first answer from your analytics tool. You get the second answer by talking to an engineer. Those two conversations usually happen in different meetings, with different people, using different language.
With codebase intelligence - tools that actually understand your architecture, your patterns, your constraints - you can have both conversations at the same time. You can ask: "Customers are dropping off when they try to import data with special characters. What's the constraint?" The tool doesn't just tell you an estimate. It tells you: "Your validation logic treats special characters as invalid. That's a design decision made in 2019 to prevent SQL injection. You could relax it by adding prepared statement checks. That's 2-3 days of work. Or you could add a pre-import sanitization step that's simpler but slower - that's 1 day but users will see a processing delay."
Now you have real options. You can talk to the customer about tradeoffs. You can make a strategic decision about whether it's worth relaxing that constraint. You can estimate when it can actually get done.
That's not magic. That's just having the information you need.
What AI-Powered Discovery Looks Like End to End
Let me walk through what a full discovery process looks like when you actually have both signals.
You're a PM at an B2B data company. Your behavioral data shows that customers who integrate via API churn at 2x the rate of customers who use the UI. That's the signal. That's customer reality screaming at you.
You could assume the API is bad. But you're smarter than that. You dig deeper. The churn happens in the first 30 days. You look at support tickets. The same three issues come up: rate limiting that's unclear, error messages that don't tell you what went wrong, and a data validation step that fails silently.
Now you have specific problems to solve. Customer signal is clear: these are the blockers.
Without codebase intelligence: You ask engineering "can we fix the API experience?" They say yes, we can improve error handling and rate limiting. Timeline estimate: four weeks. You cringe at the timeline. You negotiate. You end up planning two weeks of work hoping it's enough. You start building and halfway through find out that your rate limiting is wired into the database layer in a way that makes it hard to expose clearly. Now it's six weeks instead of two.
With codebase intelligence: You ask the tool: "These three issues are blocking API adoption. What's the actual scope to fix them?" The tool reads your codebase. It tells you: "Error handling is decentralized - you're raising errors in 17 different places without a standard format. Fixing that is a refactor, 5 days. Rate limiting is configurable at the API gateway level, so you can expose that in 2 days with clear documentation. Data validation is hardcoded in the model layer - that's the expensive one, 4 days to make it expose errors instead of failing silently."
Suddenly, you have a real plan. 11 days of work for the most impactful fix. You can also see which pieces deliver the most value: maybe error handling is the biggest blocker, so you tackle that first. Or maybe rate limiting is simpler to tackle, so you get that win and buy time for the validation refactor.
You can also see ripple effects. The tool tells you: "Those error handling changes will require updates in three integrations you maintain." Now you know you'll need to coordinate with integrations team.
You can take this plan back to customers and say: "Here's what's wrong, here's exactly what we're fixing, here's the timeline." You're credible because you're specific. You're not guessing.
Then you do the work. It takes 11 days instead of six weeks. The customer sees real improvement. They stay.
That's the difference codebase intelligence makes. You still have to decide whether to build it. You still have to prioritize it against other work. You still have to coordinate with other teams. But you're making those decisions grounded in reality, not hope.
The Future: Agentic Discovery
Here's where it gets weird.
Right now, AI tools help you discover - they make information visible. A PM uses a tool to ask questions about the codebase. An engineer reviews the answers. You all discuss. A decision gets made.
That's an improvement over the status quo. But it's still a human-driven process.
The next step is agentic discovery - where the discovery loop runs partially autonomously. An agent notices that your behavioral data shows a retention issue. It queries your codebase. It identifies the technical root cause. It suggests a fix with accurate scope. It even models the impact: "If we ship this in two weeks, retention could improve by 3 points." Then it surfaces this to the product team for a decision.
You're not asking the questions anymore. The agent is asking them and bringing you the answers.
We're not there yet. But we're close. The pieces - behavioral data, codebase intelligence, cost modeling - are starting to exist. Stitching them together into agentic discovery is the obvious next step.
When that happens, the constraint on product velocity won't be discovery anymore. It'll shift again to execution, or strategy, or market fit. The discovery process will finally be fast enough that it's not the bottleneck.
What to Look for in AI Product Discovery Tools
If you're evaluating tools in this space, here's what actually matters.
First: accuracy grounded in your actual codebase. Any tool can claim to understand your system. What matters is whether it actually does. The best way to test: ask it about your most complex architectural decision. Does it get it right? Or does it confidently give you wrong information?
Wrong information is worse than no information. You'll make decisions based on it and ship broken things.
Second: clarity about what it doesn't know. The best tools tell you when they're guessing. They might say "I'm confident about this, but I'm less sure about this other constraint, you should verify with an engineer."
That's honesty. That's useful.
Third: integration with your actual workflow. The tool doesn't matter if nobody uses it. You need it to fit where discovery actually happens - in roadmap planning meetings, in customer calls, in prioritization discussions. If it requires a separate process, people won't use it.
Fourth: ability to grow with your team. As you scale, your codebase gets messier. Your architectural decisions become less obvious. Your team spreads across more systems. The tool needs to stay useful as complexity increases.
Fifth: transparency about the AI. How is it trained? What model is it using? What's the risk if it hallucinates? This matters because you're making product decisions on top of it. If the AI is a black box, that's a risk.
FAQ
Doesn't this require perfect documentation of your codebase?
No. In fact, it's most useful for codebases that are poorly documented. Clean, well-documented systems are easy to understand anyway - you can just ask an engineer. It's the legacy systems with unclear architecture where codebase intelligence saves you the most time.
Who should use this - product, engineering, or both?
Product. Your job is discovery. If you're grounding discovery in codebase reality, you're using the tool. Engineering gets value from it too - they can see what product is asking for and why. But it's built for product decision-making.
Does this replace conversations with engineering?
No. It changes them. Instead of "how long would this take," you're asking "what are the specific constraints we're hitting here?" Instead of estimates, you're discussing tradeoffs. The conversation gets better because you're starting from the same information.
What if our codebase is a mess?
Then the tool will tell you it's a mess. That's actually valuable data. If the tool can't figure out your architecture, that's a signal that your architecture is unclear. That's a separate problem worth solving. But even for messy systems, codebase intelligence is more useful than guessing.
How much does this speed up discovery?
It depends on your current process. If you're doing deep discovery with real conversations, it might speed things up 30-50%. If you're doing discovery through quick estimates and guesses, it might be 5x faster because you're getting real answers instead of rough estimates.
Can this predict what customers will want?
No. It can tell you what's technically possible. It can't tell you whether customers will love it. That's still your job. What it does is ground your prediction in reality - you're not assuming technical feasibility, you're verifying it. That changes the quality of your prediction, because you're not starting from false assumptions.