Platform investment versus feature delivery: a PM framework for splitting engineering time

How do you weigh shipping a product now against putting time into building a platform? ```hint Make the trade-off concrete Ask what the platform work would let you or other teams ship faster or more safely, and for how many products; that turns an abstract debate into a comparison you can estimate. ``` ### Clarifying Questions - Is the platform an internal foundation that several product teams would build on, such as a shared data model, permissions or a workflow engine, or an external platform for customers and partners to build on? - How many products or teams would use the platform work now, and how many are planned to? - Has a date already been promised to customers on the product side? - Is the lack of a platform causing pain today, such as duplicated work, recurring bugs or slowing delivery, or is it a bet on future needs? ### What a Strong Answer Covers - Criteria for when platform investment pays off and when shipping the product should win - Ways to avoid an all-or-nothing choice, such as building the platform through a real product or reserving a share of capacity - How to quantify the trade-off and present it to leadership and partner teams - Signals that the balance should change, and the risks of leaning too far either way - A concrete example that applies the reasoning ### Follow-up Questions - A large customer has been promised a feature by a near date, but building it properly needs a platform change that will take much longer. What do you do? - A year later, how would you show whether the platform investment paid off? - Engineers ask to rebuild the platform from scratch. How do you evaluate the request?