Prioritizing Platform and Tech-Debt Work Against the Feature Roadmap

As a product manager, how do you decide how much effort goes to foundational engineering work versus building new features? ```hint Put both on one scale Foundational work rarely shows up in a feature's metrics. Think about how you would express its value so it can compete fairly in the same planning conversation as a launch. ``` ### Clarifying Questions - By foundational work, do you mean tech-debt pay-down, platform and infrastructure projects, reliability and security work, or all of these? - Am I the PM of a customer-facing feature team, or of an internal platform team whose customers are other engineers? - Would you like my general approach, an example of when I made this call, or both? ### What a Strong Answer Covers - A way to express foundational work in terms of customer impact, risk and delivery speed instead of treating it as overhead - A concrete planning mechanism, such as a default capacity split or a single ranked backlog, and the signals that make it shift - Work that is never traded away, such as security, regulatory and urgent reliability fixes at a financial company - How the PM and the engineering lead share the decision and explain it to stakeholders - An example that shows the approach applied and what it changed ### Follow-up Questions - Engineering wants most of next quarter for a rewrite while leadership wants a major launch. How do you resolve it? - How would you show leadership, after the fact, that the foundational investment paid off? - When would you knowingly take on new tech debt to hit a date?