There was a period in my career when the title was difficult to explain and the responsibility was not.
I ran work across several internet businesses and industries. Developers were building. Marketers were finding demand. Products needed decisions. Priorities collided. Somebody had to keep the whole portfolio moving.
That somebody was often me.
Titles describe clean organizations
Small internet businesses are rarely clean organizations.
The work does not arrive already separated into product, engineering, growth, operations, and commercial strategy. A traffic problem becomes a product problem. A product promise creates development work. A technical constraint changes the marketing plan. A person waiting for a decision becomes the bottleneck across all of them.
The job was to see those connections early enough to do something useful about them.
I coordinated developers and marketers, chose what deserved attention, translated between people with different definitions of done, and kept execution connected to the commercial reason for doing it. The title changed or failed to capture the shape. The responsibility stayed legible: make the portfolio work.
Management was not a departure from making
It would be convenient to tell this as a detour away from engineering. It was not.
I had started by building my first commercial website, where development and distribution were already one job. Running a wider portfolio expanded the same system. The code was now written by more people. The marketing had more channels. The consequences crossed more businesses. But the core question was familiar: what has to happen next for this thing to keep working?
I spent less time typing code and more time shaping the work around it. That taught me where execution actually stalls.
Usually it is not a lack of ideas. It is unclear intent, missing ownership, bad handoffs, weak feedback, or nobody willing to make the tradeoff explicit.
Earth Roulette pulled me back into the code
Earth Roulette began with a small personal annoyance: wanting to travel and having no idea where to go.
Building it pulled me deeply back into hands-on engineering. The random button became filters, destination data, travel guides, saved places, mobile apps, and eventually the data underneath Travel Bot.
The return mattered because I did not come back as the same developer who had built that site. I came back carrying years of portfolio decisions, marketing, team coordination, and commercial responsibility.
I was not learning how to type code again. I was reconnecting execution to a much larger model of what a product needs.
Magic Toolbox and Sirv made the job wider again
I later joined Magic Toolbox as a marketer and moved to Sirv. Over time the boundary around the role expanded: growth, product, systems, content, operations, and whatever else needed owning.
That breadth can look unfocused on a conventional CV. In practice it is a coherent skill: take responsibility for the product as a whole, then work at the layer where the bottleneck currently lives.
Sometimes that is copy. Sometimes it is architecture. Sometimes it is a process nobody has named. Sometimes it is telling people to stop building and prove that the existing thing works.
AI removed the execution bottleneck
As AI coding systems improved, the distance between intent and implementation collapsed.
That did not turn a marketer into a developer. It gave someone who had already accumulated development, distribution, management, marketing, and commercial experience a much larger execution surface.
I could build more of my own ideas directly. Then, when the models became reliable enough for production engineering with strong review and verification, those abilities converged in Sirv Studio.
Studio is not the beginning of the story. It is what happened when the bottleneck that had separated the roles finally became small enough.
Responsibility is the durable title
I now use “product builder and operator” because it is the least misleading short version I have found.
Builder matters because I make the thing. Operator matters because shipping is not the end of the job. Distribution, people, incidents, users, money, maintenance, and the uncomfortable evidence that something is not working all remain part of the product.
The title can stay a little fuzzy. The responsibility is still the same: understand the whole system, find the real bottleneck, and keep the work alive.