Platform engineering has a dirty secret that nobody discusses at the architecture whiteboard: the hardest problem isn't building systems, it's deciding what to build. This essay tackles that problem directly, offering a taxonomy of eleven signals that tell a staff engineer where value hides — organized by whether the signal arrives from the system itself, from users, from the org, or from the industry. The framework is more useful than it first appears. The systems-facing signals are the most familiar and the least interesting: crashes, cost centers, toil. The author knows this and says so plainly. The real insight is the explicit warning that crash-led discovery biases teams toward recency and loudness rather than opportunity. The buy-versus-build reframing — treating it as a continuous decision rather than a one-time call — is the kind of observation that sounds obvious only after someone says it. Most teams treat their vendor contracts like geological formations. The user-facing signals are where the essay finds its stride. The overloaded use-case heuristic — treating users who press your platform into unintended service as free prototypers — is genuinely sharp. It has the quality of a good pattern: once named, you see it everywhere. The companion concept, partner-to-prototype, is the deliberate version of the same move. Both share a litmus test the author keeps returning to: who else among your users has this problem? That single question does more filtering work than most prioritization frameworks. The org signals section is appropriately skeptical of its own entries. The manager-repetition heuristic gets the weakest endorsement of any signal in the essay, and the author explains exactly why: proximity to the HiPPO problem. Migration debris is the more original observation — treating laggard teams not as annoyances but as signals that your median solution has coverage gaps. This reframes a common frustration as a discovery mechanism. The industry section contains the essay's most portable idea: lag as arbitrage. The observation that internal platforms follow the same bundling-unbundling cycles as the broader industry, but with a delay, means you can import both the reasoning and the evidence from the industry's convergence without paying to generate it. The failure case — too much delay puts you in the straggler set — is honestly noted. The descriptive-writing-leads-to-prescriptive-writing technique is a practitioner's version of Feynman's 'if you can't explain it, you don't understand it,' applied to system design. The two-axis ranking at the end (argument-readiness vs. leading/lagging) is what elevates this from a listicle to a framework. The author is explicit about why overloaded use-cases sit in the sweet spot: the signal is leading and the argument is already running in production. This is the kind of prioritization logic that's hard to arrive at without having lived through multiple platform cycles. The essay's limitation is that it's addressed entirely to engineers on platform teams with captive internal users. If you're building external-facing platforms with real revenue signals, most of this framework collapses — you already have the market feedback loop this essay is trying to reconstruct from first principles. The writing is clean and confident, occasionally over-structured (eleven signals is a lot of sections), but every section earns its keep.
