- ai · product
AI can build more, but that makes product judgement matter more!
AI can take on much of the implementation, which makes product judgement, technical architecture and understanding the user more central to building something useful.
I’ve been publishing a lot lately: apps, websites, little tools and experiments, and I can imagine someone looking at that and wondering where I find the time. The answer is obvious: I use AI a lot to build them (surprise, surprise). But that doesn’t mean I’m just prompting things into existence and moving on! I care about what I’m building, I take responsibility for the decisions, and I keep learning as I go. That’s what I want to write about here.
The technical side still matters
A lot of the detailed implementation is now delegated to AI, but that doesn’t make the technical side irrelevant to me. I still enjoy working out the architecture: how the pieces fit together, where the boundaries are, and what it takes to make the system work as a whole. My background in software and AI development helps me assess those decisions, even when I don’t know every detail of the language or framework being used.
Product work happens before and around implementation
One thing I’ve believed for a long time, and have defended in many conversations, is that the most valuable work often happens before and around implementation. What problem are we solving? Who is it for? What would make the solution genuinely useful and intuitive? Should this feature use AI at all? Are we simplifying the experience, or just making it less capable? Those questions shape whether we build a product people can use, rather than a technically interesting collection of features.
Business, project management and technology
At Enlitia, I used to have a lot of long conversations about the relationship between business, project management and technology. Business understands the customer, their needs and what success means. Project management understands the pace, expectations, capacity and availability. Technology understands the possibilities and constraints, and how to build the solution. A project works best when those three perspectives keep shaping the work together, rather than passing requirements along in sequence. (More about my time at Enlitia.)
Applying that way of thinking to AI agents
The funny thing is that I’ve naturally started applying a similar way of thinking to working with AI agents: I take the business role (I understand the problem and decide what a good outcome looks like) and work with a project manager agent on a functional plan, including technical context and constraints I already know matter, and that agent then asks a separate technical lead agent to work out how to implement it.
The project manager reviews the technical plan and handles most of the back-and-forth with the technical lead. If there’s a specific question it can’t confidently resolve, it brings it to me. I’ve given it technical context about the project, and my experience in software development helps me answer those questions without having to review every implementation detail myself.
Once the plan is ready, the technical lead can delegate implementation to one or more development agents, then ask separate reviewer agents to inspect the work. Keeping review independent from implementation helps reduce the chance that a reviewer simply accepts the assumptions made by the agent that wrote the code. If something doesn’t line up, the feedback goes back through the team and the agents revise the work. I stay involved in the product decisions and the questions that need my judgement.
This isn’t just about writing better prompts or picking the newest model. It’s about knowing the problem well enough to recognise a useful solution, and having enough technical understanding to guide the system and catch the decisions that matter.
Important disclaimer: building for myself makes understanding the user unusually convenient… building for someone else is a much harder test!
More room to think about the product
I also find myself thinking about things I used to spend less time on, like product-led growth: how a product can help someone reach a useful first moment, come back to it, or share something that might help another person discover it. The shareable recaps in Hoku are one example. Thinking about what makes a product useful to share, and what should stay private, is part of thinking about the product too. I wasn’t thinking much about questions like that when most of my attention was on implementation, but the marketer in me really enjoys them now!
I’m not saying deep technical work has stopped mattering, or that every engineer needs to work exactly like this. But when AI can take on more of the implementation, product judgement becomes a bigger part of building: understanding the problem, choosing what to make, and making sure all the pieces add up to something useful. That’s where I think the work is shifting, and where I want to keep getting better!