Why we all need more Agency in Healthcare
Why companies are turning to prototyping to create the new builder mindset
Max Schoening, who runs product at Notion, recently made a point on Lenny’s podcast that has stuck with me: in the AI era, the thing separating people who thrive from people who fall behind is not skills. It is agency.
Agency, in his framing, is the willingness to find a problem, pick up the tools, and drive something to a result without being told to. It is a disposition, not a credential.
I think this is exactly right. And I think the clearest place you can see what agency does to a product organization is in the collapse of PRD culture and the rise of prototyping.
One thing that became obvious during my time inside a product organization is that most companies are still optimizing for a world where software creation is expensive.
That world is disappearing fast.
A lot of product management today is still built around a model that assumes implementation is the bottleneck: gather requirements, define scope, align stakeholders, create specs, prioritize tickets, hand everything to engineering, then wait months to see if the idea was even correct.
The uncomfortable truth is that most PRDs are not validating anything. They are structured guesses written with high confidence.
They describe a perceived problem, a proposed solution, and a set of assumptions about how users will behave once the thing exists. But until someone can interact with the product directly, most of those assumptions are still theoretical.
Schoening’s other line is that the first ten percent of every project is now essentially free. AI has collapsed the distance between an idea and a running version of that idea. That collapse is what makes requirement-driven development feel anachronistic. You no longer have to spend weeks describing the thing in order to find out whether the thing is worth building.
A functional prototype forces reality into the process much earlier. Instead of debating workflows in meetings, teams react to something tangible. Instead of arguing over interpretation, people see the interaction model directly. Instead of refining documentation for weeks, teams refine the actual experience.
This is where many organizations are struggling.
There is enormous institutional comfort in requirement-driven development because documents create the appearance of certainty. A polished PRD feels safe. It feels measurable. It feels controlled.
Rapid prototyping does the opposite.
It exposes weak thinking immediately.
The second you put a working prototype in front of users or internal stakeholders, vague assumptions collapse:
this workflow is confusing
this feature is unnecessary
this interaction creates friction
this problem was not important enough to solve
this idea sounded smarter in a meeting than in practice
That feedback loop is uncomfortable for organizations built around hierarchy and handoffs. It is also dramatically more efficient than discovering these issues six months into production engineering.
After building more than 15 prototypes inside product organizations and over 25 independent full-stack projects on my own, I have become convinced that prototyping is not just a productivity improvement. It is a different philosophy of building products.
PRD culture optimizes for specification.
Prototyping optimizes for discovery.
That distinction matters more than people realize. A prototype validates not just functionality but usefulness, usability, clarity, trust, workflow fit, and even taste. Those things are incredibly difficult to communicate through requirements documents alone.
Schoening also has a “tiny core” theory of great products. iPhone multitouch. The GitHub pull request. The Notion block. Dropbox’s menu bar icon. Each is a small, powerful primitive that everything else hangs off of. I think this is where prototyping earns its keep beyond speed. PRD culture is structurally bad at finding tiny cores because specification rewards comprehensiveness over reduction. Iteration against real interaction is how you discover which one primitive is actually load-bearing and which twelve features can be cut.
I want to be honest about a tension here, though.
Schoening has another argument that runs counter to the easy techno-optimism: the volume of software has exploded but the quality has not. AI has turned a handful of model providers into something like manufacturers, producing standardized outputs at scale, and bespoke, highly-crafted experiences could become rarer rather than more common.
He pushes against the MVP framing for the same reason. Early experiences carry disproportionate weight. Minimum viable is rarely enough to earn trust or attention.
I think both things are true. The same tools that let a PM ship a working workflow demo in an afternoon also let them ship a confused workflow demo in an afternoon. Agency without taste produces a lot of fast garbage. The differentiator going forward is not who can prototype that is becoming table stakes but who can prototype and tell when the prototype is actually good.
We need more of this in Healthcare.
This is where I think Schoening’s commoditization worry plays out differently in different contexts.
In consumer software, where homogenization is already a problem, he is right to be cautious.
In regulated, workflow-specific domains, the risk runs the other way. The existing software is already homogenized into the lowest-common-denominator shape that big vendors ship. Prototyping in those contexts does not flatten experiences. It is the first plausible path to specificity at all.
Which brings me to what I actually find most interesting about this shift.
The boundaries between product management, design, engineering, analytics, marketing, and even sales are starting to look artificial. Schoening’s own framing for this is the Venn diagram between design, product, and engineering the more overlap in shared vocabulary and materials a team has, the better the team is. AI is just collapsing the diagram.
A product manager using Cursor or Claude Code can now build a functioning workflow demo in hours. Designers are no longer limited to static mockups and can create live interactive experiences directly. Marketing teams can test positioning against real product flows before launch. Sales teams can influence workflows earlier because they can react to prototypes instead of slide decks.
Engineering is no longer forced to spend months translating vague business intent into reality before anyone knows if the workflow is even correct.
Ironically, this does not reduce the importance of engineering. It elevates it.
The role becomes more focused on the genuinely difficult problems: architecture, infrastructure, scalability, security, reliability, observability, governance.
The prototype becomes the pressure test for whether an idea deserves production-grade investment in the first place.
The old model was built around handoffs: PM defines. Design mocks. Engineering builds. QA validates. Marketing launches.
That structure made sense when software iteration was slow and expensive.
AI changes the economics of iteration completely.
The bottleneck is no longer creation. The bottleneck is organizational coordination.
That is why the future is going to move toward small, highly collaborative, agentic workstreams where product builders, designers, engineers, data teams, marketing, security, and AI agents all operate together around a single mission.
Not in sequence. Together.
AI agents will increasingly handle the operational burden: QA validation, stress testing, scenario generation, documentation, infrastructure checks, security scanning, data analysis, regression testing.
That frees humans to focus on judgment, workflow intuition, creativity, taste, and rapid iteration.
The most interesting part is that younger teams entering the workforce already intuitively understand this shift. They do not see rigid distinctions between “product people” and “technical people” the way older organizations do.
A product builder will ask: “Why can’t I prototype this myself?”
An engineer will ask: “Why are we waiting three weeks for requirements refinement when we could test the idea tomorrow?”
A designer will ask: “Why are we still handing static mockups across departments instead of building experiences collaboratively?”
Those questions are not going away.
Once functional software becomes easy to create, the walls between disciplines start collapsing. And most organizations are underestimating how disruptive that collapse is going to be.
The new model increasingly looks like: everyone explores → everyone reacts → everyone iterates
Healthcare vendors are beginning to recognize this shift, which is the part I find most encouraging.
We are already seeing early signs of healthcare platforms becoming extensible AI ecosystems rather than closed software products. Epic’s movement toward agentic workflow ecosystems is one example. Providers experimenting internally with Claude Code and AI-assisted tooling is another. Health systems are realizing they no longer need to wait for massive vendor release cycles to prototype operational improvements themselves.
That changes the power dynamic significantly.
If Schoening is right that agency is the dividing line, healthcare is about to find out which of its institutions actually have any.
That is why I am building in healthcare prototyping.
The mindset has to change. You do not need to spend weeks and months building ivory towers and beautiful paintings. You just need to create something that works and helps solve a problem.
Healthcare is awash with bad experiences: unfinished processes, broken handoffs, no two-way communication between providers and patients, patients treated like widgets instead of customers.
Most of these problems do not need new science. They need someone willing to prototype the thing, put it in front of the people doing the work, and iterate against reality.
Companies that are slow to adopt this mindset are going to be left behind. Not because they will fail to keep up technically — most of them have plenty of technical capacity. They will be left behind because their organizational instinct is still to specify, approve, and hand off, while the rest of the world has moved to explore, react, and iterate.
That is the gap I am betting on.
If any of this resonates, here is where I am putting it into practice and how to engage.
What I am building:
How I am building it. The stack I prototype with day to day: Figma Make, GitHub Copilot, Claude Code, Cowork, OpenAI Codex, Vercel, and OpenCLAW.
What I help organizations with: market analysis, functional PRDs, data model design, analytics and BI architecture, and the move from prototype to production in healthcare contexts.
Where to find me: I will be presenting on this approach at DevDays 2026.
I am also running a free course and light advisory program on using Claude Code for healthcare development and product roles. If that is useful for you or your team, sign up by emailing gene@fhiriq.com.