From Producer to Builder: My Journey as a Product Manager Through the Web

I didn’t set out to have a career that tracked the history of the internet. But looking back—GeoCities, Yahoo!, Media Temple, Etsy, my own startup, Mailchimp, and then Intuit Mailchimp—I realize I’ve been standing in the front row of a 25-year argument about what a “product person” is even for and what the role even means.

Web 1.0: The Producer Era

When I started, nobody called it product management. At GeoCities, and later Yahoo!, the job title that came closest was producer, a holdover from media and entertainment. The mental model was editorial: you assembled content, coordinated a page, and shipped a release the way you’d ship an issue of a magazine. Engineering built what was specified. Design made it look right. The producer’s job was traffic cop plus tastemaker.

This was the era of waterfall by default—not because anyone read a methodology book, but because the web itself was still page-based and slow-moving. A “release” was a real event. Requirements docs were long. The feedback loop between what you shipped and what users did with it was measured in weeks, if you could measure it at all.

It’s worth remembering what it took to get funded back then, too. A startup in the 1990s typically needed a working product, real revenue signals, and a founding team with a track record before a venture firm would write a check. Even then, the checks were large: a Series A was often the first institutional money a company saw, in the millions of dollars, and it came with the expectation that you’d immediately build out a full functional organization.

That capital structure produced the producer model almost by default. If you could raise money at all, you could afford departments: engineering, design, and yes, product. There was no version of the industry yet where three people with a laptop and an idea could get funded and start building.

Web 2.0: The Mini CEO Myth

By the time I got to Media Temple and then Etsy, something had shifted. The industry had discovered the “product manager as mini CEO” framing: you owned a P&L-adjacent slice of the product, you were supposed to think like a founder, and you were the person who said no to everyone, including your own engineers. Ben Horowitz’s essay on the subject became gospel; every PM job description quoted it, knowingly or not.

This is also when the management fads started arriving in earnest. Agile had already crossed over from engineering into product thinking. Scrum gave us sprints, backlogs, and the strange ritual of story pointing. Etsy in particular was steeped in a culture of continuous deployment and blameless postmortems—the opposite instinct from the producer era’s big, careful releases. You didn’t ship an issue anymore; you shipped constantly, and you watched what happened in real time.

The “mini CEO” language was aspirational and a little bit of a lie. It gave PMs authority language without actual authority: no headcount, no budget, all the accountability. But it did something important: it moved the center of gravity from coordinating output to owning outcomes. That’s the seed of everything that came after.

The Money Story: Seed, Pre-Seed, and the Accelerator Effect

None of what happened next makes sense without talking about where the money came from, because the financing structure of startups and the organizational structure of product teams have always moved together.

Y Combinator launched in 2005, and it, along with the seed funds and angel networks that followed it, did something the industry hadn’t really seen before: it made it normal to fund a company before it had a product, a business model, or sometimes even a full founding team, for a small check relative to a traditional Series A.

Seed rounds went from a rare bridge that serious investors used sparingly to a full asset class with its own funds, terms, and expectations. That mattered enormously for product work, because it meant a huge new population of companies existed at a stage where they simply could not afford a dedicated product manager, a dedicated researcher, and a dedicated growth lead. They could afford maybe three or four people total.

The generalist “mini CEO” framing wasn’t just a management philosophy at that point; it was a budget constraint wearing a philosophy’s clothes.

Accelerators layered their own management culture on top of this. YC’s batch model, its weekly office hours, and its relentless emphasis on shipping something demoable by demo day imported a cadence that looked a lot like the sprint structure agile teams were already adopting, but compressed to the scale of a single founding team instead of a department. “Talk to users, ship fast, iterate” became as much a cultural inheritance from the accelerator world as from the Agile Manifesto.

Then, roughly a decade after seed rounds normalized, pre-seed emerged as its own explicit category, sometime around 2015 to 2017, pushing the earliest institutional money even further back—often to the idea stage, before a line of code existed.

That had a subtle but real effect on what “product thinking” meant at a company’s founding moment. When you can raise real capital on a narrative and a founding team’s judgment alone, the earliest product work isn’t building at all. It’s the discipline of articulating a hypothesis clearly enough that someone will fund you to go test it. Some of the sharpest product instincts I’ve seen in founders show up right there, before the company technically has a product to manage.

By the time I was raising for Reaction Commerce, this was the water we all swam in. Pre-seed and seed capital meant you could start a company with a small team and a real shot at survival, but it also meant nobody was going to hand you a product organization. You were going to be the whole organization, for a while, whether or not “product manager” was ever your title.

The Great Unbundling: New Roles Arrive

As companies scaled—this is roughly my Etsy-through-founder-years period—the “mini CEO” job got too big for one person to hold, and the industry responded by unbundling it.

Growth became its own discipline, borrowing from marketing and data science and obsessing over funnels and experimentation velocity. User research split off from design and became its own function, with its own rigor and its own seat at the roadmap table. Strategy sometimes lived with a separate “product strategy” or business operations role. And project management—the actual choreography of who’s doing what by when—got explicitly separated from product management, because it turned out “own the outcome” and “run the standup” were different skill sets pretending to be one job.

Kanban showed up here too, often alongside Scrum rather than instead of it, with teams borrowing whichever ritual solved their actual bottleneck rather than adopting a methodology as identity. This is also when “agile” started to curdle a little, in my experience, becoming a compliance exercise at some companies rather than the lightweight, adaptive thing it was meant to be.

It’s worth noting that this unbundling was itself a capital story as much as an organizational one. Companies could only afford to split growth, research, strategy, and project management into separate functions once they’d raised enough—usually a Series A or B in the old sense—to staff each one properly. Seed- and pre-seed-stage companies didn’t get that luxury. They stayed generalist by necessity, which is exactly the population of companies I kept ending up inside of.

Founder Years: Product Management Without the Title

When I co-founded Reaction Commerce, I stopped being a “product manager” and became, functionally, all of the unbundled roles at once: strategist, researcher, growth lead, and project manager, because there was no one else.

This is where I actually understood the mini CEO framing for the first time—not as a job description, but as a lived reality. Nobody unbundles the roles for you when you’re eight people, and nobody was going to fund eight people plus a full product organization on a seed round.

Builder: What’s Actually Changing Now

Which brings me to now, HappyHQ, and the reason I think “builder” is the more honest word than “manager.”

For twenty years, the core scarcity in product work was execution capacity. The PM’s whole professional identity got built around that scarcity: you couldn’t build everything, so you had to be excellent at deciding and prioritizing, and at writing the spec precisely enough that someone else could turn it into working software without you in the room.

Every role that got unbundled from the mini CEO job—research, growth, project management, strategy—was in some sense a specialization built on top of that same constraint: ideas are cheap, building is expensive, so surround the expensive part with enough process and specialized judgment to spend it wisely.

AI-native tools break that constraint in a way I don’t think our industry has fully metabolized yet. A PM today can go from idea to working prototype in an afternoon, without waiting on the old handoff chain of spec, design, engineering estimate, and sprint planning.

That’s not a faster version of the old job. It’s a different job, because the thing the whole discipline was organized around—the scarcity of building—is no longer the bottleneck.

There’s another shift underneath this one: the move from deterministic to probabilistic products. Many of us who spent the last twenty years building software were trained to think in terms of systems that take known inputs and produce predictable outputs. That model shaped how we designed products, wrote requirements, evaluated quality, and defined reliability.

AI-native products work differently. They often create value through outputs that are probabilistic, adaptive, and sometimes surprising. The challenge is no longer simply specifying exactly what the system should do. It’s defining the conditions under which an intelligent system can be useful, trustworthy, and safe—even when its behavior isn’t entirely predictable.

People who begin building with this mental model from the outset may have a significant advantage. They won’t have to unlearn the assumption that every valuable product is essentially a deterministic machine with a user interface. They’ll be able to imagine products that behave more like collaborators, guides, or creative partners.

This is also reshaping the capital story again, in a way that feels like it rhymes with the seed and pre-seed shift. When a tiny team can build and validate more with the same round size, pre-seed and seed checks stretch further, and companies can stay small and generalist for longer before they need—or can even justify—unbundling into specialized roles.

The founder-does-everything phase I lived through at Reaction Commerce because of capital constraints is now something founders are choosing to extend because of capability, not just enduring because of scarcity.

And I’m not the only one seeing it.

I hear the same tension from almost every founder and leadership team I coach right now. Code is cheap, but the process built around code being expensive hasn’t caught up. Teams tell me that sprints stopped being meaningful release units years ago. They ship whenever something is ready, but the two-week planning ritual survives anyway, wrapped around work that often takes a fraction of that time. Story points still get defended in retrospectives even though everyone privately knows that a point means something different on every team. Or there’s an appetite and things are shaped. Different words, similar issues.

The founders who’ve actually adapted aren’t eliminating process. They’re reorganizing it around risk instead of ritual. Most changes ship quickly with no formal gate. The handful that are genuinely hard to undo, such as a data model change or something a partner will build against, get real scrutiny before anyone touches them. That’s a much sharper distinction than the old questions of “How big is this?” or “Whose sprint is it?”

The other thing my coaching clients bring up constantly is that the bottleneck didn’t disappear. It moved. An engineer can fix something in thirty minutes that used to take days, but getting that fix reproduced, reviewed, merged, and communicated to a customer can still take most of a day. The organization around the code hasn’t been rebuilt at the same speed as the code itself. That’s the institutional memory problem again, wearing a different outfit.

A few things I’m noticing as this plays out, from the inside, building HappyHQ and through my coaching practice with founders:

The spec is becoming the artifact, not the plan for the artifact

The old world separated “deciding what to build” from “building it” because those required different skills and different people. When you can prototype in natural language, the line blurs. Writing a good prompt and writing a good spec are converging into the same craft, and that craft belongs to whoever has the clearest judgment about the problem—not necessarily whoever has the engineering title.

Taste and judgment are getting more valuable, not less

When execution was scarce, a mediocre idea executed flawlessly could still win. When execution is cheap, the quality of the idea and the judgment about what’s actually worth building matter disproportionately more, because there’s no longer a long, expensive build cycle to filter out the bad ones before they ship.

The unbundled roles are re-bundling, but around a person, not a title

Growth, research, strategy, and project management got separated because no one person could hold that much surface area when each required deep specialized tooling and process. AI collapses a lot of that tooling overhead.

I don’t think this means those disciplines disappear; user research is still a discipline, and growth is still a discipline. But a single builder can now hold meaningfully more of that surface area than they could five years ago—the way a founding team always has, out of necessity, before a company can afford to unbundle.

Institutional memory becomes the actual constraint

This is the problem HappyHQ exists to solve, so I’m obviously biased, but I think it’s real: when building gets fast and cheap, the thing that determines whether a team compounds or just spins is whether it remembers what it already tried, what it learned, and why it made the calls it made.

The producer era had slow releases and long memories, because everything was documented out of necessity. The builder era has fast releases and short memories, because nothing forces the documentation—or, more importantly, the learning—to happen. That’s a real regression, and I think it’s the next problem worth solving.

The producer coordinated. The mini CEO owned outcomes without authority. The builder just builds, and the job is less about translation between people who have ideas and people who have the tools to execute them, and more about judgment: knowing what’s worth building at all, and remembering why, once you’ve built it.