Section 11: The Product Team's Wishlist - Follow-up Feature Evolution

Executive Summary: The interviewer turns from "does it work?" to "can it grow?" and reads seven requests off the product backlog. Each one gets three beats: what changes, what stays, and what it costs in the ledger's own numbers. Most land as a new scope value, a new field, or a new reader of data the pipelines already produce. Four trip a flip trigger named earlier, and two of those (personalization and real-time ranks) change a component's shape. The lesson: a design evolves cleanly when new features read data the system already keeps.

With about ten minutes left, the interviewer slides a sheet across the table.

Interviewer: "Product loved the demo. Here's what they want next. Talk me through what each one costs."

This tests whether your boundaries hold up under change. Answer each request the same way: what changes, what doesn't, the cost in numbers, and which earlier decision it bends. If a request needs a rewrite, say so. Hiding that is the only wrong answer.

The Evolution Map

Sketch where the requests land first. Almost all attach to things that already exist.