Product Owners' new superpower

Product owners understand the business problem better than anyone. They know the users, the constraints, the benefits and the politics. They understand what needs to be built to fix the problem or bring the benefit. But communicating their vision to engineering is not always easy. Slideware is convenient, but can be hard to bring the idea to life. Mock-ups and demos can turn into projects needing engineering resources, sign-off - more politics. Written requirements and user stories can become a barrier rather than a help.

AI is changing that. Not by replacing the people, but by giving product owners a capability they've never had before: the ability to turn an idea into a working, interactive prototype themselves, in an afternoon. Enabling them to bring their ideas to life in a way that's not been possible before.

But is it really as good as it sounds? Well, let me share what I've found when building prototypes with AI. Firstly, the speed of delivery means that I have been able to get immediate, good quality feeback. I've been able to show things that are relatable and realistic which has invoked instant engagement. It was easy to add features to capture and store the feedback within the prototype itself, aligned with the way I would articulate the ask to engineering.

I also discovered that the brief became more specific and less woolly very quickly. There is no better way to reveal that you haven't fully thought something through than when you try to build it. The act of prototyping forces decisions that written requirements miss. When you've built your own prototype, you develop a much more informed and detailed view of the requirements. For example, I started this Solar Panel Pre-sales Assessment app with a basic brief: an outline of the business need and the problem being solved, who the audience was, and the preferred design style. But the initial version then included things that made me immediately question aspects of the design, such as the best way to structure the assessment, how much benefit articulation should be added into the user journey, and other nuances that I hadn't considered in the first brief. Below is the final landing page after a few iterations (style changed to a fictitious company).

Things change when you create something quickly and cheaply. If building a prototype takes a sprint or two using hard-pressed engineering resources, you'll do it once and defend it to the death. If it takes an afternoon, you'll do it three or four times, test each version, and throw away the ones that don't work without batting an eyelid. This puts prototyping into a completely different light.

The tools that make this possible have matured to the point where the only barrier is your visioning and AI prompting skils. A product owner who can clearly describe a user journey, specify who it's for, and articulate what it should look like can produce a working, branded, multi-page HTML prototype using AI, without breaking a sweat.

Another benefit is the ease with which you can reverse engineer the iterated prototype to produce a nice tidy engineering brief, providing tracability and control. You can seed it with context, or add it afterwards. For example you can clarify the data sources, security and access requirements and acceptance criteria. You still need to take responsibility for the content, but AI can give you a great head start.

It may be a step too far for some, but pairing your prototype with a lightweight automation layer such as Make.com or Zapier, enables you to submit realistic data, trigger real workflows, and send real notifications. It stops being a demo and starts being a proof of concept that a user can actually experience.

This is not a marginal improvement on existing prototyping practice, but a step change where the person who understands the problem is also the person who builds the first version of the solution. Where discovery is accelerated and risk of re-work on the final product is greatly reduced.

A complaint we often hear about prototyping is that it raises expectations and puts engineering under pressure to deliver the real product as fast as the prototype. This is a genuine problem and needs to be addressed. This comes down to good comms and relationships. You need to make sure that your stakeholders are bought into the idea that this approach to prototyping is for the purposes of accelerating discovery and avoiding later rework. It eases the demands on engineering teams who need to focus on production ready artefacts, not playing in sandpits! It is NOT the end product. In fact, revealing that you've used AI to produce your prototype could be helpful. Releasing something live that's been developed by ChatGPT or Claude is likely to be perceived as high risk!

Engingeering teams also need to be kept on side and reassured that this is not an attemp to replace a designer's eye. A Product Owner building their own prototype will produce something functional, but it will not always be beautiful or perfectly aligned with branding guidelines. For internal tools, operational products, and early-stage validation, that's fine. For consumer-facing products where visual excellence is part of the value, design expertise is still vital.

Neither does it replace engineering judgement. Security, scalability, accessibility and performance are not things a prototypes addresses, and they shouldn't be. The prototype's job is to validate the what, not to solve the how.

And it doesn't replace the engineering brief. A prototype that gets handed to engineering without documentation of the design decisions behind it is just a different kind of ambiguity. Used well, the prototype becomes the foundation of an engineering brief that captures user journeys, edge cases, data requirements, and the decisions made along the way - all the information needed that engineering can actually build from.

I think they do. Especially if you shift the preconception of what a prototype is. Rather than think of the prototype as the beginning of the development, think of it as the discovery accelerator; the reqiurements tester. Ask yourself: what becomes possible when the person who understands the problem can also create a facimile of the solution - without the risk; without the cost?

That is the real case for AI prototyping. Not the tools. Not the speed. The shift in who gets to shape the product — and how early they get to do it.

Wisereach helps organisations build the capabilities their people need to lead in an AI-first world. If you're interested in running a prototyping masterclass for your product teams, get in touch.

#ProductOwners #ProductDiscovery #AIPrototyping #EmpoweredTeams