My brother Matt signed up to one of my products and created a timeline about the history of cinema. There was already a comprehensive one on the site. He had not seen it, and nothing in the product told him it was there.
He also found a bug in the process, because of course he did.
That is the thing nobody puts in the diagram. Every workflow chart of this kind ends with an arrow pointing at deployment, as though shipping were the terminus. It is not. It is the point at which the product starts telling you things you did not know, and the only question is whether you have built a way to hear them.
Three sources, in increasing order of how much they hurt.
Errors, automatically. I run Sentry on the front end. It has told me about things I would never have found, and it tells me in minutes rather than when a user gives up and leaves. On 8 July I asked for a batch of Sentry errors to be investigated and fixed, and remembered, with visible reluctance, to add "follow the coding laws" so the fixes went through tickets like everything else. Automated error reporting is the cheapest thing on this list and the first thing I would set up.
Feedback, deliberately. A form is enough. Airtable, Productlane, whatever you have. What matters is not the tool but that the path from a user’s irritation to your backlog is short enough that the irritation survives the journey. If it takes four steps, you will only hear from the furious, and the furious are not representative.
Yourself, using it properly. This is the one I keep relearning. I demoed one of my own products off the cuff and was embarrassed, because a flow I had not walked through since building it was broken. Everything I know about that product came from building it, which is exactly the knowledge a new user does not have.
And then the loop runs again. The feedback becomes a ticket. The ticket becomes a plan. The plan waits for a separate go. The branch, the merge, the deploy, and back round.
Which is where this series started, and it is the actual point of all of it. The stack is not Claude plus Linear plus GitHub plus a host. Any of those can be swapped and the thing still works. What matters is that there is a loop at all, that it is closed, and that every part of it leaves a record that outlives the conversation it happened in.
Fourteen pieces on how I do it. I have been at this twenty-five years and about eight months of it has been like this, so I am reporting rather than teaching.
Which part of your own loop is still open? Mine is user feedback, and it has been for months, and I am not sure the honest answer is a tool.