How We Use Asana, Linear, AND Jira (And Why)

We're a 40-person SaaS company. Product uses Asana. One engineering team uses Linear.

Another uses Jira. Three tools, one company.

This is chaos. But it's intentional chaos. Here's why we do it and how we make it work.

Why We Ended Up Here

We didn't plan to use three tools. It happened over time.

We started with Asana in 2022. Everyone used it.

Then we hired our first engineering team. They wanted GitHub integration, Asana felt slow to them, so we switched that team to Linear.

A year later, we acquired a team from another company. They were using Jira for their own projects. Rather than force a migration, we let them keep it.

Now we have:

• Product team (5 people): Asana
• Platform engineering (8 people): Linear
• Integration engineering (5 people): Jira
• Everyone else (22 people): Asana

It's messy, but it works.

The Problems

The obvious pain: someone has to keep three tools in sync.

1. When a feature moves from Linear to ready-to-ship, we update Asana's status.

2. When a bug is filed in Asana, we create an issue in Linear or Jira.

3. When a task in Jira is blocked by something in Asana, someone has to manually flag it.

4. Reporting across three tools is impossible. We have to run reports separately.

5. Status is sometimes out of sync. Product thinks something is shipping Tuesday, engineering knows it's shipping Thursday, but Asana isn't updated yet.

How We Make It Work

We invested in process and tooling.

Weekly Sync Process

Every Monday morning, the product lead spends one hour syncing all three tools:

1. Pull all closed issues from Linear and Jira (automated query).

2. Update the equivalent Asana tasks to "complete."

3. Pull all new issues from Linear and Jira that aren't in Asana.

4. Create corresponding Asana tasks.

5. Update Asana blockers based on what engineering reported.

This one hour prevents days of miscommunication.

A Zapier Bridge

We built a Zapier integration that catches the obvious cases:

• When a Linear task is marked "done," create a Slack notification in our #engineering channel mentioning the Asana task to update.

• When an Asana task is moved to "Ready for Engineering," create a Linear issue (if one doesn't exist).

• When a Jira issue is closed, create a Slack message to the integration engineering team.

It's not perfect, but it catches 70% of the sync work automatically.

Clear Ownership

Each team owns their tool.

• Product owns Asana. They maintain templates, custom fields, automations.

• Platform engineering owns Linear. They maintain sprints, automations, GitHub integration.

• Integration engineering owns Jira. They maintain workflows, custom fields.

Each team is responsible for their data being accurate. Cross-tool sync is the product lead's job (one hour per week).

Status Language

We defined a consistent status language across all three tools.

For tracking the lifecycle of a feature:

• Asana "Backlog" = Linear "Backlog" = Jira "To Do"
• Asana "In Progress" = Linear "In Progress" = Jira "In Progress"
• Asana "In Review" = Linear "In Review" = Jira "In Review"
• Asana "Complete" = Linear "Done" = Jira "Done"

This makes manual syncing easier. Everyone knows what status means.

What We've Learned

1. Three Tools Is Too Many

In a perfect world, we'd standardize on one. The switching cost is high, but the long-term cost of managing three tools is higher.

If we could do it again, we'd force everyone into Asana. One tool for 40 people is better than three tools with high sync overhead.

2. Tools Matter, But Process Matters More

We don't have a problem with three tools. We have a solution for the problem three tools create: process.

The weekly sync, the Zapier integration, the status language. That's what makes it work. The tools are just repositories.

3. Context Switching Is Real

When engineering needs to ask "is this a blocker or a nice-to-have?" they're looking in Linear. But the context is in Asana. Someone has to bridge that gap.

It's not tragic, but it's inefficient. A single tool would eliminate this friction.

4. Reporting Is Broken

We can't answer "what's our feature velocity?" across the company because features are tracked in Asana but coded in Linear/Jira.

We end up building custom reports and losing confidence in the numbers.

A single tool would fix this immediately.

What We'd Do Differently

If we were rebuilding this today:

1. We'd standardize on Asana for everyone. Engineering team would get over the speed difference. The alignment gained is worth it.

2. We'd build clear processes upfront. The one-hour sync happens because we learned the hard way. Better to build it in from day one.

3. We'd integrate with Slack heavily. People don't live in PM tools, they live in Slack. Update Slack from the tools and you'll get better adoption.

4. We'd hold process sacred. This works only because the product lead spends an hour every week syncing. If that person leaves or gets busy, it falls apart.

The Cost of Three Tools

Direct cost: $3,000-5,000/year (Asana, Linear, Jira licenses).

Hidden cost (product lead time):

• Weekly sync: 1 hour x 52 weeks = 52 hours
• Investigating sync errors: 10 hours/year
• Training people on "which tool for what": 5 hours/year
• Total: 67 hours/year

At $75/hour (blended cost), that's $5,025/year in hidden cost.

Total cost: $8,000-10,000/year

Compare to standardizing on Asana:

• Direct cost: $2,500/year
• One-time migration: 40 hours = $3,000
• Total year one: $5,500

We would have broken even after year one, then saved $4,500/year forever.

We're probably going to consolidate to Asana sometime soon. The math is clear.

Honest Take

Three PM tools is a management failure. We don't recommend it.

If you're considering allowing multiple tools, push back. The convenience of each team choosing their tool is outweighed by the coordination cost.

If you already have multiple tools like us, solve it within one year. Migration is painful once, then you're done. Living with multiple tools is painful forever.

For Teams Considering Multiple Tools

Before you go down this path:

1. Can you standardize on one tool? (Yes, always yes.)

2. If not, can you pick one tool per function? (One for product, one for engineering, not three.)

3. If you must split, invest heavily in integration and process. That's your success factor.

4. Plan your consolidation now. When will you merge back to one tool? Two years? One year?

5. Don't let temporary convenience become permanent cost.

FAQ

Does Huddle help with this problem? Huddle aggregates multiple PM tools into one dashboard. You see Asana tasks and Linear issues in one place. It reduces the tab-switching pain, but it doesn't solve the underlying sync problem. Still useful for us though.

Should we use Zapier for everything? No, there are limits. Zapier is good for automated patterns (when X, then Y), but manual nuance requires a human (the one-hour weekly sync). Don't try to automate the human part.

Can we split tools by project instead of by team? Maybe. But it's worse than splitting by team. Splitting by team at least has clear ownership. Splitting by project means projects change tools over time and you lose history.

What if we add a fourth tool? Please don't. At that point, you need to consolidate. If you have four tools, you have a process problem that no tool will solve.

Is the one-hour sync enough? It's barely enough. That's 52 hours a year, and it's high-touch work. One person gets sick, one person gets busy with something else, and your sync falls apart. I'd recommend two hours per week if you're going to do this, which is another argument for standardizing on one tool.