A panel discussion at The Pragmatic Summit featuring Tuomas Artman (co-founder and CTO of Linear), Michelle Lim (co-founder of Flint), and Drew Hoskins (author of The Product-Minded Engineer) explores what it means to be a product-minded engineer, how to cultivate that mindset on teams, and how AI tools are reshaping the role in 2026.
What is a product engineer?
A product engineer is an engineer who can both define and implement a vision — not just take specs and code them, but also talk to customers, figure out what’s needed, and own the full problem-to-solution arc.
The core distinction is motivational: product-minded engineers care as much about the what and why as the how; code-minded engineers are drawn to technical complexity, libraries, and system elegance for their own sake.
Product-mindedness isn’t limited to user-facing work — even infrastructure or internal tools have “users” (other engineers), and designing good APIs, clear interfaces, and safe abstractions is product work in miniature.
In startups especially, product-minded engineers are more valuable because each person needs to span the full stack from problem definition through shipping and testing.
How people become product-minded engineers
Drew started as a compiler engineer at Microsoft focused on low-level optimizations, but was drawn toward product thinking when he noticed the C# community investing heavily in API usability and developer experience — realizing that developers are users too.
Michelle interned in both front-end and back-end roles but felt unfulfilled by either because she never connected with users; she realized the industry’s front-end/back-end framing was misaligned with her interests, and that “product engineer vs. code engineer” was the more useful distinction.
Tuomas has always gravitated toward visual, user-facing work — from CD-ROM multimedia and Flash animations to mobile and infrastructure — but is motivated by complexity only insofar as it enables a better user experience (e.g., rewriting Linear’s sync engine four times for UX quality).
Taste: definition, importance, and how to develop it
Taste is learnable, not mystical — it’s a craft built from the ability to put yourself in the user’s shoes, selectively forget what you know, and simulate how someone discovers, understands, and uses your product.
Two components of taste: (1) conceptual quality — figuring out what should be built and how best to solve a problem; (2) implementation quality — crafting the user experience around that solution.
Exposure is key — engineers should spend time with diverse products (software, physical products, restaurants, films) to build a sense of what good and bad taste look like; managers should protect time for this.
Customer conversations are essential — talking to customers directly builds empathy that AI summaries cannot replicate.
Interviewing for taste: give design problems with a user component and a novel twist, then evaluate whether the candidate adapts their thinking to the specific user context rather than defaulting to familiar patterns.
Building product engineering muscle on teams
Hire for taste first — it’s contagious; one person who pushes for “magic” instead of incremental improvements raises the bar for everyone (e.g., Flint’s designer, formerly head of design at Netflix, constantly challenges the team to go beyond feature parity).
Quality Wednesdays at Linear — every engineer finds and fixes one small defect (a misaligned highlight, a missing fade animation) each week and presents it to the team; over two years this fixed ~2,500 defects and trained the team to constantly scrutinize the product.
Shared communication mediums — at Stripe, Drew introduced “developer flows” into API review templates, requiring engineers to walk through step-by-step how a developer would use their API; this both aligned teams on user thinking and often helped engineers discover their own design problems.
Use case compendiums — maintaining a living document of north-star user scenarios helps teams evaluate whether their system actually serves real user needs.
Encourage discussion and tool exploration — Flint has a Slack channel for sharing AI product learnings and agentic development techniques, and the company pays for AI tools that help engineers learn.
Give engineers time to care about quality — quality degrades if not actively maintained, and there’s no A/B test for it; engineers want to be proud of their work if given the space.
How AI is changing product engineering workflows
Feedback loops are dramatically shorter — Flint engineers run ~4 Claude Code agents in the background simultaneously; bugs found at 8 a.m. on a sales call can be fixed by 11 a.m. through automated summaries triggering AI agents.
Scaling customer signal — AI can sift through large volumes of customer feedback (emails, call recordings, Slack, GitHub issues) to surface relevant user requests and connect engineers with the right users to talk to, reducing the noise problem that previously made customer interaction overwhelming.
Lowering the cost of experimentation — engineers and designers can now try out complex or uncertain UI ideas in hours rather than weeks; designers at both Linear and Flint are shipping their own PRs (5–6 per week in some cases) using AI coding tools, directly improving UX without waiting for engineering bandwidth.
Product skills augmented by AI — PMs and engineers use Claude skills for competitive analysis, customer signal detection, and other product research tasks that previously required significant manual effort.
Parting advice
Talk to customers directly — AI summarization is useful, but nothing replaces human-to-human empathy; bring engineers on site visits and sales calls.
Align engineers on value metrics, not vanity metrics — move from sign-ups → active users → time spent → meaningful interactions → surveyed value (e.g., “Would your company exist without this product?”); tie these to performance reviews for senior engineers.
Protect time for quality — quality is slow to measure but fast to degrade; engineers will use the time well if given it.
Expose teams broadly — encourage engagement with products outside your domain to build taste and inspiration.
