For years, I worked on products through requirements, slides, and conversations with designers and engineers. I could explain what I wanted to build. Showing exactly what I meant was harder.
My wireframes were often shapes in PowerPoint or screenshots with annotations. They helped start discussions, but there was a limit to what they could make clear.
- An uncertain idea
- A working example
- Specific feedback
- Clearer requirements
Making an idea tangible
As I started using AI tools, I found that I could turn an idea into something people could interact with. One of my first useful attempts was a workforce-scheduling prototype built over a weekend.
It was imperfect and took a lot of trial and error. But it was functional enough for stakeholders to try and respond to. That changed the kind of conversation we could have.
A different kind of feedback
People began asking whether the prototype could also support a particular situation. Their feedback became more specific because they were responding to an experience they could see and use.
A static document leaves readers to imagine the interaction. Different people may imagine different things while using the same words. A working example gives the discussion a shared reference.
That does not remove the need for requirements. It helps reveal which requirements need more thought.
Build around the uncertainty
My advice is to choose the smallest example that makes the uncertain part tangible. If the question is about how a manager completes a schedule, focus on that interaction. Avoid expanding the prototype until the first question is clearer.
Then watch what people try to do. The point where they hesitate, ask a question, or expect something different is useful material for the next requirements discussion.
- State what the prototype is meant to help you learn.
- Let stakeholders respond to a concrete workflow.
- Record the questions and assumptions that surface.
- Update the requirements alongside the prototype.
Be clear about the stage of the work
At the time of that first build, I was learning to move from an idea to a working prototype. I was not claiming that I had independently delivered a production system.
A prototype can look convincing while still lacking the reliability, integrations, controls, and support needed for real use. Keeping those limits visible makes the feedback more useful and the handover more honest.
Being able to show a working example has changed how I clarify ideas. It gives everyone something concrete to question, improve, and turn into a more considered solution.
Adapted from my LinkedIn reflection on learning to build prototypes with AI. The early prototype described here is distinct from the later delivered scheduling workflow.
Have you worked through something similar?
Let’s compare notes on LinkedIn (opens in a new tab)