You're 12 people. Half are engineers, a couple do design, and someone owns growth while also doing three other jobs. You don't have a PMO. You have a founder who checks the board at 11pm and an eng lead who wants to know what ships this week without opening four tools.

This is a workflow built for that reality: a 5-25 person SaaS that outgrew a single Trello board but has no appetite for a 40-field enterprise process. Three boards, one roadmap page, and a few automations doing the boring parts. That's it.

Key takeaways

  • Run three boards that match how work actually splits: dev, design, growth. Don't force one board to do all three jobs.
  • Use a single nested page as the roadmap roll-up, so leadership reads outcomes instead of card-by-card noise.
  • Let automations move cards, set due dates, and post updates on triggers, so status is a byproduct of doing the work, not a separate chore.
  • Keep priorities and labels shared and few. Four priorities and a short label set beat a taxonomy nobody maintains.
  • Add AI bottleneck detection once you have real card history, not on day one.

Why three boards beats one

The temptation at 15 people is to keep everything on one board because "we're small." It falls apart the first time a designer's in-progress column collides with an engineer's code review column, and growth experiments have nowhere sensible to live. Different functions have different verbs. Engineers move cards through review and QA. Designers move work through exploration and handoff. Growth runs experiments that either win or die.

Three boards give each function a workflow that fits its own rhythm, while the cards stay linked to the same workspace. In Zoobbe, boards live under one workspace with shared, reusable labels, so a "Q3 Launch" label means the same thing on the dev board and the growth board. You get separation without silos.

The dev board

Lists that mirror your delivery pipeline: Backlog, To-Do, In Progress, Code Review, QA, Done. Cards carry the useful metadata engineers actually reference: multiple assignees for pairing, a priority (Normal, High, Low, Urgent), due dates with reminders, checklists for acceptance criteria, and threaded comments with @mentions so context lives on the card instead of a Slack thread that scrolls away.

Custom fields earn their place here. A single-select field for "environment" or a number field for estimate points keeps structure light. If you're migrating off Trello, the Trello board import brings cards, checklists, comments, and members over, so you're not rebuilding history by hand.

The design board

Design work isn't a straight line, so the lists aren't either: Requests, Exploring, In Review, Ready for Dev, Shipped. The strength here is that design specs don't have to be cards at all. Zoobbe pages are Notion-style rich text, and a card can link to a page holding the full spec, with cover images and attachments. Designers write in a proper document; engineers pull the linked card when it's ready for dev.

Because pages support real-time collaborative editing via Yjs, two designers can work the same spec at once and see who else is present. No refreshing, no "can you get out of the doc so I can save."

The growth board

Growth lives or dies by cycle time on experiments, so the board is a funnel of experiments: Ideas, Prioritized, Running, Analyzing, Learnings. Each experiment card gets a hypothesis in the description, a due date for the review checkpoint, and a custom field for the metric it targets. When an experiment closes, the learning stays on the card's activity log, so you stop re-running the test you already lost six weeks ago.

The roadmap roll-up page

Here's the part most tools miss. Your CEO does not want to read 60 cards across three boards. They want a roadmap. In Zoobbe, you build that as a single page with a nested hierarchy: a top-level Roadmap page, child pages per quarter or per theme, each summarizing the initiatives underneath.

The page is the narrative layer. It says "Billing revamp: on track, ships this quarter" in a sentence a founder can scan, while the boards hold the granular execution. You control who sees it with page roles: viewer, commenter, editor, owner. Give investors a viewer link, give the leadership team commenter access, keep edit rights with whoever owns the roadmap. Permissions inherit from the parent, so you set them once at the top.

Update it in the weekly leadership sync, live, with everyone present on the same page. Because presence is shown, you know who's actually reading versus who said they read it.

Automations that remove the busywork

The reason status updates rot is that they're a second job. Automations make status a side effect of doing the work. A few rules cover most of it:

  • When a card moves to Code Review, auto-assign your reviewer and set a due date so reviews don't sit for three days.
  • When a due date is approaching, send a notification to the assignee before it's late, not after.
  • When a checklist completes, mark the card complete and move it to Done.
  • On a schedule (cron), auto-create the recurring cards you know are coming: the Monday planning card, the end-of-sprint retro card.

Zoobbe automations follow a trigger, condition, action shape, so "when a card is moved to a list, if it has the Urgent priority, add a comment and notify the lead" is a single rule. The point isn't automating everything. It's deleting the ten manual card-shuffles per day that nobody should be doing.

Where AI fits (later, not first)

Skip AI on week one. You have no history for it to reason about. Once your three boards have a few months of real card movement, AI Insights like bottleneck detection and completion prediction start telling you things you can act on: which list cards pile up in, whether a launch is likely to slip. The AI Chatbot can also create and move cards from plain language, which is handy for the founder who lives in a terminal or on their phone and doesn't want to hunt for the right column.

Putting it together

Three boards, mapped to how your team already splits work. One roadmap page that rolls execution into a story leadership can read. A handful of automations doing the shuffling. AI added when you've earned the data to make it useful. That's a project management workflow a 15-person SaaS can actually run without hiring someone to run it.

You can build all of this in an afternoon and import your existing Trello board to start. Set up your three boards and roadmap page in Zoobbe and let the automations handle the rest.

FAQ

How many boards should a small SaaS startup use?

Map boards to functions, not headcount. For most 5-25 person SaaS teams that's three: dev, design, and growth. Add a board only when a function's workflow genuinely differs from the others. More boards than functions creates overhead; fewer forces mismatched work onto one pipeline.

Should the roadmap be a board or a page?

A page. Boards are for execution at the card level; a roadmap is a narrative for leadership and stakeholders. Zoobbe's nested pages let you build a roadmap with child pages per quarter or theme, shared with role-based permissions so investors get view access and the team gets edit access.

How do I keep three boards from becoming three silos?

Keep them in one workspace with shared, reusable labels so a launch label means the same thing everywhere, and link related cards to the same pages. The roadmap page ties execution across all three boards into one view.

Can I move my existing Trello setup over?

Yes. Zoobbe imports Trello boards including cards, checklists, comments, and members, with real-time progress as it runs. You can also import from Fluent Board.

When should we turn on AI features?

Once your boards have a few months of card history. AI Insights like bottleneck detection and completion prediction need real movement data to be useful. Turning them on before that gives you predictions with nothing to predict from.

Photo by Paper Textures on Unsplash