Become an Epic Product Engineer

Kent talks with Michael Shimeles - Rasmic - about building products in the AI era without losing the engineering judgment that makes software useful.They cover AI consulting, why clients often ask for the wrong thing, how to push conversations back to the real problem, why simplicity is a product advantage, and why developers are more valuable when they combine technical skill with taste, domain knowledge, and user empathy.(00:00) - Meet Michael Shimeles (01:16) - Product studios and AI consulting (04:35) - Training teams and building custom agents (07:37) - Uncovering the real problem (12:33) - Questions that cut through AI hype (16:47) - Do it the hard way first (19:01) - Finding ideas in products you use (21:03) - Taste, quality, and care (24:10) - Simplicity beyond design (28:04) - Domain knowledge and feedback (31:11) - Developers are expected to own more (35:35) - Do not fall in love with the solution (39:14) - Homework: read an old engineering book Michael Shimeles is a full-stack engineer, DevX engineer at Convex, creator, and the person behind a product studio and AI consultancy. In this conversation, he and Kent talk about what happens when every company suddenly wants agents, automation, and custom AI tools - and why the right answer is sometimes "you do not need AI yet."A major thread in the episode is problem discovery. Michael describes clients who come in excited about subagents, custom harnesses, or the newest tool from a YouTube video, while the real job is to slow down, ask what problem they are trying to solve, and decide whether a simple workflow, an off-the-shelf tool, or a custom product is actually warranted. Kent connects that to The Mom Test and the value of doing things the hard way first so you know where existing solutions fall short.They also dig into taste and simplicity. Michael argues that AI has made it easier to ship software, but not easier to care. Taste comes from shipping, noticing products you wish you had made, learning from feedback, and making the path from a user's problem to a solved problem as short as possible. The episode closes with a practical challenge for engineers using agents: go back to the old engineering books. Syntax is cheaper now, but engineering, architecture, first-principles thinking, and simplicity make you better at directing AI.HomeworkPick one classic engineering book you have ignored or dismissed and read it with AI-assisted development in mind.Notice how the engineering principles from that book change the way you prompt, review, and steer coding agents.Treat agents as code-writing accelerators, not replacements for architecture, simplicity, and first-principles thinking.ResourcesRas Mic - Michael ShimelesConvexFabrikaThe Mom TestClean CodeGuest: Michael ShimelesCompany: ConvexGitHub: @michaelshimeles𝕏: @rasmicHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer

Kent talks with Lucas Wargha, engineering manager at FamilySearch, about turning software engineers into product engineers: understanding mission and business outcomes, talking to real users across cultures, and stopping the assembly line of JIRA handoffs.They cover customer personas at global scale, the Gmail password-loading story as product-engineering thinking, owning epics end-to-end, creators vs consumers, and a hopeful take on historic days in our industry.(00:00) - Introduction to Product Engineering (02:12) - FamilySearch and product outcomes (07:36) - Customer personas at global scale (12:07) - Know your customer better than your code (15:01) - Product engineer vs product manager (17:33) - Turning engineers into product engineers (22:38) - The Gmail password-loading story (27:01) - Stopping the JIRA assembly line (31:19) - Prioritizing customer needs (42:28) - Homework: talk to three users Lucas leads engineers building FamilySearch Memories - tools for photos, audio, and stories that help people connect with family beyond names and dates. He describes a shift away from engineers as expensive task-takers toward people who understand company vision, product outcomes, and why a rewrite or maintenance project is worth doing.A thread through the episode is customer literacy: mapping personas, interviewing users in Brazil and discovering translation nuances you would never see in analytics alone, and balancing qualitative insight with data when the customer base is literally global. Lucas and Kent compare product engineers and product managers, why role sprawl happened, and what changes when engineers own milestones across web and mobile instead of finishing isolated stories.They also talk about practical culture moves - engineers delivering food like DoorDash did, using your own product, the Gmail team preloading after you type your email, and why fulfillment comes from creating value for people rather than optimizing reducers. Lucas closes with homework grounded in his motto: know your customer better than your code, and talk to three users before you implement your next story.HomeworkKnow your customer better than you know your code - measure whether you get as passionate about product outcomes as you do about architecture debates.Take the first story on your board (or next assigned work) and talk to three different potential users across personas before you implement it.Resist finishing the story in isolation - what you learn from those conversations should change what you build.ResourcesFamilySearchLucas Wargha (site)Competing Against Luck (Jobs to Be Done)UtahJSGuest: Lucas WarghaCompany: FamilySearchGitHub: @lucaswargha𝕏: @lucaswarghaHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer

Kent talks with Ruben Casas about building products again in the AI-agent era: why experienced engineers can now stay close to customers and code, how demos turn vague ideas into something people can react to, and why product judgment matters more as implementation gets cheaper.They cover Postman, MCP, agent-driven UI, prototypes, early user feedback, feature product-market fit, and the engineering guardrails that help teams ship quickly without turning the product into a pile of disconnected features.(00:00) - Introduction to Product Engineering (00:48) - Ruben Casas and Postman (07:36) - Building products again in the AI era (19:38) - Finding customer pain points (22:32) - Demos and prototypes (28:53) - Getting people to care about your ideas (31:41) - Prioritizing product problems (41:25) - Homework: build a prototype demo Ruben brings a practical perspective from building developer tooling, platform work, and AI-agent products at Postman. The conversation starts with a shift many experienced engineers are feeling right now: agents make it possible to stay involved in higher-level product decisions while also getting hands-on with implementation again. That is exciting, but it also raises the bar for deciding what is worth building in the first place.A recurring theme in the episode is that demos and prototypes are not just engineering exercises. They are product tools. Ruben and Kent talk about starting from a real pain point, building just enough to show the opportunity, putting it in front of users quickly, and using that feedback to decide whether the idea deserves more investment. They also dig into the risk of shipping too many mildly useful features, and why product engineers still need architecture, testing, taste, and guardrails as more people use AI to touch production code.HomeworkFind a real problem that is bothering you.Use an agent to build a quick prototype for it, especially if you have not tried AI coding tools seriously yet.Record a short demo, send it to someone, and ask for feedback.ResourcesRuben CasasPostmanRethinking UI in Agent-Driven SystemsMCP AppsGuest: Ruben CasasCompany: PostmanGitHub: @infoxicator𝕏: @infoxicadorHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer