How I'm rethinking my Asana strategy in a Teamless reality

[Kelly_Perry4]

Like many others, I started using Asana in a pre-Portfolio era where Teams were a key factor in my set-up and project set-up strategy. While it wasn’t perfect, it’s how I cut my teeth with the tool. I was honestly late to the Portfolio game because it took me awhile to find a use-case that wasn’t solved by Teams. I know I’m coming off as a Team stan here, but honestly when the new Team Overview Page launched it was such a bright spot for me that I tell everyone I know to use this feature.

But now it appears that Teams are kind of…pointless? In our new Teamless reality, there is no way to add new projects directly to a Team without a Flowsana integration or manually going back in to add them. Most of the guidance I’ve seen has been to lean more into Portfolios which has forced me to rethink my strategy and my processes around workspace setup. I figured I’d share how I’m navigating this shift here.

Less of an Org Chart, More of a Filing System

While I’m not always setting up Teams to reflect org structure, it was definitely one of the more common ways I would set things up. Switching to Portfolios all-the-way-up did allow me to think about organization a bit differently.

The first thing I did was reframe how I thought of my projects. If you’ve ever had to figure out how to organize files on a company drive (Sharepoint, Dropbox, Server) then you’re already halfway there. I figured out what is the top-most folder, and then drilled down from there.

Questions I asked myself:

• What work is being done where?
• What work is related (and therefore should be close-by)?
• Who needs visibility/access to this work?

In my examples below, I explored a couple of options:

Option 1: Where the Ops Team needs to have their projects centrally located and easily accessible. In this scenario, not a lot of folks outside the department really need to be in the weeds of the projects going on.

Option 2: Where the company needs a team-agnostic approach for campaigns that require a ton of crossfunctional collaboration.

Added Layers of Norming

When setting norms for Asana usage, I always skipped Portfolios unless I had a real reason to include them. Now, it has to be a key inclusion.

• Who creates Portfolios at the organization? Should anyone be able to make a new Portfolio? Do you need to submit a request if you think you need one?
• What criteria should be met before a new Portfolio is created? I’m starting off with an internal criteria that a Portfolio should be used if there will be 3 or more contained projects or sub-portfolios.
• Portfolio Naming conventions – Like with folder & filenaming, how do we ensure the Portfolios are clearly titled so work can be found easily.

Issues I’m Still Solving

The main reason I am still uneasy about adopting Portfolios as a major aspect of my strategy is because I still find it immensely difficult to navigate. Once you really get into nesting Parent/Child Portfolios, it can get really hard to navigate and find what you’re looking for if you’re not deeply embedded in the work. Yes, I can star everything but what an onboarding nightmare to hand a list of Portfolios you have to favorite before you can get to work.

I would love to see some kind of nesting menu where I can easily locate the parent-most Portfolio and see everything layered into it, like you would in other file management tools. Or maybe to be able to filter/sort on parent Portfolios. Idk, maybe I’ll put in a feature request!

If anyone has any tips on better navigating the Portfolio view or thoughts on how to rethink an infrastructure without relying on Teams, I would love your perspective!

[ka_nishiyama]

I’ve thought about that a little before.

Large-scale, cross-functional projects

Overview Use Asana to manage large-scale projects(Different definition to Asana projects) involving multiple departments, clients, and partner organizations. Premise Asana Features: Asana provides a wealth of tools for open, non-hierarchical communication. Real-world organizational features: Internal communication tends to be closed within each department. When interacting with other departments, information about one’s own department is often somewhat exaggerated. Challenge To effectively…

---

I have recently provided commentary on WorkGraph.

Asana Work Graph - as a feature

Recently (though it’s actually been almost a month now), we’ve switched to a teamless project structure. Up until now, each project was under a team, which had its advantages in terms of clarity. I feel that a graphical representation of work graph is needed now more than ever.

[Skyler]

I too want nested portfolios to work like subtasks—where we can continuously expand them like your GIF shows.

That said, I applying custom fields to the projects in the portfolio and then using the group by function goes a long way and still prevents a ton of siloing.

That said, I still use Teams as well. Even if a project is cross-functional, a team still needs to own it (applying the same philosophy Asana has for tasks to projects). I don’t care about hierarchy so much as accountability.

As far as how to best use portfolios. I try to keep them simple and don’t go too deep because it does become more difficult to find them later on. I mainly use them to group different projects together underneath a single “parent” portfolio and rely on the portfolio to give us context as to what client a project is associated with. Many projects have the same name, so the portfolio, project icon, and custom fields applied to the project at the portfolio level enable us to distinguish things.

We avoid creating any sort of portfolio that’s used for aggregating projects for the purposes of navigation since Asana dynamically changes what portfolio appears in a project’s breadcrumb list based on where it was navigated from—learned that the hard way.

In a perfect world, I’d like to just be able to create a saved view (not a favorited view…I still wish they were different like they used to be) where I can define what I want to see, how I want it filtered, grouped, sorted, and organized. But unfortunately Asana’s advanced search is still extremely weak in this regard.

[Kelly_Perry4]

This is so great, Skyler, I really like the idea of using Custom Fields in this way. I need to add that to my repertoire! I was already weary of getting too deep with the nested portfolios and getting lost, not even realizing the breadcrumb situation.

How are you working around the Teamless-by-default shift? Have you just adjusted process to include a step of manually going back into the new project and adding to a Team?

[lpb]

Hi @Kelly_Perry4,

@Kelly_Perry4

I would love your perspective

My clients and I are taking teamless teams in stride thanks to the flexibility afforded by Asana’s implementation (though some retraining and adjustment have been required along the way, since moving from projects-in-teams (now known as Associated Team) to teams-as-members-of-projects is a pretty big transition!). So “teamless” is definitely not “pointless” in my book!

A key to this is that a team still displays all of its projects, regardless of whether the project’s team membership is because a) the project specifies an Associated team, or b) the project specifies the team as a member (in the Share dialog), or c) both.

Any of the above results in the project being listed both in the Team > All work page:

and also in the team’s sidebar popup on hover:

And in both cases, the ordering is governed by the team page sort menu:

For many, these provide a good way to browse/navigate projects in teams without requiring a portfolio. The fact that Associated team can’t automatically be set is not an issue for them. (For the small subset of folks who have advanced save search reports using the Associated teams search criterion:

… it would remain an issue.)

Now I’ve always been a huge Portfolio stan (confession: when I saw that in your post, I had to look it up!), but more because of the other powerful features of Portfolios (Milestones progress column, and more recently custom fields, customizable tabs/tab views, grouping, filtering), and never encouraged their use simply for navigation. Also, I feel nested portfolios were more valuable before the addition of customizable tabs/tab views and grouping by custom fields (single- and multi-select). I find that many earlier uses of nested portfolios are more easily addressed this way, and you don’t have to worry about forgetting to add a project to multiple portfolios or not being able to easily specify the portfolio in a project template because you’re not sure which portfolio to use. There are still some helpful uses for nested portfolios, but it’s rarer now in my experience.

I hope that might help, and apologies for the lengthy post,

Larry

PS Update after original post.

• I wanted to add that @Skyler addressed some of these points but often with differences so I wanted to express my point of view even with some duplication.
• I hadn’t noticed @Kelly_Perry4’s last post before posting, so re:

  @Kelly_Perry4

  How are you working around the Teamless-by-default shift?

  …but I think my post addresses that.

[Jonathan_Gustavo_Pin]

Kelly, I also miss having a way to view portfolios like in your gif. Not just the portfolios, but the projects themselves. This is one of the only features present in other tools, like ClickUp, that I miss in Asana.

I run a marketing agency, and my setup is as follows:

Client A - Team. Inside the Team, a Portfolio (redundant, I know). Inside the Portfolio, the services (Projects). Paid Media Social Media Inbound

Each one becomes a project.

Honestly, I feel like portfolios would easily do the job, and I wouldn’t need to create teams for this.

But the Team overview, which allows you to add a note with the project details, is quite important.

Anyway, I think your suggestion would be great!

[Kelly_Perry4]

Thanks for this, @lpb ! I’m definitely in the retraining and adjustment period and your perspective is so helpful. I think between seeing others across the forum being told to, “just use portfolios,” and Phil’s comment that Associated Teams may be going away, I got a little spooked.

@Phil_Seeman

The “Associated team” is now legacy concept, might or might not stick around in the future from what I hear.

I’ve been perplexed by the projects being Teamless (and therefore missing from any reports that pull Team-specific data, but still showing up in the All Work tab. Your explanation makes a little more sense to me, but I’m still curious how do you approach the reporting piece? Or are you & your clients not often reporting on team-specific metrics?

I’m such a proponent of grouping by custom fields, I don’t know why I never considered it on Portfolios! Thanks so much for taking the time to give such a thoughtful reply.

[lpb]

Replying to my own post because I realized I had left something out, so I just edited it slightly to add:

The portfolio features that allowed me to simplify to one portfolio instead of using nested portfolios as much are customizable tabs/tab views (that’s the one I forgot to mention), custom fields, grouping by single- and multi-select custom fields and built-ins like “Owner.”

Thanks,

Larry

[lpb]

Thanks for the kind words, @Kelly_Perry4

@Kelly_Perry4

between seeing others across the forum being told to, “just use portfolios,” [. . .] I got a little spooked.

Very fair observation and understandable response. I’m really careful about these things because following unvetted advice can lead to unnecessary complexity and other problems. That advice may quickly address the problem, but not in the simplest way, and perhaps with downsides. I feel it’s simpler not to use portfolios unless you need to (like for reporting as described below). Otherwise it may be unnecessary, and you’ll regret it if you fail to keep in sync both your team and portfolio memberships for every project.

(For another (worse) example of ubiquitous advice that I recommend ignoring: So many Asana- and expert-provided examples, articles, project templates, AI-generated projects, etc. show “Status” and “Priority” custom fields and list view columns for all projects. I recommend against both for almost every project, except for a small minority of projects that might need one or the other, but almost never both at once. Sorry; this belongs in another topic!)

@Kelly_Perry4

how do you approach the reporting piece?

I only touched on this in my earlier post, so good question. My earlier answer was more addressed at the navigation question and to show that you could still see project memberships completely in two places (Team > All work page and sidebar team hover).

For reporting, I’d turn to portfolios since a) Associated teams may disappear ultimately, b) Associated team is not as convenient as before, and c) but mainly because reporting across teams will be simpler, better organized and more sustainable/maintainable with portfolios. First, you can use the portfolio’s dashboard tab easily if you want; another form of reporting now in the same place. And when using either (Saved) Advanced search reports or Universal Reporting, replace the use of Associated teams by specifying one or more portfolios instead. (This may mean you effectively need to keep the two membership lists (teams, portfolio) in sync, but only when you need to.

Thanks,

Larry

[ka_nishiyama]

Your explanations are very specific, detailed, and excellent.

Personally, I don’t fully understand the details yet, but wouldn’t it be better to use Asana Goals function?

[lpb]

Thanks, @ka_nishiyama!

Re Goals, maybe you can explain the connection, because I think the original question here is more about how to get along after the change to deprecate that projects must belong in a team.

Thanks,

Larry

[ka_nishiyama]

Thank you for asking, @lpb .

Let me try to explain the connection I had in mind.

The core issue in this thread is navigation and organization after the teamless shift — how do we find and group projects without relying on Teams as containers?

My thought is that Goals could serve as the top-level anchor that gives meaning to the portfolio structure beneath it.

Here is a concrete example from manufacturing (my context):
Goal: Complete Equipment Manufacturing – FY2026
│
├─ Portfolio: Factory 1
│ ├─ Portfolio: Equipment A
│ │ ├─ Project: Equipment A – Engineering
│ │ ├─ Project: Equipment A – Manufacturing
│ │ └─ Project: Equipment A – Construction
│ └─ Portfolio: Equipment B
│ └─ (same structure)
└─ Portfolio: Factory 2
└─ Portfolio: Equipment C
└─ (same structure)

In this structure:

• Portfolios handle the “where do I find this?” navigation problem (replacing Teams as containers)
• Goals handle the “why does this work exist?” question — connecting daily project work to
  organizational objectives

The key benefit: when a project is linked to a Goal, progress updates automatically. So instead of navigating through nested portfolios to understand overall status, leadership can check the Goal and see the big picture instantly.

I also think Goals could help solve the “onboarding nightmare” Kelly mentioned — rather than asking new team members to star a long list of portfolios, you can point them to the relevant Goal, which surfaces the connected portfolios and projects in context.

---

However, I have to be honest: the current Goals feature does not fully support this vision yet.

To make Goals work as a true top-level navigation anchor above portfolios, I think one of the following would be needed:

Option A – Upgrade Goals to include Portfolio-level views Bring the Map view, nested visualization, and navigation features of Portfolios into the Goals experience, so that
Goals become a genuine command center — not just a progress tracker.

Option B – Introduce a dedicated PMO layer Create a new feature above both Goals and Portfolios that serves as an organization-wide control tower: connecting strategic objectives, portfolio structures, and resource visibility in one place.

Either way, I believe the teamless shift makes this kind of top-level anchor more necessary than ever — because without Teams as containers, users need something higher up in the hierarchy to make sense of everything below.

I would love to hear how others feel about this gap, and whether a feature request along these lines would resonate with the community.

[lpb]

@ka_nishiyama,

Thanks for explaining; it helped me understand more of what you’re getting at.

I think you’re looking at a broader, more speculative/future-focused question than I was addressing.

My focus was on addressing Kelly’s concern and specific issues in Asana as it is today. I don’t believe that the removal of project-in-team makes so much difference due to the handling of team-as-member-of-project. Teams still have landing pages, (Overview) with curation facilities there, Knowledge, Goals grouping by teams, etc., so none of that has changed.

Treating Goals as the top of the hierarchy, as you suggest, has benefits. But shortcomings too. First, it’s a different model than the above, so it’s hard to see an easy separation of concerns as there is now (currently, Goals are just objectives and measures, which is clearly bounded). I think to load it down with so much more responsibility will make Asana too proscriptive for many orgs. Remember Asana must work for any size/type of org anywhere doing anything! I think that’s easier to deliver with good separation of concerns.

Also, remember that Goals are an Advanced/Enterprise feature. I think basic org hierarchy features must exist similarly in all plans, including Personal (Free) and Starter.

I’m not saying things couldn’t be improved, but my personal take is that I’m not convinced that’s the way to do it. But I don’t expect everyone will agree with me, so let’s see!

Thanks,

Larry