yeah the things are moving so fast with AI, or can move so fast with AI, that now anything static may not work. Rules need to be dynamic in nature because the prototyping will become faster. It's not about turning prompts into PRDs, but just providing a framework and a structure or a channel under which the PRDs can operate with well-defined governance.
the governance point is exactly right - and that is where it gets hard in enterprise delivery.
The framework and structure you describe needs to know the domain constraints before it can govern anything usefully and in retail that means pricing rules, inventory behaviour, promotional logic. If those are not encoded into the governance layer before the AI starts prototyping, you get fast iteration inside the wrong boundaries.
Dynamic governance only works mostly if the constraints it operates under were defined correctly in the first place.
Om, I completely agree they are different animals today. That is exactly the point.
In the old world, we aligned humans with a static PRD and hoped the code followed. In 2026, the gap between "what we want" and "what gets built" is closing because the AI lives inside the repo.
The rules are no longer just suggestions. They are technical constraints.
Thank you, glad you found it insightful. For DraftKit, we used it together to draft our changes in seamless manner, message each other and one place multi-collaborators working helped publish this draft without back and forth of sharing google docs and messages in multiple channels. Rest Elena is the creator and can share much more about it :)
I think you've created a beautiful marketing campaign for DraftKit, Dheeraj! I'm honored. It was great to show how much faster we move when we own the logic from the start. Looking forward to the next one!
I love that! A "http://lessons.md" is just owning the failures so they don't happen twice. That's where the actual "muscle memory" of the product lives.
Thank you, Elena, for giving me the opportunity to contribute in this article.
Thanks Dheeraj It was my pleasure! I know this post will help lots of product people out there looking into the Claude Code domain.
This is interesting, but also a bit risky if taken too literally.
turning prompts into PRDs works well when the problem is already clear - you’re compressing the translation layer.
but in most teams, the harder part is figuring out what should be built and why. that still needs messy thinking, context, and debate.
otherwise it risks becoming faster execution on something that wasn’t thought through enough.
yeah the things are moving so fast with AI, or can move so fast with AI, that now anything static may not work. Rules need to be dynamic in nature because the prototyping will become faster. It's not about turning prompts into PRDs, but just providing a framework and a structure or a channel under which the PRDs can operate with well-defined governance.
the governance point is exactly right - and that is where it gets hard in enterprise delivery.
The framework and structure you describe needs to know the domain constraints before it can govern anything usefully and in retail that means pricing rules, inventory behaviour, promotional logic. If those are not encoded into the governance layer before the AI starts prototyping, you get fast iteration inside the wrong boundaries.
Dynamic governance only works mostly if the constraints it operates under were defined correctly in the first place.
Couldn’t agree more with you on this, Om!
Om, I completely agree they are different animals today. That is exactly the point.
In the old world, we aligned humans with a static PRD and hoped the code followed. In 2026, the gap between "what we want" and "what gets built" is closing because the AI lives inside the repo.
The rules are no longer just suggestions. They are technical constraints.
This is fair point Elena - the technical constraint layer closing the gap is real.
My concern is more about what gets encoded into those constraints in the first place.
If the intent was unclear before the AI entered the repo, the rules just enforce the wrong thing faster.
Great way to distill the building process, Elena! Awesome, Dheeraj had that openness to share advice and the struggles from building and delivering.
Plus, I'm really intrigued about trying DraftKit.app to actually draft some internal docs in my team.
Thank you, glad you found it insightful. For DraftKit, we used it together to draft our changes in seamless manner, message each other and one place multi-collaborators working helped publish this draft without back and forth of sharing google docs and messages in multiple channels. Rest Elena is the creator and can share much more about it :)
I think you've created a beautiful marketing campaign for DraftKit, Dheeraj! I'm honored. It was great to show how much faster we move when we own the logic from the start. Looking forward to the next one!
Ha Ha, I jsut shared what I expiernced :)
Glad the process clicked for you, Antonio! Using it for internal docs is a great way to cut the noise. I actually never thought of this use case.
Let me know what you think once you try it. :)
I'll take your CLAUDE.md and raise you a lessons.md. That's where the real magic happens.
Perfect way, just follow the reference pointers to any new files back to claude md
I love that! A "http://lessons.md" is just owning the failures so they don't happen twice. That's where the actual "muscle memory" of the product lives.