Field NoteEngineering · Intermediate · 3 min read

The question that started PDLC: why does this feature exist

A field note on losing traceability, and why I built a lifecycle engine instead of shipping faster.

Richa Shah
Share

The question that started PDLC: why does this feature exist

A field note on losing traceability, and why I built a lifecycle engine instead of shipping faster.

I was in a review when someone asked a plain question about a feature we'd already shipped: why does this exist? I couldn't answer it. Nobody in the room could. The feature was real. It was tested, live, working. The reason it existed lived in my memory, or in someone else's, not in the product itself. That gap is why I built a product lifecycle engine instead of just shipping faster.

Context

Before that review, I worked the way most AI-assisted teams default to. Describe what I wanted. Let the model produce it. Ship it. Move on. No stage boundaries. No record of which decision a feature traced back to. Nothing to check a new change against, besides whether it looked reasonable that day.

It worked, in the sense that features shipped. I had a working product. I also had no way to explain most of it six weeks later.

I'd lost traceability. There was no record of which persona, which problem, or which earlier decision a given feature descended from. Two features that quietly contradicted each other could each look fine on their own. The contradiction would only show up months later, in production, when a real user hit both at once.

The pattern

I didn't fix this by writing better prompts. I fixed it by giving the product a shape it had never had. Eight stages, each required to trace back to the one before it. Vision. Personas. The problems those personas have. The journeys they take. The features that follow. The screens. A working prototype. A release manifest that freezes the whole chain.

That structure alone wasn't enough. A check that only looks at the stage directly above it can still let a contradiction three stages back slip through. So every proposed change now gets checked against everything upstream before it's allowed to cascade. It comes back aligned, flagged as a concern, or blocked outright.

I considered skipping all of this and just reviewing changes by eye, the way I always had. It's faster, in the short run. It's also exactly how I lost traceability the first time. The whole point was to stop relying on my own memory, or anyone else's, to hold the reasoning behind a feature.

Building the engine took longer than shipping features ever did. I spent more time deciding what a "problem" record needed to contain than I spent on any single feature that stage produced. That felt slow at the time. It stopped feeling slow the first time a proposal got blocked for contradicting a persona decision I'd made weeks earlier, and had already half-forgotten.

None of the eight stages are complicated on their own. A persona is a short document. A problem is a paragraph, not a specification. What makes the chain worth anything is the requirement that each link points backward, and that nothing skips a link just because writing it felt obvious in the moment. The obvious ones are usually the ones nobody writes down, and the ones nobody writes down are the ones you can't check later.

Generalised lesson

If you can't answer why a feature exists without checking your own memory, you don't have a product. You have a pile of things that shipped.

Build the record before you need it. Not after someone asks the question in a review, in front of everyone, and you realise you don't have an answer.

Richa Shah

Software Engineer II · React.js Frontend Developer

Software Engineer II with 5+ years of experience building web and desktop applications. At FintelligenX, Richa has worked on financial services products and helped build a micro-frontend architecture using Webpack Module Federation. She specialises in React.js, Next.js, TypeScript, reusable component systems, frontend testing, and ElectronJS. She holds AWS Certified Cloud Practitioner, Google Cloud Associate Cloud Engineer, and Claude Certified Architect credentials, and a B.E. in Computer Engineering.

Was this useful?
Share

The Engineering Notebook

Once a month, a long read on what we're learning building governed AI for regulated enterprises. No hot takes, no roundups.

Prefer to talk it through?

Related case studies