Owning the product, not the ticket

Most of my work is inside someone else’s product. There is a queue, a design, and a person who can tell me which problem is allowed to wait. I still push on those calls. I would rather ship a smaller thing that a customer can finish than a wide thing that stalls on the second screen. But the product is not mine. If a decision sits, the next ticket is waiting.

Jobs Copilot is mine. I planned it, built it, and launched it. It is a job-search product: a Next.js front, and a Node, Prisma, and Postgres back. It reached more than 200 active users. That is not a huge number. It is large enough that the boring parts stop being optional.

The first change is what “done” means. On a team, done is often the story matching the screen and the checks passing. On a product I own, done means a person can get through the thing I said it does, without me sitting next to them. I kept finding work that would never have been filed as a ticket. A screen that assumed the visitor already understood the product. A failure that was obvious in the database and invisible in the browser. A path that worked once and fell over the second time, because I had only tried the case where everything was already filled in.

I also had to decide what not to build. A product with “copilot” in the name can grow without end: more sources, more reminders, more ways to rewrite a sentence. Each one sounds useful on its own. A launch does not need all of them. It needs one path a person can finish, and data that still makes sense when they come back tomorrow. Prisma and Postgres were a good fit for that, because the schema is the product decision written down. If I had modeled the tables around a demo, I would have been rewriting them once people started repeating the same action. I tried to model them around the action I expected people to repeat.

The other change is that there is no separate team for the last mile. If the app is up and the message never goes out, that is still the product. If a query is fine at ten users and rude at two hundred, that is still the product. I got into the habit of checking the places where the screen and the database can disagree. The interface says the action worked. The row says it did not. Those two have to match, or the next screen is a lie as well.

Support is part of the build at this size. Two hundred people is not a call center. It is enough that the same question shows up more than once. When it did, I had a choice: answer it again, or change the product so the question was less likely. A clearer label. A better default. A step removed. That work is slower in an afternoon and cheaper over a month, and nobody writes the ticket for it unless you do.

The middle of a product is quieter than the start. The first version is loud. You can see the screens appear. After launch, the useful work is smaller: a query that got heavier, a sentence that confused people, a field nobody filled in. It does not look like progress in a screenshot. It is how the next version gets easier to ship than the last one.

I still like working inside other people’s products. The constraint is useful, and the systems are often bigger than anything I would pick alone. I wanted one product where I could not hand the last mile back. Jobs Copilot is that one. The launch was the start of the work, not the end of it.