Engineering Judgement Workshop 🧑‍⚖️

Intro

👨‍💼 Hello, my name is Peter the Product Manager. I'm here to help get you oriented and to give you your assignments for the workshop.
This workshop is about a skill that becomes more valuable as implementation gets easier: engineering judgment.
You'll work on a lightweight scheduling product and practice the part of the job that happens before, around, and after code is written:
  • clarifying ambiguous goals
  • surfacing constraints and assumptions
  • defining success before implementation starts
  • deciding whether a request is worth shipping at all
  • protecting core user experience as the product evolves
  • evaluating whether the implementation actually matched the intent
This is not a workshop about prompt tricks, framework trivia, or shipping the most code the fastest. The point is to build durable judgment that still matters even when AI can generate most of the implementation.

What you'll work through

1. Building an MVP

You'll start with an ambiguous product request and turn it into a focused, shippable MVP. The work is to define what "good enough" means, ask better questions, choose a reasonable starter architecture, and judge the final result against the plan you created.

2. Product Restraint

Next, you'll confront a plausible feature request and slow the team down on purpose. Instead of rushing into implementation, you'll qualify the request, separate evidence from momentum, and decide whether the right move is to ship, narrow, defer, or reject.

3. Protect the User Experience

Finally, you'll evolve the product without losing the experience that made it valuable in the first place. Before implementation, you'll define the user flows and UX invariants that must not degrade, then use those guardrails to evaluate whether the change was actually an improvement.

How to approach the workshop

In each exercise, focus on making your reasoning visible:
  1. Ask clarifying questions.
  2. Write down assumptions, constraints, and success criteria.
  3. Make scope and tradeoffs explicit.
  4. Treat implementation as evidence to inspect, not the only output that matters.
  5. Compare the final system against your original intent and critique the gaps.
A strong result in this workshop is not "I added the most features." It is "I made the right tradeoffs for the information available, and I can explain why."
When you're ready, mark this page complete and start with the first exercise.