u/Intrepid4

I've just completed the corpus on a RAG I'm building for local lawyers, realtors, and contractors who want fast information about every parcel in town without having to go through town hall's antiquated records system. I'm not trying to make a buck - just trying to learn how to make AI more precise in domains where that's important.

The corpus is tiny (only a couple hundred PDFs). I plan to use structure-aware chunking with contextual enrichment. Here are the steps:

• Parse PDF into text
• Detect structure (agenda items, sections, paragraphs)
• Split at natural boundaries
• For each chunk, generate a context summary via Claude
• Prepend context to chunk before embedding
• Store both the enriched chunk (for embedding) and the raw chunk (for citation)

Am I on the right track? Any land mines to watch out for?

I'm watching an org transition from traditional BI to DI in real time, and the early designs are really prescriptive - as if the users are unreliable narrators of their own area of the business. It bugs me and it's got me thinking about how you actually design DI that builds organizational intelligence rather than organizational dependency.The analogy I heard was the paper map and GPS. The paper map is harder to use but enables the user to learn spatial reasoning. The GPS is easier to use, but the user simply follows instructions and learns nothing.

A few questions for people who've been through this:

* Does your UI reward digging and validation, or does it reward accepting the output?

* Is the backend logic transparent - do users know what shortcuts the model is taking?

* Does the tool surface peripheral signals, or does it create blinders around a handful of headline metrics?

* How do you introduce just enough noise or friction to trigger human discovery without overwhelming people?

* Does the system disclose what it doesn't know -- or does it present its model as complete?

Genuinely curious whether there are design patterns that get this right, or whether prescriptive DI is just the current era's version of "the dashboard will save us.”

It's the most common question I see from builders who've never worked with a PM -- they've made something and they genuinely don't know what they have. Is it a feature? A business? A hobby project with delusions of grandeur?

I've been thinking about this a lot lately. The canonical literature - Christensen, Blank, Fitzpatrick, Perri, Cagan - gives us the frameworks, but none of it was written for someone who just pushed to Vercel at 11pm and is wondering if they accidentally built something real.

What do you actually tell these people? And is there a sequence that works -- problem legitimacy before customer specificity before WTP - or do you find yourself jumping around based on what they give you?

Genuinely curious how experienced PMs handle this conversation.

Is anyone using an agent to accelerate product discovery?

I'm a data product manager trying to make sure that product discovery keeps pace in this rush to vibe code solutions before truly understanding the problem.
To do this, I'm working on a 'Decision Discovery Agent' that engages with internal data/report users in a 5-7 minute chat to essentially answer five questions in the course of their NL conversation: Who uses this data? What decisions are made with this data? What decision are you not able to make or cause you anxiety using this data today? What is the value to the business of making the right decisions with this data? What happens if this data is wrong or late?
The agent will process the responses and provide me (the product manager) with a full analysis and signposting for where human engagement is critical.
My hope is this will save me time sending emails, user surveys, and scheduling endless meetings just to define the problem that needs solving. To be clear, this is not meant to replace product discovery, but to make me more efficient.
What do you think? Anyone have experience with agentizing aspects of the product discovery process?