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.
Questions
kcd.im/aie-2026-qa
Any final questions before we wrap?
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?”
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
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
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:
Small enough to learn before we build the whole car.
Customer context changes the software
Story · Become an Epic Product Engineer · Episode 19
Phone repair truck. Customer’s house. New perspective.
Robert C. Martin
Product engineers bridge code and customer context
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
Measure engineering by product outcomes
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
Good primitives make products easier to build
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. Security updates.
Michael Grinich
Coding agents need a safe playground
Agents are only as useful as the environment, constraints, and feedback loops we give them.
Prepare the environment before delegating to agents
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
Netflix TV UI. No browser. Custom feedback loop.
Ben Ilegbodu
Architecture guardrails prevent agent drift
Story · Become an Epic Product Engineer
Twelve agents. Different patterns. Architecture drifts.
Shaundai Person
Humans own system-level integration
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
Without product insights, you build the wrong size
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
Without product insights, stakeholders hear tech work
Become an Epic Product Engineer · Upcoming
“I think sometimes engineers talk a little too technical of like we need to do this migration... stakeholders say, well, there’s no revenue in that... being able to tell the story as an engineer now is way more important than ever really before.”
Erin Fox
Without product insights, disagreements lose the customer
Become an Epic Product Engineer · Episode 09
“who is this disagreement in service of?”
Alex Hillman
Without product insights, throughput becomes 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
Without product insights, user error can point to design failure
Story · Become an Epic Product Engineer · Episode 06
Three Mile Island operators. Intelligent people. Bad system design.
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
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 vs better questions
Move from opinions about your idea to specific past behavior.
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:
- Workarounds
- Cost
- Frequency
- Existing effort
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.
Better evidence comes from asking and listening
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
Test ideas with real users early
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
User feedback turns shipping into learning
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.
Questions
kcd.im/aie-2026-qa
Any questions before we move to user requests?
Dig past the requested button
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.
BWK: How to build a product users hire: Practical Jobs Theory
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 huge level of complexity...”
Rita Kozlov
Feature requests need product judgment
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
Questions that reveal the job
- Who is this for?
- When does the problem happen?
- What progress do they want?
- What do they do today?
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
Absorb customer signal continuously
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
Design for the user's real-life context
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
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.
Questions
kcd.im/aie-2026-qa
Any questions before we prioritize changes?
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.
Source: the 1984 paper Attractive Quality and Must-Be Quality.
BWK: I hate sprint planning
Kano model demo
Missing basics punish users
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
Do no harm
Questions
kcd.im/aie-2026-qa
Any final questions before we wrap?
Conclusion
Early Idea Validation
The Mom Test
Framing User Requests
Jobs Theory
Prioritizing Changes
Kano Model
