The Product Context Doc

Table of Contents

I’ve been using LLMs to help me think better about product decisions for a while now. Along the way, I’ve settled into a workflow that’s helped me gain clarity before (and while) building features.

I keep a short doc that captures the core context of what I’m building. I call it a Product Context Doc. The surprising part is that writing it turned out to be more valuable than what I use it for afterward. This post is my notes on the structure I’ve settled on and how I use it.

Here’s the core idea: if you can’t explain your entire product and your feature in a single text paragraph, you don’t fully understand it yourself. The doc is just a forcing function for closing that gap.

# The Four Layers

Let’s look at the structure. I’ve settled on four layers that cover the right ground. “Doc” is a bit generous, honestly. If your thinking is clear, this won’t be more than a few paragraphs.

# The Product Layer (what exists and why)

  • What the product does, in plain language (describe it like you’re explaining to a smart friend who doesn’t work in your industry)
  • The core belief that makes this product worth building
  • What exists today vs. what’s planned
  • How do people solve this problem today without your feature, and why is that painful

# The People Layer (who cares and why)

  • Your 2-3 primary personas. Real descriptions of real people with real problems.
  • What their day looks like, what they care about, what frustrates them

# The Feature Layer (what you’re building right now)

  • Which persona does this serve most directly
  • What workflow does this slot into
  • What’s the smallest version that still makes a real difference

# The Needle Layer (what changes in someone’s life)

  • What metric in their life improves
  • What becomes possible that wasn’t before
  • What’s the emotional shift (do they feel less anxious? more in control? less wasteful with their time?)

Some of these might sound like obvious questions. I get that. But just putting the answers down in words makes for excellent context when you paste it into an LLM and you’re facing a decision, trying to mine insights on which way to go.

# Using It With an LLM

Once you have this written down, let’s talk about where it gets useful.

Copy-paste the full context into an LLM conversation, and use it as a starting point for:

  • Finding prior art: “Who has had this problem before, and how did they solve it?” This surfaces solutions from products you’d never think to look at.
  • Connecting to real metrics: “What is the actual metric this person’s success is measured by, and how does my feature connect to that?”
  • Discovering use cases: “Who would benefit from this feature right now, today? What does their workflow look like?” This helps you find concrete use cases you hadn’t thought of, and then you can simulate those users to actually test your product.
  • Pressure-testing your understanding: If the LLM’s response surprises you, that’s a signal. It means your mental model has gaps you didn’t know about.

The key thing is that the quality of these conversations scales directly with how good your context doc is. A vague doc gets you vague answers. A crisp one gets you responses that actually challenge your thinking in useful ways.

The doc isn’t precious, either. I rewrite it as I learn more. Sometimes the biggest insight is realizing that a layer I thought was solid is actually vague.

# Why Bother

Writing this doc takes maybe 20 minutes. Sometimes less. But it forces me to confront the parts of my understanding that are fuzzy. If I can’t fill in a layer, that tells me exactly where I need to dig deeper before building anything.

This has helped me gain clarity and get deeper insights into what I’m building. That clarity compounds into smarter micro-decisions along the way, and those micro-decisions accumulate into something that feels magical to use. It also helps me prioritize. When you have 10 things competing for attention, this kind of clarity makes it obvious what to do now, what to postpone, and what to just not do at all (the less you do, the better).

That’s it for this one. If you try this out, I’d love to hear how it goes. Thanks for reading, see you in the next one!

Raj Rajhans

Raj Rajhans

I'm a product engineer who loves Elixir and the JavaScript ecosystem. I write here to make sense of what I'm learning — it helps me think more clearly.