Dania / AI · a field lab
AI does the work. The PM's job is judgment.
Everyone's a builder now, and the software is piling up. And the PM's job just got harder: deciding what's worth building, and what good looks like.
AI writes the code, generates the options, runs the analysis. Evaluating a firehose of seemingly sensible options to select for the right ones to push forward. That call is the job now; and the demand for people who can make that call shot up exponentially.
So I spent the last few months testing how to be a more effective product leader by building instead of writing about it. Here are some the concepts I'm learning from the projects I've built to explore them.
Principle 01
Collaborative design with AI needs visual tools.
PMs used to write the problem, the solution, and the assumptions into a PRD. I don't know about you, but I find reading tons of generated text in my favorite LLM exhausting. Instead, I've started replacing that with visual testing grounds you can actually touch.
The first encounter with this was designing Ultramarine, an ASMR paint mixing game that was intended to make realistic colors for oil and acylic painters in the real world. It needed to mix like paint, move like paint, and meet a beautiful standard to appeal to an artistic audience.
You can't co-design a paint simulator through a chat window. I built it on real fluid physics engine bcause paint isn't pixels, it's a non-Newtonian fluid. It moves with the resistance of a gel and mixes like pigment deposits, not light on a screen. Getting that to run on a phone meant building the simulation from scratch.
A model like that lives or dies by its parameters, and you can't tune a parameter you can't see. So I built the harness before I built the app.
AI generated the helper code that staged it. I dragged sliders until the paint read as real, down to that perfect ketchup-y ooze, then had it write the parameter set straight into the app.
The tool below is the actual harness for the gel movement, not a mockup. I loved it, and happily it away and started over when launching the app.
Drag on the canvas to paint; the eleven sliders are the live knobs, non-Newtonian dials included.Shipped (Closed Beta) The WebGL fluid sim used for staging. The app is on Google Play Store.
Principle 02
AI does the work. PMs think.
PM Tutor. Built to find out whether people who already have expertise can learn faster with AI, instead of quietly outsourcing the thinking to it.
"What happens to experienced professionals like architects, engineers and lawyers outsource their thinking to AI? And worse, how does the next generation of professionals build expertise?" These were the questions that led me to explore how to use AI to support active learning.
Most AI tutors optimize for answer fluency. You ask, it explains beautifully, you move on feeling smarter than you are, but I believe strongly in learning that's only integrated through experimentation and failure.
Anthropic's AI-fluency research has a name for that failure: borrowed intelligence. Fluent output that skips the thinking it was supposed to build. The trap gets worse for people who already have judgment to build on. Designers, engineers, architects, PMs; the expertise is exactly what's at risk of going soft.
So I built the tutor on the Claude API, grounded in the National Research Council's How People Learn, Daniel Jackson's concept design, and Anthropic's own interpretability work. For this concept, I used highly available PM concepts for the Body of Knowledge, but it's swappable for any indexed body of knowledge from mathematics to history and everything in between.
A classifier reads every turn and picks a mode: acquisition, practice, self-test, reflect. You talk and it adapts to meet you where you are and guide you in learning.
Ask a definition and it answers. Ask a judgment call and it asks what you'd do first, then holds until you commit. That gate only arms in practice and self-test, which is the whole design: teaching mode shouldn't withhold, testing mode shouldn't hint.
Try it below. The panel on the right is the mechanism, not decoration: the concept it's teaching, what the classifier decided, and whether the sync is open or armed.
Prototype The real engine's logic built with the Claude API for concept testing. UX Design incomplete.
Principle 03
Build systems that put guardrails around "good."
Ovo's design system and its eval pipeline. Every screen, mine or the model's, has a standard to clear before it ships so I can automate away some of the generated slop.
As a PM, it feels pretty great to get closer to building real software, but if a new concept can't fit into the way designers and engineers work, it just generates more low-value work that bogs down the team.
Ovo is a women's health app I designed in Figma. It encourages writing in messy way women actually journal and strutures it to produce meaningful insights for how we work, exercise, eat and relate to ourselves. The goal is to empower women to show up as their best selves with insights that fit their routine.
In designing this app, I intentionally went HAM with a full on test-driven development appraoch. I set up a CI/CD pipeline with standard components and a design system that made sure that as I generated new capabilities with Claude, the resulting output could plug right in.
After designing the Journal input screen and some of the main flows, I used this approach to generate a new onboarding flow, and some custom screens for logging food and fasting protocols.
Below is a screenshot of the design system components, the Journal screen I designed, and the "Your Day" screen that was generated. The design system and evals are why they still feel like one product instead of ten.
Prototype Live Figma design system, code in development (paused) note eval / CI-CD pipeline described was also used to ship Ultramarine (shown above).
Up Next
The next frontier is the physical world.
Empire Lights. A LEGO-scale digital twin I'm using to model everything that breaks on the way from an AI system to a physical object.
The frontier isn't another screen. It's the built world, and the gap between a model and a thing you can touch.
Empire Lights is my new toy. The goal is to map the Empire State Building's real-time lights to change LED lights on my Lego model. I'm mapping the Empire State Building's lighting use the building's website and live cameras and, deciding how tens of thousands of lights map to an addressable set of LEDs without losing the logic of the architecture.
Even though it's a toy, every hard part of taking AI into the real world shows up in it at small scale: approximations standing in for reality, inputs arriving as camera frames and web interfaces and unstructured text, all of it having to drive one real piece of hardware.
It's early days, but it's me moving in the direction I think the market is going, on something small enough to actually finish.
real The working twin: 859 LED indices assigned to labelled sections, and the wiring concept it feeds. in progress the LEGO model is built; the full hardware run is still too expensive to finish.
More experiments
Shipped, shelved, and still in progress. The rest of the lab.
Ovo
Every screen in the system, pulled live from Figma. Capture, food, journal, timeline, insights; the whole flow that turns a brain-dump into something a person can act on.
Ultramarine
Score a mix against a target, then compare your pigment recipe to the real one. The design-system picker and the colour-science architecture doc sit behind it.
Moat Fight + AI Strategy Team
A multi-round simulation of AEC strategy, and a team of named agents I ran against it. The personas didn't help; that was the useful part.
The scanner survived and still feeds a live market board.
Forebuilder
Built to investable and deliberately held there. A real AEC product, a co-founder, a working site.
Knowing something is good and knowing it's the right moment are different calls.
PM Tutor
The running app on the Claude API: detected mode, the typed knowledge base it teaches from, and which pieces you've actually met.
Behind it: an eval harness that tests the teaching by ablation rather than vibes.
Job Search System
Four markdown files with defined relationships: state, lens, dossiers, insights. An information architecture, not a to-do list.
Deliberately simple. The structure is the product; get that right and the rest gets easier.