Most of My PM Job Was Getting People to Agree, Not Deciding What to Build

For most of my career as a project manager and product owner, deciding what to build was rarely the hard part. Getting everyone with a stake in it to actually say yes to it, before a single line of code got written, was the hard part. I'd spend more hours getting a ticket worded precisely right than deciding what should happen in the first place, because the wording was for whoever read it next, not for me, and we needed to end up picturing the same thing.

I only noticed how much of the job was this, agreement rather than decisions, once I built something where there was nobody to agree with. WEREVEN is an app for splitting shared expenses in a group. I took it from a rough Flutter version in February to a published app on Google Play by August, working alone the whole way.

There was no proposal to write, no review round, no "let's align on this before we commit." I decided what the app should do and built it in the same breath. Nobody needed convincing, because nobody but me needed to agree.

What surprised me is how much of my old discipline I kept anyway. WEREVEN went from handling one event to handling many of them, and I did that rewrite in six separate phases: a new data model first, then a database layer, then the state management rebuilt to use it, then the screens wired on top, each one working before I touched the next. No one made me plan it that way. I did it because skipping to the finished result is how you end up debugging five new things at once instead of one.

I still run a checklist before merging anything, even though I'm the only one who will ever read it: tests passing, static analysis clean, docs updated. A pre-commit hook blocks the commit outright if the tests fail or the analyzer complains. I kept all of that, not to prove the work is good to anyone else, but because it's how I catch my own mistakes when nobody else is around to catch them.

What I did drop was everything built to manage someone else's doubt. A status update exists so someone who isn't in the room can see progress is happening. A ticket written defensively, every case spelled out, exists to survive an argument later about what was promised. Alone, there's no one to update and no argument to survive, so neither of those habits had anywhere to attach.

I'm not saying teams should stop checking in with each other. Most teams genuinely need to, and that's a real part of why a team gets anything done at all. But building WEREVEN by myself drew a clearer line than I'd ever seen before, between the habits that exist to get other people to agree with me, and the habits that are just me thinking carefully. Back on a team, I notice the difference now: which meeting is building shared understanding, and which one is just there so nobody has to have an uncomfortable conversation directly.