Moving Past "Demos Over Memos": The Future of AI in Enterprise Product Development

I often use the analogy that AI is the equivalent in the workplace of taking the box of 96 crayons, representing the packaging of tasks by role, and throwing the box on the floor. Whatever’s left and how we repackage it are how roles currently look like, or will look like once the instability of AI in the workplace is over.

We’ve already seen a number of approaches with generative AI go by the wayside as models improve, as agents, MCP, and skills are introduced, and as we better understand the impact of AI to our existing talent in our organization.

One of those approaches in particular is(/was?) the notion of demos over memos. In this sense, a product team should focus on building prototypes of the features they want, not 10 page documents describing the feature or market fit. But was killing the document really the intent, or did we go overboard in the other direction?

Downfalls of Relying on AI Prototypes

Vibe coding is winning in many places, and I’m not here to challenge that. I use it all the time in particular for smaller codebases where a model can legitimately understand the overall code concepts and make changes based on my intent.

But in an enterprise setting, where there are realistically millions or billions of lines of code, vibe coding still struggles. The demos to memos approach highlights a few issues in particular:

1. ‘Hallucination’ - In an era where we have to challenge everything and AI models are relatively superior at frontend development already, is a prototype real or not? There is a sense of cognitive overload where even internally users have to question what they see. We’re training ourselves to question AI output (after all, its not really hallucination, its just bad next token prediction), and we added an unnecessary layer of cognitive burden at the workplace with purely frontend vibe demos.

2. Product / feature market fit - While sometimes I find this frustrating, process documentation can act as a gate to keeping bad ideas out, good ideas in waiting, and get great ideas out on the field. Was the goal really to kill the document, or is it to reconsider what’s actually important that we need in order to move fast?

3. Recency bias - Remember that cool thing you just saw? Your feature looks just like it. But is that really what you wanted to accomplish? There’s a time marination factor here that usually yields a better outcome. Not suggesting that we should wait unnecessarily long, but the first action usually isn’t our best outcome.

4. The lack of alignment across true functions within the org - This is probably the biggest one IMO. While a product manager might be able to ‘vibe’ a prototype, it still fundamentally does not reduce the feedback loop cycles or force key groups to work together.

So did demos over memos really solve things here? I’d argue it actually, and unintentionally, highlighted the largest issues engineering and supporting functions have, and accelerated them.

4 Steps to Improve AI Product Cycles (Beyond Demos Over Memos)

If demos over memos accelerated problems that we already had, let’s talk about a few ways teams can start changing behaviors and structure to better leverage AI, and reduce product cycles.

1. Remember that AI is an opportunity to challenge what’s existing. That doesn’t mean you need to throw it all out the window. Documentation and process exist to help drive clarity on decisions, and what actions are being taken. Start from zero to ask yourself what in these is the most useful, and refactor how you’re doing your current work to get back to only what’s most needed in a world where AI can assist with a lot of the actual work and exploration.

2. Get clear about AI usage. It’s fine, and encouraged, to use AI at this point for many places. But be clear about when you’re generating with AI, and label your work where appropriate. This lets people know what to expect.

3. Get anyone associated with your product a local environment. Use AI to get your local environment working if needed. The value of local environments is that, when you make changes, you’re forcing considerations on other subsystems in the application. No more vibe coding a frontend that has no reality in the existing data model.

4. Consider your org. There’s a reason teams are restructuring to move faster. Would an org of 1,000 engineers, organized by function, move faster than teams of 20-50 with clear charters and AI tools? The latter enables accountability at the team level and helps increase velocity. You’ll need to potentially account for different overhead on talent management, but I think that’s a fine trade off for the next few years (organization structures are like pendulums).

5. It was always about the product. The document is the reason why people need or want it. The demo is the support. You need both, use the above to make sure you’re rightsizing how to build and message each.

Just like all the crayons on the floor, we eventually figure out how to put things back together in orders that make sense. The same will happen with organizations, take the learnings from those who’ve shared early in the journey and apply the net gained learning to scale in your job / company.

Happy Wednesday!