Every function can prototype now, and it’s changing how teams work together.
Product, design, engineering, marketing. All of them can spin up something that looks polished, functional, almost finished, in a fraction of the time it used to take. Some of it is good enough to put straight in front of users for feedback.
That used to be impossible without engineering time, and engineering was the expensive part. A big part of design’s job was reducing the risk of that investment: testing ideas, mapping flows, making sure whatever got built was worth the cost of building it. Now a working prototype can be cheaper to make than a design mockup, so “design first, build second” doesn’t always hold anymore.
To me, the tools are fine. What’s missing is the language.
We don’t have a shared way to talk about what stage something is in. A prototype can look designed before the actual design process happened. It can look done before anyone asked the first questions. Should we build this? Who’s it for? What problem does it solve?
Skipping those questions doesn’t show up immediately. It shows up later, in confused users, inconsistent experiences, and work that has to get redone because nobody agreed on what “ready” meant.
So here’s where I’ve landed. A few principles for keeping quality intact while everyone moves fast and in parallel:
Teams own the whole thing. Discovery, prototyping, delivery and outcomes. And by team I mean everyone on it: product, design, engineering and product marketing. I work on projects like this, and whole team ownership is super powerful. When PMM is in from discovery, the launch story is already there by the time we ship. This isn’t about adding a central approval layer. Autonomy stays.
Prototypes get labeled by stage. Concept. Exploration. Ready for feedback. User tested. Updated. Ready to build. When everyone can see where something stands, nobody mistakes a polished prototype for something ready to ship.
Customer evidence drives the decision instead of backing it up after the fact. That evidence starts early, with exploration from market research and customer analysis, whether that’s Reddit threads or internal customer feedback tools. Then qualitative and quantitative testing as the prototype takes shape. If the evidence shows up after the direction is locked in, it’s just there to back up a decision that’s already made.
Reviews happen early, while there’s still time to change something. A review at the very end isn’t a review. It’s a verdict.
Every checkpoint has a decision owner and a deadline. The whole team owns the work, and the named decision makers make the call. I’ve seen this go wrong the other way too. The moment you add more review and more evidence gathering without naming who decides and by when, teams stall. Everyone’s gathering more input, running one more test, waiting for one more signal, and nothing ships. Quality checkpoints without an owner and a deadline just become a slower way to avoid deciding.
For me, quality is still a shared responsibility, even when everyone is building in parallel. Faster tools just mean we can’t count on a slow process to catch our mistakes anymore. Judgment, ownership and being willing to take a risk all need to show up earlier. And honestly, I like that. It puts the responsibility back with the team doing the work.
Leave a Reply