FareHarbor wasn't a startup finding its footing. By April 2019, when I joined as the company's first external Product Owner/PM hire — my first-ever role in product — it already had customers, revenue, and three years of an established operating model. That model was three US-based technical cofounders running the company from San Francisco, alongside a small engineering team split across SFO and a growing Amsterdam office. Their habit — build a feature in its entirety, then ship it — worked fine with three or four engineers in one room. It didn't scale as Amsterdam grew, and there was no formal product function to bridge the gap: no refinement process, no prioritisation discipline, and every merge request, regardless of where it came from, needed a cofounder's personal sign-off.
My mandate was to scope and deliver three flagship international-expansion projects with FareHarbor's growing Amsterdam engineering team: the company's first e-invoicing integration, for market fit in Italy and Portugal; its first Android app; and iDEAL/Sofort integration, for the Netherlands and Germany.
Phase 1 — the basics.
Denis Barzakovsky, Amsterdam's sole Engineering Manager, and I introduced FareHarbor's first formal scoping and refinement process — standard scrum, epics broken into stories, delivered in sprints. Neither of us was reinventing anything. What mattered was that none of it existed yet, and the cofounders' habit of building whole features solo had never needed to scale past a handful of people.
Phase 2 — the collision.
Amsterdam's engineers wanted to work in small pull requests behind feature flags. The cofounders had never worked that way, and expected features built whole on a single branch — with every merge request, regardless of size, still requiring their personal approval. I didn't have a strong view on the underlying engineering philosophy. What I cared about was that the standoff was costing real delivery time, made worse by a nine-hour gap between Amsterdam and San Francisco. It came to a head on the iDEAL/Sofort project, where merge requests sat unreviewed and the timeline began slipping.
Phase 3 — going to the source.
Rather than assume this was simple resistance to process, I opened a conversation with Bryan Knauber, the Head of Product, to understand what was actually driving the pushback. The answer wasn't about process at all: small merge requests gave him no usable context — he wanted to check something out and interact with a real feature, not review an isolated function with nothing to click on. I checked this with Zack Snow, the CTO, separately; he confirmed the same read from his own side, comparing what a request actually contained against what he'd expect to see at that stage of a build.
Phase 4 — the third option.
I brought that insight back to Denis, and together we designed a system that hadn't been on the table for either side: each merge request would represent one complete, testable sub-feature — no smaller, no larger — merged to a shared feature branch for testing, with the cofounders approving once at the feature-branch level rather than reviewing every individual request. It took about a month to align everyone on it. The iDEAL/Sofort project, targeted for September, shipped at the end of October as a direct result of that month.
The win was not iDEAL being shipped but the trust I started to build through this friction.
The six-week delay was real, and I've never found a version of this story worth telling that hides it. What it bought was more valuable than the missed date: a working system, and a working relationship with two cofounders who'd never had a reason to trust an outside PM's judgment before. That system wasn't a one-time fix. It carried through FareHarbor's Adyen integration a year later, and through the company's 2021 online-cancellation work. And when the next PM joined the company four months after I did, she didn't have to rediscover any of this the hard way — I walked her through it directly, so navigating the cofounders' delivery expectations was one less thing she had to learn on her own.