Build the Right Thing
Product engineering for software developers
Q&A
Use the QR code for questions
kcd.im/aie-2026-qa
Ask or upvote as we go
The code stays in the corner during the workshop so you can add questions without interrupting the activity flow.
The pain
The code is clean. The tests pass. The ticket is closed.
And none of it matters if we built the wrong thing.
Become an Epic Product Engineer
The right thing comes first
Become an Epic Product Engineer · Episode 02
The right thing before the thing right
Building the thing right is downstream of building the right thing.
Product engineering, not product management
Technical judgment changes the product decision
Product management asks
What outcome matters? Who is it for? Why now?
Product engineering adds
What technical shape makes it viable, learnable, and durable?
We will use product questions, but the work is builder judgment.
Workshop shape
You will work on one real request
- Start with one request from your work
- Reframe it into a first-pass need
- Revise the need with interview evidence
- Translate it into technical shape
- Prioritize it against the rest of the backlog
- Leave with a recommendation and feedback loop
If you do not have a request, use my food delivery example.
Your artifact
The thing you leave with
Each activity fills one part of the Product Engineering Decision Brief.
Reframe before you build
What is this really for?
The request is one proposed solution.
Example
The request
Add group chat to checkout.
Food delivery app.
Sounds reasonable. Still might be the wrong build.
Activity 1
Write your request
Use your real work. Anonymize anything sensitive.
We are being asked to build...
Engineer move: capture the request before you estimate it or prompt an agent.
Reference
Jobs-to-be-Done
Book / framework
Competing Against Luck
Clayton Christensen, Taddy Hall, Karen Dillon, David Duncan
Useful here: people "hire" products to make progress.
Jobs theory
People hire products to make progress
Request
The solution someone is asking for
Job
The underlying need: the progress they are trying to make
Before we decide what to build, we need to understand what the product is being "hired" to do.
Question
What job is this for?
Who?
Specific role, not "users"
When?
The circumstance where pain appears
Progress?
What they are trying to make true
Today?
The workaround they already use
Ask why
Become an Epic Product Engineer
You need to understand what they want it to do, why they want it to do that, and why that's a problem.
You probably won't get to the bottom of the actual issue until three or four layers deep.
Jack Ryan, Principal Engineer at Intercom
Ask why
Run the request through why
- Request: Add group chat to checkout.
- Why do you want this? The lunch plan lives in a messy text thread.
- Why is this a problem? One person has to collect choices, timing, and checkout details.
- Why is that a problem? Orders get missed, checkout stalls, and everyone waits.
Activity 2
Find the job
- Who is this for?
- When does the problem happen?
- What progress do they want?
- What do they do today?
Write this sentence
Draft the job statement
When ___, help ___ do ___ without ___.
This is a first pass. The interview is how you make it less wrong.
Example first pass
The request becomes a rough need
When a group is checking out together, help them coordinate in the app without switching to a text thread.
Engineering clue: this still assumes the solution is moving chat into checkout.
Reference
The Mom Test
Book / interview principle
The Mom Test
Rob Fitzpatrick
Useful here: ask about specifics from the past, not predictions about your idea.
The Mom Test
Ask for behavior, not opinions
Weak
Would you use group chat in checkout?
Better
Walk me through the last time your team ordered lunch together.
Evidence lives in what people already tried, paid for, worked around, or abandoned.
Become an Epic Product Engineer
Talk before implementation
Become an Epic Product Engineer · Episode 16
Know your customer better than your code
Take the first story on your board and talk to three potential users before you implement it.
Pair interview
Test your first draft
- When did this last happen?
- What did you do instead?
- What did it cost you?
- What happens if nothing changes?
Interview output
Revise the job statement
Before
When a group is checking out together, help them coordinate in the app without switching to text.
After
When our team orders lunch together, help us coordinate food and check out once without one person chasing everyone.
Great teams use interviews to change the work before implementation starts.
Example interview notes
Group lunch has a repeat-use problem
Last time?
Friday lunch, right before checkout.
Instead?
A 40-message thread and one person collecting details.
Cost?
Missed orders, stalled checkout, and one annoyed coordinator.
If nothing changes?
They keep using the thread because everyone already knows it.
Example revision
The chat request becomes a job
When our team orders lunch together, help us coordinate food and check out once without one person chasing everyone through a 40-message thread.
Now implementation has a target
The revised job statement changes what we build.
Product engineering lens
The job is not the implementation yet
Product question
What progress does the group need?
Engineering question
What state should the product own?
This is where technical expertise turns discovery into a buildable shape.
Technical shape
Make coordination a group-order session
Shared state
participants, item choices, readiness, deadline
Checkout state
locked cart, payer, submission, confirmation
Failure states
late joiner, abandoned order, unavailable item
Telemetry
started, joined, locked, checked out, reused
Build toward the job
Help the group finish one order
Not "add chat." Help the team coordinate food and check out once.
Question the requested solution
Will chat remove coordination, or just relocate it?
Maybe yes
choices, questions, and checkout stay in one place
Maybe no
the same person still has to chase everyone
Cut scope that misses the job
Do not build generic chat first
- No reactions, threads, or message polish yet
- Start with group-order state and checkout completion
- The job decides the smallest useful version
Bridge to risk
The workaround is painful and familiar
That means shipping chat once is not enough. The question is whether teams choose it again next time.
Risk
What would make this not work?
Activity 3
Name the risk
This might fail if...
We can learn that by...
Look for both adoption risk and technical failure modes.
Example answer
Risk for checkout chat
Adoption risk
teams try it once and go back to their old thread next time.
Technical risk
shared order state breaks when people join late or edit at the same time.
Engineer validation
Learn before building messaging infrastructure
Prototype
shared cart link, readiness, and single checkout
Instrument
started -> joined -> locked -> checked out -> reused
Become an Epic Product Engineer
Demos make ideas testable
Become an Epic Product Engineer · Episode 15
Demos are a product tool
Build just enough to make the problem and possible solution visible, then let feedback tell you whether it is real.
End of Part 1
Thank you.
This is the end of Part 1.
Take five. When we come back: should this feature exist yet?
AI changed the question
Can we build it? Should this exist yet?
Activity 4
Write five backlog issues
Use your product, your team's queue, or the food delivery example.
1.
2.
3.
4.
5.
Food delivery backlog
Five requests in the queue
- 🎁 Surprise discount on next order
- 🎨 Accent theme colors
- 📬 Confirmation email sometimes fails
- 📣 "Share your order!" prompt
- ⏱️ Estimated delivery time accuracy
Activity 5
Prioritize them
Reference
Kano model
Framework
Attractive Quality and Must-Be Quality
Noriaki Kano
Useful here: satisfaction is not linear, and some features should not move up the backlog.
Kano model
Satisfaction is not linear
Example map
Where the food delivery backlog lands
Basic
Confirmation email sometimes fails
Performance
Estimated delivery time accuracy
Delighter
Surprise discount on next order
Indifferent
Accent theme colors
Reverse
"Share your order!" prompt
Activity 6
Check your order
What moved up?
What moved down?
What should not be built?
Decision rule
Fix broken basics before chasing delighters.
Example
GPS changed categories
2015
Delighter
Today
Basic
Your competitor's Delighter can become your Must-be.
Follow-up
What broken Basic competes with this?
If a Basic is broken, the exciting thing can wait.
Activity 7
Check the basics
Before this, we may need to fix...
Ownership
Decide how you will learn after ship.
After ship
Success and failure
Success signal
What should improve?
Failure signal
What might get worse?
Engineering ownership
Build the feedback loop into the system
group_order_started
participants_joined
cart_locked
checkout_completed
group_order_reusedIf the product needs to learn, the system needs events worth trusting.
Signal check
What should improve? What might get worse?
Activity 8
Design post-ship feedback
- What should improve?
- What might get worse?
- What will you inspect after ship?
Final box
The recommendation
I recommend we ___ because ___.
The smallest technical shape is ___.
Before building, we should validate ___ by ___.
The smallest useful version is ___.
We will know it worked if ___.Activity 9
Write your recommendation
I recommend...
Pair share
Say the before and after
- Original request: ___
- Now I recommend: ___
Keep these
Four questions
1
What job is this for?
2
What technical shape does it need?
3
What type of feature is this?
4
How will we know after ship?
Product engineering
What if my recommendation is wrong?
Ask it before implementation.
Resources
Go deeper
- The Last Software Engineer
- Better with Kent: Stop Taking Tickets, Start Applying Jobs Theory
- Better with Kent: How to Prioritize Software Tasks
- Become an Epic Product Engineer Podcast
- EpicProduct.engineer
- Your filled-in decision brief
Thank you!
Build the right thing. Then make it right.