Frontload VS Backload

TL;DR: Decide everything at the beginning than at the end of the dev process to avoid rework and chaos

Imagine being a dev working on the backend APIs without prior discussion with the frontend devs. You would create the APIs needed for a new feature and then share API structure with them. Meanwhile, the front-end devs would write their code first using static data, then using dummy data from APIs, and finally test them with production data. Close to release, you find out that the PM has decided to go down another direction, and you'll need to repeat the whole process.

Missing edge cases is a common theme in such cases. So is changing entire flows to handle them. It's a chaos. This process is backloaded. A lot of critical things happens at the end of the product dev cycle, like documentation, marketing plans etc, and this chaos is the last thing you'd want.

Mistakes at the beginning are easy to correct. So catch them at the beginning. Make your processes front-loaded with most of the items done at the beginning than the end.

After the mistake of backloading as a PM, I have tried to front-load the dev process. Stakeholder alignment happens before we decided to pick up a project. A feature is broken into detailed milestones before we design for a single one. Kick-off with all members of the team (PM + Designers + QA + front end + back end devs) happens before we close implementation details. RFCs are floated early, comments are invited from team members. People escalate their concerns during the beginning and not the end. Questions around the WHY behind a feature are answered while writing the spec and not close to shipping something on Production.

Frontloading has brought more predictability, minimised rework for devs, and more peace for me as a PM.