Every User a Product Manager

How a two-person company runs product and QA by turning the crowd into the team. Part of the series.

A user found a bug I never would have. Not a crash — a subtle, specific wrongness deep in a workflow I don't even use the way she does, the kind of thing that only surfaces when someone is trying to make something real on a Tuesday afternoon. She told us. A day or two later it was fixed, she got a note saying so, and a handful of credits landed in her account for the catch. And somewhere in there it hit me: she had just done, for the price of a little compute, two jobs I could never afford to hire for. She was my QA. And by telling me which broken thing actually mattered to a real person making real work, she was my product manager too.

The math that forced it was simple. A non-technical founder and one engineer cannot staff a QA team or a product team. So I didn't. I turned the people already using the product into both — because they are the only ones who truly know what's broken and what matters, and there are a great many more of them than there will ever be of me. Your users are the most honest, most thorough, most motivated product organization you will ever have. The trick is building the machine that lets them be it.

That machine is a loop. It has four moves, and once it's running it mostly runs itself.

First, capture — and make it frictionless. Most people can't write a bug report. They can write "this is broken and I'm annoyed," which is useless to an engineer and the only thing you'll ever reliably get. So I put an AI in the middle: the user describes the problem like a human, and the system quietly turns it into the thing an engineer actually needs — what they were doing, what they expected, what happened, where in the system it lives. Messy in, structured out. The user never knows they just filed a professional-grade ticket.

Second, route it. That structured report doesn't land in an inbox to be forgotten. It becomes a tracked issue, enriched with technical context, and dropped straight into the same pipeline my engineering work already flows through. The report becomes work, automatically. This is the unglamorous half nobody builds, and it's the half that makes the whole thing real instead of theater.

Third, pay them. Credits for a valid report. This is the part that feels almost too clever to say out loud: I pay my users to find my bugs, in a currency I print myself. It costs me almost nothing and it's worth a fortune, because it aligns everyone — they want the product better, I want it better, and now they're rewarded for caring. We host sessions where this gets concentrated: invite people in, turn them loose on the thing, let them hunt. It turns QA, the most thankless job in software, into something that feels like a game with a prize.

Fourth — the one everyone skips — close the loop. When the bug is fixed, the person who reported it gets told. They watch their complaint become a real change in a real product they use. That is the entire magic. A report that vanishes trains people to stop reporting. A report that visibly ships trains them to do it again, and to bring their friends. The loop reinforces itself. That's what I mean when I say it runs itself: every closed loop makes the next one more likely.

Lay those four moves end to end and look at what you actually have. The crowd finds what's broken — coverage across every device, every workflow, every weird real-world path no internal team would ever think to try. That's a QA department. And by which bugs they bother to report, and how loudly, they tell you what actually hurts real people doing real work — which is prioritization, which is most of the job of product. That's a PM department. I hired neither. I built the loop, and the loop hired them for me, in credits.

Now the warning, because this is where it goes wrong, and it's the same warning as everything else in this series. You cannot let the crowd drive. A raw feed of user reports, acted on automatically, is just a different kind of catastrophe — you'll build whatever the loudest, or the most credit-hungry, person asks for, and you'll get gamed the moment someone realizes junk reports pay. The crowd is a sensor, not a steering wheel. So the AI captures and structures and routes, but a human — me — still decides what's real, what matters, and what ships. The incentive has a gate on it, the same way the money path does: easy to report, hard to farm. Crowd as input. Judgment as output. Control in the one place it has to be.

This is the company-as-code idea pointed at the people outside the building. Your customers stop being an audience and become a department in your operating system — a distributed product-and-QA org you coordinate through software instead of hiring. It is, genuinely, how a company of two has a QA team and a product team it never could have paid for. And it's the cleanest example I have of the loop this whole series is about: messy real-world experience goes in, the system distills it into something it can act on, and the thing gets better on its own — except here the "experience" is everyone's Tuesday afternoons instead of just mine.

Once that loop exists, you start feeding it everything, because mess is mess and the machine doesn't care where it came from. The richest and most wasted source of it in any company is the meeting — an hour of people talking, circling, deciding things out loud, and then mostly forgetting them by Friday. So the meetings get recorded too. Every call is transcribed and read by the machine, which does to an hour of rambling exactly what it does to a user's this is broken and I'm annoyed: it turns talk into structure. One meeting comes out the other side as a QA report of the bugs someone mentioned in passing, a list of product changes that got agreed to and would otherwise have evaporated, draft issues filed straight into the same engineering pipeline the rest of the work already flows through, and a clean set of strategy and operations notes — the decisions, the owners, the next steps — pulled out of the noise and written down where they can't be lost. The conversation files its own follow-ups.

And it lands the same way the bug reports do: as proposals, stacked up and waiting for a human to say which ones are real. I read the meeting back as a list of here's what the machine thinks we just decided, promote the ones that matter into actual work — the product queue, the engineering backlog, the ops list — and let the rest go. Same loop, same gate. The crowd's mess and my own mess pour into the same machine, come out as the same structured work, and stop at the same place: my judgment about what's worth doing. The meeting used to be where decisions went to die. Now it's just another sensor.

The best part is what it does to the people in it. Someone who reports a bug and watches it get fixed stops being a customer and starts being a collaborator. You didn't just get free QA. You turned the person into a co-owner of the thing. Call it a growth hack if you want; I think it's just what a product was always supposed to feel like, back before software decided its users were a number on a dashboard.

Next: the MBA was an AI manual — why half of business school just died, and the other half became code.