Video coming soon
This video is a work in progress and should be out by the end of the month.
Two engineers get the same ticket: "Add CSV export to the reports page."
The first one builds exactly what the ticket says. Clean code, well tested, shipped on time. The ticket moves to done.
The second one asks a question first: who needs this export, and what do they do with the file? It turns out a customer's finance team downloads the report every month, opens it in Excel, and manually fixes the date format before they can use it. The second engineer ships the export with the right date format, and adds a column the finance team was computing by hand. Same ticket, same week of work, but one of them solved the problem.
That difference is the whole course.
What is a product engineer?
A product engineer is still an engineer. They write code, review PRs, and care about quality. The difference is what they consider their job to be done.
- An engineer owns the implementation: the ticket is built as specified, the tests pass, the code is maintainable.
- A product engineer owns the outcome: the user's problem is actually solved, and there's evidence for it.
Owning the outcome doesn't mean becoming a product manager. It means closing the gap between "what was asked" and "what was needed", and that gap exists on almost every ticket you'll ever pick up.
Why this matters for you
There's a practical career argument here.
Being able to build what you're told is still valuable, but it's no longer the differentiator. Frameworks get easier, tooling gets better, and AI can now do a large share of straightforward implementation work: generating components, wiring APIs, writing tests, fixing common bugs, and translating clear specs into code.
What AI does not reliably replace is judgment: knowing what to build, how much of it to build, where the risk is, what tradeoffs matter, and whether the thing actually worked.
Engineers with product judgment get pulled into roadmap conversations instead of receiving their output. They ship features that get used, which is what actually gets noticed at review time. And they're the ones trusted with ambiguous, high-stakes work, because they can be handed a problem instead of a spec.
How this course works
This is not a course you read once. It's eight habits, one per lesson, and every one of them ends with a Practice this week exercise.
If you're currently employed, you'll practice inside your current job, whether you work on a customer-facing product, an internal tool, a platform team, or a service team. The "user" might be an end customer, another engineer, an operations team, or a downstream system that depends on your work.
If you're looking for a job, you'll practice on real products and companies you might want to join. You'll study their users, inspect their product, identify tradeoffs, scope improvements, and write about your thinking in a way you can reuse in interviews, applications, and portfolio pieces.
- Know the user better than the ticket, find out who actually hits your screen and what decision they're making.
- Use your own product, do your users' job with real data, not localhost fixtures.
- Get close to the raw signal, support tickets, customer calls, and usage analytics.
- Scope as a skill, find the smallest version that tests the hypothesis.
- Understand the business model, know what your company charges and what drives churn.
- Write to be read, explain your work in words a non-engineer would understand.
- Push back with evidence, disagree with data, not opinion.
- Close the loop, find out whether anyone used what you shipped.
The lessons are standalone. You can read them in order or jump to the one that stings the most.
But the exercises are where the mindset actually forms. By the end, you should have a few concrete artifacts you can talk through with hiring managers or teammates: a product note, teardown, scoped improvement, user hypothesis, or follow-up analysis.
Let's start with the habit that changes how you read every ticket from now on.
Further reading
Before building this course, we read through how other teams and engineers describe product engineering. You do not need these to take the course, but if you are interested in the broader conversation, these are worth reading: