The problem with ticket-first thinking
You have an idea for a new product line. You open the tracker and start a ticket. The ticket gets long — motivation, scope sub-bullets, open questions, a paragraph about constraints. A week later your developer opens that ticket, sees a wall of text, scrolls past it, and codes from the title. Three months later somebody asks why the work landed the way it did and nobody can find the answer.
This is how Monday turns into Friday with nothing legible to show for the week. The intent was in your head. Some of it went into chat, some into a ticket, some into a call nobody transcribed. By the time the work shipped, the trail had three forks and none of them matched.
What we do instead
Ship treats an initiative as a project, not a ticket. A project on your tracker (Linear projects, Jira epics, whatever your tool calls them) has a description body — and that's where motivation, scope, constraints, and decisions live. One place. Readable in one sitting. Authored by you, expanded over time.
Child tickets stay short. Each one says what's being done and what counts as done, and links back to the project. When somebody opens a ticket, they pull motivation from the project body.
The rule: long context lives in the project, short tasks live in the tickets, the conversation that produced both lives in your chat. Three layers, each doing one job.
How this plays out in chat
You open the chat and say "I want to think through how we'd add team workspaces to the product." Ship doesn't immediately draft a ticket. It checks whether a project for this already exists. If one does, it reads the description and asks where you'd like to add what you're thinking. If not, it proposes a project description — a paragraph or two of motivation and scope — and asks you to approve before writing it.
You go back and forth. You correct a sentence. You add a constraint. When the description holds, Ship creates the project and the work has a home. From there, ticket creation is short. "Draft the three first tickets for this." Each one is a goal and a definition of done; each one links to the project.
Adding to a project as you keep thinking
A week from now you have a new thought about the same initiative. You don't write a new ticket called "thoughts on team workspaces (v2)." You say "add a constraint to the team-workspaces project — we're not supporting nested workspaces in version one," and Ship appends that decision to the project body. The description becomes a living document that captures how your thinking evolved. A developer opening a ticket six weeks from now reads the full picture without finding you on Slack.
When to use a project, when to use a ticket
A project is the right shape when the work is more than one or two pull requests, takes more than a couple of days, or requires multiple people to coordinate. A single ticket is the right shape when the work is one self-contained change with a clear definition of done. If you're unsure, ask Ship — it'll suggest the shape and won't create either without your OK.
The mistake to avoid is letting the first ticket on an initiative become the de facto project. The second ticket has no parent, the third one duplicates the motivation, and the trail forks again.
The dashboard view
Once your projects are on the tracker, the Ship dashboard shows them grouped — active, drafted, parked. You move a project between groups from chat ("park this for now") or from the dashboard itself. Parked projects don't get worked on automatically; active ones do; drafts are still being shaped.
That grouping is how a busy founder sees the whole portfolio at a glance instead of scrolling a flat ticket list.