Design Systems Slack “Ask Me Anything,” September 2019

A question and answer session with Jina Anne and Dan Mall.

By Jina Anne + Dan Mall — 11 October 2019 at 09:43:30 am

On Wednesday, September 25, 2019, design systems consultant Jina Anne and SuperFriendly CEO Dan Mall did a 2-hour AMA session on the Design Systems Slack account. Topics covered included:

  1. Multiple teams using a design system
  2. Growing a design system team from scratch
  3. What to do after making patterns
  4. The design system reference site
  5. Connecting design system teams to product teams
  6. Shared naming conventions
  7. Splitting time between product and system
  8. Contributing to design systems
  9. Component documentation and responsibility
  10. Working with remote teams
  11. What’s next for design system teams
  12. Where do UX guidelines belong in a design system
  13. Should startups have design systems?
  14. KPIs for design systems
  15. Snowflake components
  16. Design systems for agencies
  17. Getting buy-in
  18. Outreach and materials for design systems
  19. VR & AR in design systems
  20. One framework or multiple?
  21. Systematizing animations
  22. Shifting priorities for maturing design systems

Here’s the full transcript of that AMA session.

Multiple teams using a design system 


How do you deal with multiple teams building their own version of components and avoiding a common set of existing components?


Ah, already with an it depends answer.🙂

I think it’s common/natural to want to consolidate all these efforts. And a lot of the time, that makes sense.

But I’ve found in my experience, sometimes it’s necessary.

Simple Example: A company having a product design system and a marketing design system. In some cases that makes sense, especially if the editorial site needs are vastly different from what the product needs.

A more extreme example, Amazon has like 20 design systems. But that’s because the end user and the features are so different. The fullfillment factory workers using a device to scan boxes uses a very different design system from shopping on their website, versus AWS, versus Twitch, versus Zappos, etc. They might have a global language of type and color on most of the systems, but the component needs are so vastly different.

So for the case that you do want consolidation, I think it’s important to not do this:


In other words, don’t create a new standard and try to force it on everyone else. That never goes well. I think it’s better to get those different teams together and talk about where things might make sense to share, and what things should be prioritized — whether it even makes sense to do so.

Growing a design system team from scratch 


We recently lost our main designer for design systems and we'd like re-staff this team to 2 roles. We have design tokens and a growing component library that our devs are increasingly contributing to. We're thinking a product designer and engineer experienced in design systems makes sense. We have a brand designer that's looking to step in one of the roles but I wonder about gaps in responsibility and experience. What roles or attributes are must-haves for regrowing this team? Specifically, what qualities should a designer have?


It’s a good call to be sensitive to what skills team members should have! Before I add more, Leslie, what other roles already exist on the team? Or is the team now down to 0 members?


We’re down to 0 😔


Ah, a tough situation! But there’s hope! I’d say the most crucial skill for the first (or first, again) role on the design system team is not tactical but political. The skill this person needs is to be able to make friends. So much of the success of a design system at an organization depends on how amenable product teams are to the idea of a design system.

If your brand designer is particularly surly, they might have trouble getting anyone to even give the design system the time of day. But if they’re good at building bridges, it’ll more easily expose what the design system needs more urgently than other things. Then, the “making friends” skill comes in handy again to delegate the production tasks for the things that need to be designed and built that the brand designer may not be personally equipped to tackle.


should I advocate for a product designer in addition to the brand designer and UI engineer? I see design systems as a internal product and I worry a lack of technical understanding when working with product dev teams means some responsibilities falls heavily to other product designers not on the team.


Absolutely! This is from a deck I often share with teams, but this is typically what I’ve recommended for what a design system team ideally looks like. (No surprise: this looks like the structure for any great product team.)

A model design system team

But, no pressure to have this from the start. It’s totally fine to build up to it slowly.


This is great, thank you!

If you had to choose between a product designer or brand designer joining a systems team, what would you do?


For me, it’s less about the role than it is the person. Which one plays more nicely with others? That’s the one I’d pick for this team 😉

What to do after making patterns 


Our team is wrapping design system visual patterns, what should we consider next?


Make products! This is really one of the best ways to know for sure that your design system works. The faster you can put the patterns into practice, the more realistic data you’ll get about how well they’re working.

The design system reference site 


What do you think is the most important part of a successful Design Systems website? We’re doing our 2.0 site now and would love to hear the pitfalls.


Ah and here I ask… do you even need the website? 😉 In all honesty, I think getting the process down to improve people working together should be prioritized over a site. But since you’re on v2, you already have one. In that case, and assuming you already have component docs in place… I think a really good release notes is crucial. If you can indicate what’s added, what’s changed, maybe even show that visually and reference where? That can be one of the most important things for devs, pms, etc to see.


Totally agree with Jina!

If I were to construct a hierarchy of needs for a design system site—hey, blog post idea!—it’d probably go something like this:

  1. Priority 1: what helps a design system user right now?
  2. Priority 2: what helps a design system user in the near future?
  3. Priority 3: what helps a design system user in the longer-term future?


What helps a design system user right now?

How to use the system. Getting started, installing the design system (is it copy and paste or package-managed, etc), stuff like that. Component documentation. Lots of on-the-ground, nitty-gritty, in-the-weeds, other-hyphenated-phrase stuff.

What helps a design system user in the near future?

Knowing what to do next. What if a component doesn’t exist? What if a component kinda exists but needs modification? (This flowchart from the Ubuntu team is awesome). What else can I do with this design system?

what helps a design system user in the longer-term future?

Becoming a better professional. Guidelines are incredibly valuable here. Developers can become better designers by using the design system, and vice versa.


Thanks to you both! Never considered not having one. 🙂 But I think it serves a purpose particularly for external adopters and contributors (we have external vendors who build stuff based on our system).

Editor’s note: our design system for The Cosmopolitan of Las Vegas was created almost exclusively for external vendor use.

Connecting design system teams to product teams 


What are some processes and/or tools to help product teams' designers connect with the design systems team? The design systems team could hover over every project, but we lack the capacity to have total awareness and we'd like to promote product teams to take initiative—particularly because we're at the early stage where the component library is being built.


Well, I think looking at the design system as a shared ownership rather than a DS team “hovering” is the first thing. team models are different, but it sounds like you have both a centralized team and product designers. Here is an article about how we handled that at Salesforce, which is based off the models Nathan Curtis wrote on.


Great point! I think we need to do a better job of advocating and communicating shared ownership. Thanks for the resources 👍🏼

Shared naming conventions 


Do you use the same naming convention for elements as developers? I mean like BEM (block, element, modifier) or something similar. If you don’t, why not?


I definitely try to! Though I’ve been in a large organization where that was very difficult, so we explored a taxonomy that had “aliases” which could help our doc search. 🙂

Splitting time between product and system 


What are the most important things to focus in the design system if you're a solo designer early in their career with little experience in design system? The relationship I should build with the front-end engineers and how much of a collaborative effort it should be, how to maintain while doing product design work, etc.

I'm part of a small startup where there are about 2-3 front-end devs and 9 engineers in total working on the product.

  1. Could you expand on how I should go about splitting product design work and design system maintenance? So far, I've done 4 days of product design work and 1 day for revisions for product design work and design system.
  2. It seems to me that it's always good to work on the engineer who is building it but often at a small startup that doesn't happen. Would this mean I need to evangelize the collaborative effort more and set time for it?


how I should go about splitting product design work and design system maintenance? So far, I’ve done 4 days of product design work and 1 day for revisions for product design work and design system.

That sounds like the right split to me. Design systems are about making better products, so a 80/20 product-to-system proportion seems appropriate. (The Pareto principle wins again!)

It seems to me that it’s always good to work on the engineer who is building it but often at a small startup that doesn’t happen. Would this mean I need to evangelize the collaborative effort more and set time for it?

Yes and yes! If you need some tips, Brad Frost and I made a video about why the designer-developer collaboration is important. We also talked about it with Aarron Walter and Eli Woolery on the Design Better podcast.

Contributing to design systems 


Our team is 150+ engineering and we’re seeking process for others to contribute or implement to the system. Any resource you would recommend?


adding to this, any tips for incentivizing contributors? How do I make it appealing for engineers across the company to contribute rather than wait for the 2 systems Engs to eventually do it for them?


I would definitely try to make contribution accessible to designers. If it’s all in a react codebase, that can be tricky. So maybe have some docs pull from a Quip or Google Docs folder. I’ve seen folks use APIs to pull this stuff in. Or if you’re using something like InVision DSM that has a style guide generated, you can pull things in from there.

On incentivizing — crediting contributors is probably the easiest thing. They can then show their managers how much they’ve contributed.

A silly thing but seems to work, when it comes to incentivizing contributors. If you have a team all hands meeting, you can shout out top contributors. Maybe even give them some fun trinket or gift card.

If you have the bandwidth and some sort of internal employee dashboard, you can add a leaderboard. I know, gamification is cliche. But you’d be surprised how much this can motivate folks.


I love the team model examples that Jina and Nathan Curtis have written about and continue to point back to them:

The Federated and Cyclical models resemble pieces of something a lot of us are more familiar with: an Open-Source model. If you think about how a product like WordPress is managed between Automattic employees, WordPress core members that don’t work and Automattic, infrequent contributors, and the masses that use WordPress but never contribute to it (and likely never will), there are some really good parallels to how a design system grows (or doesn’t).

Thinking about it that way, I love the guides that exist at Open Source Guides, especially the ones about Starting an Open Source Project and Building Welcoming Communities.

Component documentation and responsibility 


What should design/UX be documenting in terms of accessibility for individual components, and what should be left to dev or other areas to determine?


I would never consider anything in accessibility to “be left to dev.” i think anything and everything you can do from the design/ux perspective can and should be done, and then in every step of the process as it gets into production. it should be a shared ownership.


Not sure if this was intentional, Penelope, but the way you phrased your question made me wonder if your frame of reference is that the designers/UXers job is one of documentation. I believe it’s everyone’s job to document. We all have different experiences and expertise in our heads, and one of the great promises of a design system is to extract and collect that expertise in one place so it can be better distributed. So, designers can document what they know about accessibility (typically things like color contrast, type sizing, etc) while developers can document what they know about accessibility (typically code-related things like how to properly use aria- attributes and manage focus states). Accessibility specifically is something that many disciplines can equivalently contribute to!


I agree that it’s got to be a shared responsibility. My challenge (and why I asked this question) is that accessibility wasn’t baked into our culture—though it is growing—so it’s often a matter of it either being overlooked, added on, or having to be retrofitted. When I started here, I began championing accessibility, and as a result, I am often viewed as the expert and expected to know it all, but also expected to not “tell people how to do their jobs.” So I guess I’m really looking for guidance on how to get all the teams on the same page, speaking the same language, and I was hoping to use the design system we’re building to start that.


I’m really looking for guidance on how to get all the teams on the same page, speaking the same language, and I was hoping to use the design system we’re building to start that.

Ah, gotcha! Thanks for sharing that context, Penelope. (Warning: I’m gonna get all quote-y here.)

The Salesforce team (I think?) shared the mantra, “Make the right thing to do the easiest thing to do.” And I’m a big fan of the George S. Patton quote, “Don’t tell people how to do things. Tell them what to do and let them surprise you with their results.” So, to your comment…

When I started here, I began championing accessibility, and as a result, I am often viewed as the expert and expected to know it all, but also expected to not “tell people how to do their jobs”

…perhaps the role you might play is to tell a developer (either in a conversation or through documentation) that, for example, when a page changes state, anyone using the page should know what changed. That leaves some room for a developer to explore focus management, aria- attributes, etc. I know there might be right-er and wrong-er approaches to this, but perhaps let the developer discover that in their journey to the solution, even if you know the “right” answer. Then, encourage that developer to document their solution so that others can benefit from it. I think that kind of inclusive design process builds ownership in people and motivates them to be more involved and invite others into a welcoming space too.

Working with remote teams 


What if a portion of the dev teams are contractors and also remotely located? How would you approach the ownership aspect differently, or does it really matter?


I think the ownership model still applies, though the dynamic of executing it might change a little. Sometimes, remote team members are only physically distant but mentally engaged and invested. Other times, remote team members are both physically and mentally distant. Mandy Brown has a really great article for making remote teams work.

What’s next for design system teams 


Given your experience working with lots of different teams, answering questions, giving talks. What do you believe is an aspect of systems work that design systems teams aren’t thinking about at all or enough about yet?


I think people get fixated on the style guide website. The website you create is not your design system. It’s a representation of your design system. So i’d rather see folks get their processes and methods right. The site is just one part of that. remembering that it’s not about the artifact (though it’s nice to have one to rally around) but about the people and how they work together.


I wish designers were thinking more about what else they could help with organizationally if they weren’t bogged down with the details of design components. I think designers’ thoughts and approaches are more valuable than the pixels they push, and it bums me out to think about all the things designers haven’t done because they’re too busy designing a table for the 800th time in their career.

Like Josh Clark says, “The most exciting design systems are boring.” If designers could quickly get through the boring stuff, put it in a design system once and for all, imagine all the good they might do with the newly found free time!

Where do UX guidelines belong in a design system 


Where do you share (if at all) the overall content architecture/writing and UX playbook type guidelines that help provide structure and definition to creating user experiences that are not component specific?

Design systems focus on the artefacts and component library, but there's so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.


I would suggest that when you say “Design systems focus on the artifacts and component library,” it’s not that design systems do that. it’s the practitioners. i mentioned this in another question, but the website (and ui kits and other artifacts) are only a representation. so when you say “but there's so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.” i totally agree with you. if you do have a website, you can certainly include these. But the information architecture can get tricky. I like how Material has clear guidelines around navigation patterns or when to use a notification with the anatomy, behaviors, usage, etc.


Design systems focus on the artefacts and component library, but there’s so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.

That’s right! Design systems ultimately exist to help teams make better products, so guidance about UX and content is certainly not out-of-bounds.

Polaris navigation

Jina’s right that it becomes a taxonomy challenge. I love the way that Polaris deals with this by calling Content out right up front, and first. That’s a heck of a line in the sand they’re drawing about what they believe is important to the product experience.

Should startups have design systems? 


Do you think that setting aside or hiring dev resources to create a design system for a start up that's in a high growth stage has value? I am struggling to be more nimble in our design/dev processes. I feel like that having a common design system between design and dev with a common component library could be the answer. But I'm having trouble rationalizing the amount of work against large business opportunities that are coming up. Any tips or advice?


this is another “it depends” answer — as in what all are you thinking about when you say “a design system”? i don’t think you need to hire them to build a beautiful, gorgeous website on par with lightning or material or carbon. especially if you’re in a growth stage. but i certainly think there’s no time that’s too early to think about your design and UI engineering in a systemic way. you can build as you go, when the need arises (not creating just to create but only adding to the system when there is a need). in that case, i argue it’s not a lot of extra work because it’s work you’re already doing to build the product. 🙂


I’ll be more hard-lined on this. (Jina’s always so nice 😉 )

Do you think that setting aside or hiring dev resources to create a design system for a start up that’s in a high growth stage has value?

No. Build products. A design system is both an optimization and an investment, neither of which a typical startup has in excess. Any good engineer knows that too much pre-optimization is a waste of time. And when I talk about investment, I mean “a short-term loss to get a long-term gain.” Short-terms gains are more important to most startups than long-term gains, especially at early stages. Build products that your customers can use, find market fit fast, hone your value proposition. Then you can make a design system as you start to stabilize.

KPIs for design systems 


I struggle with setting good KPI’s, any suggestions which kpi’s we could measure as we roll out our very first design system that we could share with org, engineers, teams and or leadership?


so a lot of people might jump into talking about tracking lines of code deleted, colors consolidated, performance benefits — and all those are good and you should track. but i get really interested in the team communication part, and how the metrics you’re tracking align with your principles. I [wrote about that a little bit [on Playbook]](


The most talked about benefits of design systems tend to be around more efficiency and better consistency, so the surface level KPIs I’ve seen tend to center around those. Things like (all of these compare before having a design system to after having one):



There are also more great articles that people are writing about this topic.

Where I think it gets really interesting is when you think about your specific organization’s KPIs. For example, if you work for a healthcare company, you might tie your design system efforts to a larger company-wide effort to, say, book more doctor’s appointments or book doctor’s appointments in less time or less clicks. That’s the stuff that gets me excited.

Snowflake components 


How do you track and measure, re-evaluate snowflake components that were built by contributors that originally don’t meet the robust requirements of being a core component? When is the right time to re-visit, improve, or deprecate?


so one of my mantras is that not everything has to be in the system, and not everything has to be from the system. it’s totally okay to have special snowflakes. but they don’t need to be in the system. now if you’re in a situation where it already went in, then depending on your situation it might be trivial — or not to remove it. at salesforce, it definitely was not easy because we had an open source framework that like a gazillion third party devs were using. so we had to have a deprecation strategy. we created a tool called Sass-Deprecate to help with this, but even still, it’s hard. It takes lots of support and coordination. However, if you’re not open source to a huge community like we were, and you have control over where it’s being used, then hopefully it’s a lot easier to remove it from the design system (but keep it in the product if it’s needed). 🙂

Design systems for agencies 


I am working on pioneering design systems for an consulting agency that I work for. This has meant 1-1s with principles and giving lunch and learn talks to give awareness to the company and gain feedback on how we can implement design systems into our company. Our clients are normally in the field of B2B and most products that we ship are dashboards.

What are the pitfalls that we should look out for when creating a “micro” design system, duplicating that when we get a new project and using it as a foundation for the clients deign system?


i’m brand new to the consulting world so i should let dan take this one. but my initial gut answer if you’re trying to use a system for all your clients is to consider having a “skeleton” system of just your bare bones parts to pick and choose from for each client, with just the required structural, interactive bits to make it usable/accessible, with nothing in there that’s opinionated (art directed). then tailor that to your clients through design tokens and additional css to extend on it? curious to see if dan has a different answer!


Totally with Jina here (no surprise)! I think it’s useful to distinguish a boilerplate from a design system. There’s certainly good overlap between the two, but they are separate.

An important question I’ve seen many agencies face is whether or not they want to be known for a “house style.” Some agencies pride themselves on doing unique things for each client; others agencies relish doing the same kind of word repeatedly to gain efficiencies. An agency design system wouldn’t really be that useful in the former scenario, but it’d be incredibly valuable in the latter.

I love Dave Rupert’s thoughts on this. Rather than having one agency-wide monolith of a design system that you use on every project, use the same amount of effort to delivery “tiny bootstraps for every client.”

Getting buy-in 


We have buy in from EVERYONE at the company except for the CEO, who says that we’re still too small for a Design System (series A, 35 employees), but the product and website are becoming more and more fractured and distant in their presentation and the dev-led design that started with this company is really starting to get stale. How do you get C-Level buy-in? is it just a case of completing a UI inventory and setting up an MVP on our own time to show how much quicker devs and designers can iterate with it in place?


How do you get C-Level buy-in? is it just a case of completing a UI inventory and setting up an MVP on our own time to show how much quicker devs and designers can iterate with it in place?

In order to get someone to listen, you have to speak their language. Interface inventories and higher quality iteration is the language that designers and developers speak. The language that C-level folks speak—and please forgive the overgeneralization—is money. Show them how not having a design system means the organization is hemorrhaging money or wasting resources. Show them how that MVP you made on your own time can save them money, especially when it happens at scale.

One of my favorite examples of literally showing the pain is when Brent Hardinge printed out thumbnails of every website made by hand, put them on mounting boards, and walked into an executive meeting. That really drove the point home.

Also, Josh ClarkBrad Frost, and I talked a bit more about selling design systems to the C-suite in our Design System video series.


Another answer: go rogue. 😉

Outreach and materials for design systems 


What types of outreach materials and support offerings have you found to be successful for an enterprise with a variety of products and stakeholders? Things like ways to communicate updates, or present the visual materials, or to offer trainings and workshops, or other methods? Basically - how do you keep the system top of mind, and offer “hooks” to keep fragmented teams looking to the DS team for guidance? (Sorry, that kind of ended up being two related questions, thanks!)


as many as you can humanly do! i’ve done office hours, advisory boards (with folks represented across different disciplines or features or products) and documenting what’s discussed and distributing, brown bags/workshops, documentation, email/slack/whatever other internal messaging tool updates, definitely release notes… at salesforce i even worked on a dashboard design that showed a very visual diff (token diffs, html diffs, css diffs)… we even made a chrome extension for our engineers to show a “grade” on implementation…

i’ve seen some even do a newsletter. some of the design systems teams at amazon did. i think shopify’s polaris does too.

and one team at amazon even did a video of “what’s new”. those were fun to watch

VR & AR in design systems 


ooh i’ll ask Dan a question. 😀 have you explored other less-discussed areas of design systems yet like voice UI or AR/VR? if not, do you have interest in doing so?


have you explored other less-discussed areas of design systems yet like voice UI or AR/VR?

SuperFriendly’s pitched it a few times, but so far, no client has taken us up on it yet 😉 . (Most of them have answered something to the effect of, “Let us at least get all of our buttons in order first and then we can talk.“)

if not, do you have interest in doing so?

For sure! I think there’s a lot of ripe area here, especially as a lot of voice interfaces are improving from better machine learning. Not only can products get better by incorporating voice interfaces and AR, but AR can also improve the collaboration process. Airbnb opened the door with their whiteboard-to-code demos, and I think AR + AI + Machine Learning can help us turn this into a more explorative state.

Now, to find a client that’s willing to try it out. Minority Report, here we come!

One framework or multiple? 


For mid-sized organizations with multiple frontend web development teams and a fledgling design system, do you think the flexibility of allowing teams to choose their own preferred web component framework ever outweighs the benefits of standardizing around one?


i’m a big fan of agnostic design systems work, personally. especially with frameworks coming and going all the time. but there are pros and cons to that, as you’ve implied in your question. it is easier to just deal with one framework. so if you’re starting from scratch, by all means do that. but if you have existing products in existing frameworks, it may not be worth the effort to consolidate. unless you can make a really good business case for it, keep things agnostic. design tokens are one small piece that can certainly help with that.


I think it depends what your organizational priorities are, and what types of technical debt tolerance the organization has. Generally, I’m a fan of how Brad Frost describes managing tech-agnostic design systems.

Totally agree with Jina that one framework is easier. But sometimes the path to getting to one framework is too steep and is worth the technical debt and variance that an agnostic system with different flavors can bring.

Systematizing animations 


How do you systematize animations? *Bonus points for transitions between glyphs in your icon system?


Also, what’s your definition of reduced-motion?


full disclosure, i’ve not worked on this, but rather with people who have worked on this. putting things into a vocabulary like “pop, duration instantly” is easier to discuss across design/engineering than getting into the milliseconds, especially if you have various platforms. i’ve seen design tokens help with this. but most orgs i’ve worked with have also worked alongside a library like lottie. i wish i had better answers for this. val head and sarah drasner are the experts on this for sure. 😜

hmm. as for the reduced motion question, my intuition says if they’re turning it off, they don’t want motion… so i’d probably have no motion at all if possible for that scendario


The way my teams have done it is similar: establish a set of presets that can be modified when applied. I like how the Carbon Design System team explains it. They have 2 styles of motion: productive and expressive, and they’re applied as parameters to a motion method: motion(entrance, productive).

If I could get animation philosophize-y here, there’s something… dissonant… about the idea of “systematizing animations.” Animation (especially as compared to “motion”) is about “bringing something to life,” and “systematizing” and “bringing something to life” feel at odds a lot of the time.

So, the way I tend to approach motion is to try and understand the “world” of the interface. Is this a 3D or a 2D space? Do elements follow normal physics? What are the rules for how elements supposed to interact with each other, and when are we free to break those rules?

In the work we did with Khan Academy, we talked a lot about the rules of the “world.” If you look at the hero illustration, the red dot has inertia when you move your mouse closer or farther away. That set up a metaphor for how to animate other elements. It was less about making sure they used the same mixin than it is that they should follow the same concept.

Another way to describe that is that what I mentioned ☝🏽 is a very “designer-y” way of thinking about animation, while “systematizing” is a very “developer-y” way of thinking about animation.

Shifting priorities for maturing design systems 


In my experience, starting a design system is about focusing on process, adoption, and scale. Do you have any insight into how priorities shift once a system has stabilized and matured a bit?


for sure. this definitely happened for us at salesforce based on the adoption. we were targeting designers and third party engineers first, with the goal to target our own production engineers later (since they all said they weren’t ready for it and it’d be 2 years or so before they even adopt a button). but once we got the design system going and people saw it, our product engineers started using our stuff anyway — and not in a way we wanted them to (they were copy/pasting code). so we shifted our priorities to focus on supporting and enabling them to adopt it in a maintainable, scalable way.

also, i think the priorities should always be revisited. Nathan Curtis wrote about a worksheet he uses to help with this. i actually ran it with my team at salesforce even though we were already a year and half into things, and it helped us either modify or validate our priorities. there are other methods to do this too. but the point being it’s always good to revisit.