Designing a Process That Didn't Depend on an Unreliable Product Owner

On a product I worked on, the client's product owner went on leave mid-roadmap. Someone already on the client's team had to step up and take the reins while they searched for a proper replacement, even without the background the role needed — and we still had a roadmap to deliver.

We were building an internationalization feature where flows, validations, and form fields changed depending on the country a user was signing up from. That kind of feature lives or dies on how well-structured the input is, and structure was exactly what we were not getting. We had an established channel for tracking requirements and linking them to the roadmap in Notion, but this person never adopted it. What we got instead was a steady stream of loose documents, and often those documents were filled in on the spot, during the same weekly call where we needed the information. We would ask for something and get it back incomplete, which meant every piece of scope came with its own round of chasing.

After a few weeks of pushing Notion without any real adoption, we stopped trying to change their behavior and changed our process instead. They were going to keep sending us documents through Drive no matter what we asked for, so we moved our own tracking there. That decision on its own did not fix the quality of the information, but it removed one layer of friction. We were no longer fighting over the tool. We could focus on the actual problem, which was how disorganized and incomplete the content itself was.

I decided the real fix was not a better process document or another round of expectations-setting. It was removing as many decisions from their side as possible. I built a heavily structured Google Sheets framework, with every column, row, grouping, and tab pre-defined for the exact fields the internationalization feature needed, country by country. Instead of asking them to gather and organize information, I asked them to fill in a form that had already done the organizing for them. Their job shrank down to marking yes or no on specific items, flagging whether a piece of copy existed or not, and chasing the right people internally for anything that was still missing.

We shipped the internationalization feature on time, under the same contract terms we had committed to before any of this started. The fix was not training, and it was not a difficult conversation about performance. It was redesigning the interface between them and us until there was very little room left to get it wrong. They still owned the information. We just stopped asking them to also own the structure.

You cannot always fix the person on the other side of a contract, and it is not your job to. What you can control is the surface area for mistakes in the process you share with them. When someone genuinely cannot manage a task the way it was originally designed, the answer is not to explain the process better. It is to change the process until it stops depending on the skill they don't have. That framework was not glamorous engineering, but it was the piece of work that actually let the feature ship.