Slido
Help choose the example app
Submit ideas for the example app
We’ll use this for Q&A too. Add questions or upvote them as we go.
AI changes the scarce resource
Less scarce
Implementation gets cheaper, faster, and more widely available.
More valuable
Deciding whether the work is worth building in the first place.
“Can we build it?”
“Is it worth building?”
Product engineers understand which targets are worth hitting
AI agents make more targets reachable.
Product engineers decide which ones deserve the effort.
When building gets cheap, ideas matter more
Become an Epic Product Engineer
“It’s once development becomes cheap and easy and enables anybody to be able to do it, especially non-technical people, then it’s really about the ideas that you have.”
Ben Ilegbodu
Worth having is the hard question
Become an Epic Product Engineer · Episode 08
“deciding whether a feature is worth having or what the long-term consequences are.”
Julius Marminge
The danger is confidently building the wrong thing
Looks done
The code is clean. The tests pass. The ticket is closed.
Still failed
Finished implementation can still produce no customer value.
Shipping the wrong thing faster is still the wrong thing.
The right thing comes before the thing right
Become an Epic Product Engineer · Episode 02
“The product concern is building the right thing and the engineering concern seems to be building the thing right... building the thing right is downstream of building the right thing.”
Wayne Allan
Agents make the wrong work faster too
Become an Epic Product Engineer · Episode 01
“The default place for our new coding agent abilities to go to is to work on the wrong things. Products going from good to bad faster than ever.”
Dax Raad
Bad practices move faster now
Become an Epic Product Engineer
“It’s accelerated everything, all of the bad practices. And it’s given us the tools that we need to move bad faster.”
Shaundai Person
Real-looking prototypes can lie
Become an Epic Product Engineer
“it’s very easy for it to look and feel real very quickly... Why can’t I just ship this, right?”
Rita Kozlov
Surface-level function is not enough
Become an Epic Product Engineer
“you can build something that you know at the surface level seems functional. But is not actually scalable or doesn’t address any of the edge cases that a user is going to encounter.”
Rita Kozlov
False progress feels productive
Become an Epic Product Engineer · Episode 04
“You can do the wrong thing incredibly fast and feel like you’re making a ton of progress... how do I do the right thing incredibly fast or at least directionally correct rather than do 10,000 lines of code a day on the wrong freaking thing.”
Aaron D. Francis
Product engineers connect customer understanding to technical choices
The technical choices matter:
Get in the truck
Story · Become an Epic Product Engineer · Episode 19
Customer context changes the software
Phone repair truck. Customer context changes the software.
Robert C. Martin
Half technology, half customer
Become an Epic Product Engineer · Episode 19
“A product engineer lives half in the technology and half in the customer’s house... There’s this deeply human side to product engineering.”
Robert C. Martin
Engineering judgment comes from technical experience
Become an Epic Product Engineer · Episode 13
“What’s different for me about a software engineer is that we have judgment... knowledge of computer science. ... knowledge of algorithms and architecture and the human issues.”
Grady Booch
The goal is not the API
Become an Epic Product Engineer
“The end goal is not I built an API that just... did what we agreed on doing. The goal is to go and launch a product that is successful, secure, scale well, and performs well in the end for the end user.”
Ronan Berder
The engineering shape is part of the product decision
The same product request can imply very different technical commitments.
Architecture is where change gets expensive
Become an Epic Product Engineer · Episode 13
“All architecture is design, but not all design is architecture. Architecture represents the set of significant design decisions... where significant is measured by cost of change.”
Grady Booch
Find the right primitives
Become an Epic Product Engineer · Episode 10
“If you don’t have the right primitives, it becomes so much harder to build your products... Find the right primitives and build a great product out of that.”
Rhys Sullivan
Distribution is a product decision
Story · Become an Epic Product Engineer
WorkOS cloud API
Fast fixes and security updates changed the right distribution model.
Michael Grinich
Coding agents need a safe playground
Agents are only as useful as the environment, constraints, and feedback loops we give them.
LLMs need a prepared environment
Become an Epic Product Engineer · Episode 15
“Someone behind the scenes needs to create the right environment for LLMs to be productive and to be safe... boundary, good products and platform architecture and taste and safeguards and testing.”
Ruben Casas
Agents need to see the product
Story · Become an Epic Product Engineer
TV UI
No browser loop. Build agent visibility into the product environment.
Ben Ilegbodu
Twelve agents can create twelve patterns
Story · Become an Epic Product Engineer
Architecture drifts
Twelve agents. Different patterns. Architecture drifts.
Shaundai Person
Systems engineering is still human
Become an Epic Product Engineer · Episode 19
“You can’t tell the agent to make you a massive airport control system... You would have to tie them all together. So the systems engineering is still completely human.”
Robert C. Martin
You overbuild or underbuild in the wrong places
Become an Epic Product Engineer · Episode 04
“We can’t blame the user for having a bad solution. They know nothing about the architecture underneath, but if we can find out what they’re trying to do, we might find a nice neat home in the existing architecture...”
Aaron D. Francis
You lose stakeholders
Story · Become an Epic Product Engineer
Technical work still needs a product story
Migration framed as tech work. Stakeholders drift.
Erin Fox
Who is this disagreement in service of?
Become an Epic Product Engineer · Episode 09
“who is this disagreement in service of?”
Alex Hillman
You lose users because of unintentional feature bloat
Become an Epic Product Engineer
“If we’re able to deliver three times better, do our users actually want three times more features?”
Ben Ilegbodu
You design the wrong thing but blame the user
Story · Become an Epic Product Engineer · Episode 06
Three Mile Island was a design failure
Smart operators. Bad system design. Don’t blame users.
Don Norman
Workshop outline
You are going to leave with frameworks for making engineering decisions for your own product.
Early idea validation
The Mom Test
Framing user requests
Jobs Theory
Prioritizing software changes
Kano Model
So, what’s the idea we’re going with?
Questions
kcd.im/aie-2026-qa
Before we get into it, let’s look at your questions
Activity: audience brainstorm
Give me some questions you’d ask people to validate [example app].
Framework 1
The Mom Test
Rob Fitzpatrick
Don’t ask users to evaluate your idea or diagnose the problem for you.
Weak
“Would you use this?”
“Is this a problem?”
“What is the problem?”
Better
“Tell me about the last time this happened.”
“What did you do instead?”
“What did it cost?”
Symptoms are not the problem
Become an Epic Product Engineer · Episode 06
“Don’t ask somebody what’s the problem, because they’ll tell you the symptoms.”
Don Norman
Ask about specific past behavior
- Tell me about the last time this happened.
- What happened?
- Who was involved?
- What made it annoying enough to remember?
Ask what they do today instead
Look for:
Ask what they already tried or paid for
Stronger evidence
Existing effort is stronger evidence than stated interest.
Weak pain
If they have never tried to solve it, the pain may not be strong enough yet.
Talk, ask, listen
Become an Epic Product Engineer · Episode 02
“Talk to people, ask good questions, and listen.”
Wayne Allan
Find the cost of inaction
Become an Epic Product Engineer
“what were you losing out by not having it? Like what was the cost by not doing this?”
Michael Grinich
Output: interview evidence, not validation theater
A good interview should change the shape of the idea.
An idea that skipped validation
Story · Become an Epic Product Engineer · Episode 02
Built for all of Australia
Nobody came.
Wayne Allan
Test the market before the full build
Become an Epic Product Engineer · Episode 02
“We probably could have launched something in two weeks and done the integration manually... We could have tested the market and learnt a lot of things very, very quickly and not invested a whole team.”
Wayne Allan
Show it to people
Become an Epic Product Engineer
“It’s very easy to convince yourself that something is a good idea, just sitting in your room by yourself hacking on it for weeks and weeks and weeks... So you need to show it to people.”
Michael Grinich
Close the loop with users
Become an Epic Product Engineer · Episode 15
“The user feedback is what closes the loop... the quicker you get it to your users, the quicker they know, yes, this solves my problem, or this is not worth pursuing.”
Ruben Casas
Why product engineers need The Mom Test
Translation
PMs may own discovery, but engineers own translation into system shape.
Appropriate architecture
Past behavior tells engineers which architecture is appropriate.
Without that context, engineers may faithfully build the wrong abstraction.
Keep asking why
Become an Epic Product Engineer · Episode 11
“The number one thing is to figure out why... You need to understand what they want [the button] to do... and then they need to tell you why they want it to do that... until three or four layers deep...”
Jack Ryan
Framework 2
Jobs to Be Done
Clayton Christensen et al.
People “hire” products to help them make progress in a specific situation.
Jobs Theory source: Competing Against Luck for the hire/progress framing.
The request is not the job
Original request: [example request].
Become an Epic Product Engineer
“People will say, you guys should build this feature. And then you ask them... what are you trying to solve? ... if you do say yes to every one of these features, you do end up with a level of complexity...”
Rita Kozlov
Don’t nail requests onto the product
Become an Epic Product Engineer · Episode 11
“We don’t just take feature requests and nail them onto the thing that we’ve already got. It won’t be a good product. There’s loads of judgment that takes place there.”
Jack Ryan
Situation creates the job
Not
users want X
But
When I’m in situation Y, help me make progress Z without W.
Write the job statement
When [situation], help me [make progress], so I can [desired outcome].
Activity: write one job statement for [example request] (or the request on your own product).
Break the job into three dimensions
Functional
What progress are they trying to make?
Social
How does this affect how they are seen by others?
Emotional
How do they need to feel?
Upcoming BWK episode: How to make your thing win like React won
Let customer signal wash over you
Become an Epic Product Engineer · Episode 11
“We have Slack channels which just feed in feedback from sales calls... all of that is really useful context that you can kind of let it wash over you.”
Jack Ryan
Situate the product in a life
Become an Epic Product Engineer
“There’s something very important in thinking about the storytelling of the thing you’re building, how it situates in someone’s life.”
Michael Grinich
Translate the job into system shape
Functional
State, workflow, integration, success signal
Social
Visibility, permission, ownership, approval, history
Emotional
Preview, undo, confirmation, explanation, recovery
Production means accountability
Become an Epic Product Engineer
“if you’re gonna be committing code to production, you’re then accountable for that code and... need to really own it and fully understand... the end to end architecture...”
Rita Kozlov
Define success by repeated progress
Forces you to answer:
- How do we measure progress?
- Do they do this more than once?
- What should we build, change, instrument, defer, or not build?
- What does [example request] become after we understand the job?
Why product engineers need Jobs Theory
- The job gives engineers language for system-shape questions.
- Functional, social, and emotional progress point to different product and architecture needs.
- Without the job, we can build the requested feature while missing the system users actually need.
Not all features create value the same way
Become an Epic Product Engineer · Episode 02
“[Bun] had all these other ideas, which were really exciting, but they kind of missed some foundational ideas. And so there’s actually a mental model for this. It’s called the Kano model.”
Wayne Allan
Framework 3
Kano model
Noriaki Kano
Not all features create value the same way.
Original source: the 1984 paper Attractive Quality and Must-Be Quality.
Published BWK episode: How to Prioritize Software Tasks
Basics do not delight when present, but they punish you when missing
Become an Epic Product Engineer · Episode 02
“If there’s no toilet paper at my hotel, that’s a bad experience. But if I have 100 rolls of toilet paper, it doesn’t increase my good experience of a hotel.”
Wayne Allan
Fix foundations before chasing delighters
Become an Epic Product Engineer · Episode 03
“You can’t waste your time on doing delightful stuff before getting the foundations right... Focus on foundations and primitives. Make sure you have good feedback systems...”
Dillon Mulroy
Why product engineers need the Kano Model
PMs and product partners help identify value. Engineers decide the reliability, reversibility, permanence, and technical commitment that value deserves.
Basics
Reliability, completeness, durable ownership
Performance
Measurable quality gradients
Delighters
Reversibility and low architectural commitment
Indifferent
Do not make permanent product surface area
Reverse
Avoid turning user harm into architecture
Recommendation frame
- The target worth hitting is ___ because ___.
- The smallest technical shape is ___.
- Before building, we should validate ___ by ___.
- The smallest useful version is ___.
- We will know it worked if ___.
Conclusion
Early Idea Validation
The Mom Test
Framing User Requests
Jobs Theory
Prioritizing Software Changes
Kano Model
