Maturity level

3. Main group of stakeholders is defined, however there is now clear understanding, who makes final decisions.

4. Main group of stakeholders defined as well as main responsible one — it’s needs fullfield first, others can be ignored.

4. Main group of stakeholders defined as well as main responsible one — it’s needs fullfield first, others can be ignored.

5. There is clear governance on the product, who is responsible for what. The main stakeholder is defined, however the needs of every person of interest are taken into account.

3. Tolerance: At this level, stakeholders know each others responsibilities, positions and plans so there are no overlaps in the delivery process. However, they are still working as separate entities.

3. Tolerance: At this level, stakeholders know each others responsibilities, positions and plans so there are no overlaps in the delivery process. However, they are still working as separate entities.

4. Engagement: Stakeholders support each other, share a vision and work as a team.

4. Engagement: Stakeholders support each other, share a vision and work as a team.

3. Stakeholders are involved in the decision-making process and actively participate in the product's life and development. However, their motivation is primarily driven by external factors such as KPIs, OKRs, bonuses, etc. They make decisions to ensure the product's survival, but may not prioritize its success.

4. Stakeholders balance their personal interests with the success of the product. They make effective decisions that help the product evolve and grow.

4. Stakeholders balance their personal interests with the success of the product. They make effective decisions that help the product evolve and grow.

4. Stakeholders balance their personal interests with the success of the product. They make effective decisions that help the product evolve and grow.

3. Designers have an overall perception of their responsibilities and stakeholder expectations, however struggle in specific cases of miscommunication.

4. The designers clearly understands the scope of responsibilities and expectations of his/her work.

4. The designers clearly understands the scope of responsibilities and expectations of his/her work.

4. The designers clearly understands the scope of responsibilities and expectations of his/her work.

2. Designers participate in meetings with final approvers, however they silently listen and write down the comments.

4. The designer is an active contributor to meetings with final approvers, as a trust-worthy expert.

4. The designer is an active contributor to meetings with final approvers, as a trust-worthy expert.

4. The designer is an active contributor to meetings with final approvers, as a trust-worthy expert.

1. Awareness: At this level, stakeholders are aware of the experience designer's role and responsibilities. However, they may not fully understand the designer's expertise and the value they bring to the project, so all the ideas from designers are ignored.

3. Confidence: At this level, stakeholders have confidence in the experience designer's ability to create effective designs. They trust that the designer has the expertise and skills to create designs that meet the needs of users and stakeholders. So they can accept some ideas beyond the direct responsibilities of the designer.

4. Partnership: This level involves stakeholders working in partnership with the experience designer. They actively seek the designer's input and collaboration in making design decisions. They understand that the designer's expertise is critical to the project's success.

5. Empowerment: At the highest level of trust, stakeholders empower the experience designer to lead the design process. They trust the designer's expertise and allow them to make design decisions that best meet the needs of users and stakeholders. This level of trust creates an environment where designers can do their best work and create designs that drive business success.

1. Awareness: At this level, businesses are aware of the existence of design as a discipline and its role in creating aesthetically appealing products. However, they may not fully understand the strategic value of design or how it can impact the bottom line.

3. Integration: At this level, businesses integrate design into their product development process and see it as a key component in creating successful products. They understand the importance of involving designers early in the process and allocating sufficient resources for design.

4. Investment: This level involves businesses investing in design by setting design goals, and allocating budgets for design research and development. They understand that design is not just a one-time expense, but an ongoing investment in their product's success.

5. Business-Driven Design: At the highest level of understanding, businesses see design as a strategic product driver. Design helps guide decision-making at the executive level. Business leaders understand that design is not just about creating attractive products, but about creating products that drive growth and achieve business goals.

2. Product vision is defined by management, but not communicated effectively to the team.

3. Product vision is defined by management and communicated verbally to the team.

3. Product vision is defined by management and communicated verbally to the team.

5. Product vision is collaboratively defined by the team and documented for all team members to access.

2. The product has multiple visions of stakeholders, who can’t align with each other.

3. Everyone on the team is aware of the product vision, however majority stays indifferent to it, but not blocking others to contribute.

3. Everyone on the team is aware of the product vision, however majority stays indifferent to it, but not blocking others to contribute.

5. Everyone on the team participates in shaping product vision, shares it and contributes to it’s achievement.

3. Product has some objectives it should achieve, however they are defined to a year and have no correlation with vision.

3. Product has some objectives it should achieve, however they are defined to a year and have no correlation with vision.

3. Product has some objectives it should achieve, however they are defined to a year and have no correlation with vision.

4. Product strategy is based on the objectives with key results connected to the product vision, however they are defined on a year and not refined earlier, only in the face of significant context change (pandemix, mass relocation, RTB, etc).

2. Product vision is based on team assumptions and speculations, lacking clear goals or objectives.

3. Product vision is collaboratively defined by the team with some goals, but they may be unattainable or lacking external context.

4. Product vision is based on factual data and has clear, achievable goals, but focuses solely on internal context.

4. Product vision is based on factual data and has clear, achievable goals, but focuses solely on internal context.

2. Product Manager responsibilities are not clearly defined or integrated into the team operations, but may be handled by someone on the team if necessary.

3. Product team members take turns fulfilling Product Manager responsibilities as needed.

4. The product team includes a part-time Product Manager or someone who shares the responsibilities with other duties.

4. The product team includes a part-time Product Manager or someone who shares the responsibilities with other duties.

2. The project has low potential for ramping down, but there are no clear plans for ramping up either.

3. The project is stable and has no plans for significant growth or reduction in scope.

3. The project is stable and has no plans for significant growth or reduction in scope.

4. The project has low potential for ramping up, but there are no clear plans for ramping down either.

2. Rapid staff rotation - There is very high turnover in the staff, with employees leaving and being replaced on a near-constant basis, often resulting in a high degree of disruption and instability.

4. Moderate staff rotation - There is some turnover in the staff, with employees leaving and being replaced periodically, but turnover rates are generally low.

4. Moderate staff rotation - There is some turnover in the staff, with employees leaving and being replaced periodically, but turnover rates are generally low.

4. Moderate staff rotation - There is some turnover in the staff, with employees leaving and being replaced periodically, but turnover rates are generally low.

3. Product aware of main players in the domain thanks to some market research, however the position isn’t determined and reactively floating.

3. Product aware of main players in the domain thanks to some market research, however the position isn’t determined and reactively floating.

3. Product aware of main players in the domain thanks to some market research, however the position isn’t determined and reactively floating.

4. Product has determined the position and positions of the main competitors based on market research. However it was a one-time activity and not adjusted through time.

3. Reactive feedback gathering — Business representatives actively seek out end-user feedback through surveys, feedback forms, or other methods, and make changes based on the feedback they receive.

3. Reactive feedback gathering — Business representatives actively seek out end-user feedback through surveys, feedback forms, or other methods, and make changes based on the feedback they receive.

4. Proactive feedback gathering — Business representatives actively seek out end-user feedback and use it to inform product or service development. They may conduct user testing or engage with customers to understand their needs and pain points.

4. Proactive feedback gathering — Business representatives actively seek out end-user feedback and use it to inform product or service development. They may conduct user testing or engage with customers to understand their needs and pain points.

4. Some legacy issues are recognized, but they are seen as minor obstacles that can be worked around rather than major barriers to innovation.

4. Some legacy issues are recognized, but they are seen as minor obstacles that can be worked around rather than major barriers to innovation.

4. Some legacy issues are recognized, but they are seen as minor obstacles that can be worked around rather than major barriers to innovation.

4. Some legacy issues are recognized, but they are seen as minor obstacles that can be worked around rather than major barriers to innovation.

2. Product has very narrow vision on what team can offer: suggestions can be taken rarely.

4. Everyone in the team has a right to suggest and give feedback, however there is some favoritism, where suggestions from elit groups are more valuable than others.

4. Everyone in the team has a right to suggest and give feedback, however there is some favoritism, where suggestions from elit groups are more valuable than others.

5. Equality is the main principle of the Product. Everyone can make any suggestions or feedback that would be seriously taken and processed.

2. Functional Integration: focuses on ensuring that design decisions meet the basic functional requirements of the product. Designers work to make the product intuitive and efficient, emphasizing usability and practicality. Failures are very cost consuming and should be avoided any price.

3. Strategic Alignment: design decisions are aligned with the strategic goals of the product and the organization. This involves understanding the market, competition, and the product's unique value proposition. Failures are unfortunate, but not critical events.

4. User-centric: design is centered around user needs and driven by data and analytics, including the effectiveness of user research and data-informed decision-making. Failure precepts as an experiment result.

5. Visionary and Innovative Design: represents the highest level, where the design process anticipates future trends and innovations. Failures welcomed and treated like a steps to the great product success.

2. Product scope tries to be defined, but due to outer reasons it can’t be stabilized, despite the team’s efforts.

3. The product scope is defined, however it’s stability is questionable: stakeholders can pivot the scope in the opposite direction in a matter of days with a high impact on current delivery iteration.

3. The product scope is clearly defined and protected by the team, but can be affected by urgent requests from the stakeholders with impact on current work iteration.

5. The product scope is defined and protected by the sign-off from the stakeholders. Scope changes only in emergency cases and not more then once a quarter.

2. There are some processes in place for managing change requests, but they are not consistently followed or enforced. Clients often take advantage of this inconsistency to push through their own agendas.

3. Change management is manual and reactive, with the BA or Manager handling requests on a case-by-case basis. There is little proactive planning or alignment with the project goals.

4. Changes follow an established process for managing requests, but there is limited impact analysis or consideration of the client's needs. The process is not always followed strictly, leading to some confusion and inconsistency.

5. Changes follow a well-defined process guided by the product manager, with a focus on minimizing disruption to the current iteration. The process is managed by the BA or Managers, and includes penalties for clients who push for unnecessary changes.

3. MFU or meeting minutes appeared occasionally, without further spreading between members of the delivery team.

4. Only key decisions are documented in the MFU or meeting minutes and spread within the team.

4. Only key decisions are documented in the MFU or meeting minutes and spread within the team.

4. Only key decisions are documented in the MFU or meeting minutes and spread within the team.

2. Research is conducted on an as-needed basis, often in response to a specific problem or question.

2. Research is conducted on an as-needed basis, often in response to a specific problem or question.

4. There is a formal research process in place, and research is conducted on a regular basis using a variety of methods. However the actionable outcomes are not sharable and have narrow goal.

5. Research is integrated into the product development lifecycle, from ideation to launch and beyond. Outcomes used as a generative fuel for new ideas and decision making.

1. No research is conducted or there are no research deliverables available to inform decision making.

2. Research is conducted, but stakeholders do not fully trust its outcomes and rely on other sources of information.

4. Research is conducted and used for decision making on a regular basis, but it is not yet fully optimized or integrated into the product development cycle.

4. Research is conducted and used for decision making on a regular basis, but it is not yet fully optimized or integrated into the product development cycle.

2. The data is used as a source of information for the project, but not as a key factor in scope control.

2. The data is used as a source of information for the project, but not as a key factor in scope control.

4. The data has a significant impact on the scope of the project, and can occasionally cause a complete reevaluation of priorities.

4. The data has a significant impact on the scope of the project, and can occasionally cause a complete reevaluation of priorities.

1. No data sources are available, making it impossible to collect quantitative data for analysis.

2. Basic data sources such as Google Analytics (GA) are available and connected to the product, but not much analysis is done on the collected data.

3. General metrics such as Net Promoter Score (NPS) and Customer Satisfaction (CSat) are collected and analyzed, but more specific data is not collected.

4. Event collection is implemented in GA (or any other quantitative source) and data is gathered based on user scenarios for analysis.

2. Only one main metrics used to define product health, such as MAU or DAU.

2. Only one main metrics used to define product health, such as MAU or DAU.

4. There is a formal process for monitoring product health KPIs. This list includes not only basic metrics, but also user scenario related metrics.

5. There is a formal process for monitoring product health KPIs. This list includes not only basic metrics, but also user scenario, business strategy and OKR-related metrics.

2. Stakeholders are indifferent to a KPI-driven approach. Data for them is not a decision-making tool.

3. Stakeholders are not against a KPI-driven approach and even use data for decision-making, but they have no initiative collecting it.

4. Stakeholders support the data-driven approach and use data in decision making process. They are always interested in data points of view on the problem.

5. Stakeholders fully support a data-driven approach and refuse to take any action before they see the data.

2. The manager covers it.

2. The manager covers it.

3. Designer or Manager takes this function.

5. The product has fully qualified Web-analytics in the team.

1. There is no person to communicate with.

1. There is no person to communicate with.

3. There is some formalized process of communication, but the person lives outside the delivery lifecycle.

5. Person fully integrated into delivery lifecycle, actively participating in all the ceremonies and providing valuable actionable input.

2. The value proposition of the product for end-users is partially understood by the team, but not clearly communicated or aligned on.

3. The value proposition of the product for end-users is clearly understood by the design team, but not by all other stakeholders.

4. The value proposition of the product for end-users is clearly understood by the design team and management, but not by all other stakeholders.

4. The value proposition of the product for end-users is clearly understood by the design team and management, but not by all other stakeholders.

2. Designers have indirect access to the users through the managers or stakeholders, however the insights they get are limited.

3. Designers have direct access to users, however they are not deeply involved in collaboration. The activities limited with user tests from time to time.

4. Designers have full access to end-users and they use this opportunity to gather user needs, goals, motives and evaluate design solutions. However, the activity peak was during discovery and currently designers collaborate with users on demand.

4. Designers have full access to end-users and they use this opportunity to gather user needs, goals, motives and evaluate design solutions. However, the activity peak was during discovery and currently designers collaborate with users on demand.

2. The audience description consists of demographical data and general guesses.

3. The audience of the product is described using a low level roles approach with functional requirements as a basis.

4. The audience of the product is defined and described through roles, goals, motives and tasks, but this information is not proved and used only for empathy and onboarding of the new designers.

5. The audience of the product is defined and described through roles, goals, motives and tasks, proved by studies and uses as a decision-making tool.

3. Designers have a partial understanding of user journeys, but have not documented or formalized their knowledge in any way.

3. Designers have a partial understanding of user journeys, but have not documented or formalized their knowledge in any way.

4. Designers have a good understanding of user journeys and have documented and validated some of them, but not all (typically the main flows).

5. Designers have a comprehensive understanding of all user journeys and have documented and validated them using a structured approach such as customer journey maps (CJMs), user flows, user stories, or other similar methods.

2. Design team is using a separate task-tracking solution.

4. Designers and developers using the same environment and work in one space, however their tasks are not connected (sub-tasks or dependencies are not used).

4. Designers and developers using the same environment and work in one space, however their tasks are not connected (sub-tasks or dependencies are not used).

4. Designers and developers using the same environment and work in one space, however their tasks are not connected (sub-tasks or dependencies are not used).

3. Designers use some ad-hoc or unrelated meetings to make priorities clear, but these sessions may not involve all relevant stakeholders or be fully organized.

4. Designers have some dedicated sessions with main stakeholders or product owners to discuss priorities and task relations, but these may not be fully structured or involve all relevant team members.

5. Priorities are set at the beginning of each iteration in structured meetings that involve all relevant team members, and they are aligned with the overall product vision and roadmap. Any changes or updates to priorities are communicated clearly to all team members.

5. Priorities are set at the beginning of each iteration in structured meetings that involve all relevant team members, and they are aligned with the overall product vision and roadmap. Any changes or updates to priorities are communicated clearly to all team members.

3. Tasks contain not only a title, but a short formless description of what should be done, sometimes with screenshots with red arrows.

3. Tasks contain not only a title, but a short formless description of what should be done, sometimes with screenshots with red arrows.

4. The tasks follow the organized structure including not only titles, but short descriptions and problem statements. DoR criteria are occasionally used.

4. The tasks follow the organized structure including not only titles, but short descriptions and problem statements. DoR criteria are occasionally used.

3. Stakeholders are kept informed of the design process through regular updates from the delivery manager or design lead, but visibility is limited to high-level information.

4. Stakeholders have good visibility into the design process, with regular status meetings and updates providing detailed information on progress and upcoming work.

5. Stakeholders have full visibility into the design process, with real-time tracking of designer workload and access to detailed information on current and upcoming work.

5. Stakeholders have full visibility into the design process, with real-time tracking of designer workload and access to detailed information on current and upcoming work.

2. The product has a backlog, but it's not strategically planned, and the team works on the backlog items based on what's next in line without any long-term vision.

3. The design team has a tactical roadmap for the next two months, but it's not integrated with a strategic plan for the product.

3. The design team has a tactical roadmap for the next two months, but it's not integrated with a strategic plan for the product.

4. The product has a well-defined long-term plan (6 months) that includes an epics backlog and a preliminary timeline, which is divided into short-term sprints.

2. The product team is aware of design debt, but never documented it, hiding behind «next releases» or «someday».

3. The design debt is documented and stored into a backlog, however the team is almost never revisiting it.

4. The design debt is collected and lives in the backlog, However, the frequency of it’s development is pretty low.

5. The design debt specified and implemented into the product backlog with a clear understanding, when it will be delivered. It’s also revisited at the beginning of every iteration.

1. Designers have very little time to think about the tasks and often have to provide quick solutions without much thought.

3. Designers spend 50% of the time thinking about the task and 50% actually performing it.

4. Designers spend 60% of the time thinking about the task and 40% actually performing it.

5. The time spent on thinking about the task and actually performing it in 80/20 proportion.

2. Innovative ideas are generated and passed to development without any validation or evaluation.

4. Innovative ideas are evaluated for both technical feasibility and business value before being passed to development.

4. Innovative ideas are evaluated for both technical feasibility and business value before being passed to development.

5. Innovative ideas are evaluated for user value, usability, business viability, technical feasibility, and other relevant factors before being passed to development.

4. The design and delivery processes work to support each other, but the relationship is not fully integrated or optimized for maximum efficiency and effectiveness.

4. The design and delivery processes work to support each other, but the relationship is not fully integrated or optimized for maximum efficiency and effectiveness.

4. The design and delivery processes work to support each other, but the relationship is not fully integrated or optimized for maximum efficiency and effectiveness.

4. The design and delivery processes work to support each other, but the relationship is not fully integrated or optimized for maximum efficiency and effectiveness.

3. The team uses basic practices from established design process frameworks like Lean or Agile, but may not fully embrace all aspects of the frameworks, resulting in limited effectiveness.

4. The team has defined a collaborative design process that is followed by everyone, but designers sometimes deviate from it or cut corners.

4. The team has defined a collaborative design process that is followed by everyone, but designers sometimes deviate from it or cut corners.

4. The team has defined a collaborative design process that is followed by everyone, but designers sometimes deviate from it or cut corners.

3. Designers use a set of predefined data that is representative of real user data, but not fully customized for the specific project.

4. Designers use a variety of close-to-real data content in their designs that is customized for the specific project.

5. Designers use real data content in their designs that is customized for the specific project and closely represents actual user data.

5. Designers use real data content in their designs that is customized for the specific project and closely represents actual user data.

3. Product adapts its design to different touch points, but only at a basic level, without considering the specific advantages and constraints of each platform. (Adaptive design).

4. Product adapts its design to different touch points, taking into account the specific advantages and constraints of each platform, but not fully utilizing all of them.

4. Product adapts its design to different touch points, taking into account the specific advantages and constraints of each platform, but not fully utilizing all of them.

4. Product adapts its design to different touch points, taking into account the specific advantages and constraints of each platform, but not fully utilizing all of them.

2. The product team acknowledges the importance of inclusive design, but does not actively pursue it.

2. The product team acknowledges the importance of inclusive design, but does not actively pursue it.

3. Designers take the initiative to conduct audits and incorporate inclusive design, but face resistance from stakeholders and development team.

4. Designers conduct inclusive audits, follow best practices, and actively educate stakeholders, but face ongoing challenges.

3. Designs are versioned with saving versions of the outputs on the hard-drive or in an external cloud (GDrive or Dropbox).

4. Designs are versioned with cloud-based default features of the toolset.

4. Designs are versioned with cloud-based default features of the toolset.

4. Designs are versioned with cloud-based default features of the toolset.

2. Design documentation includes only in-source annotations and comments. In addition designers could create on-demand states for particular pages and elements.

3. Design documentation includes a detail description of the components base attributes: atoms, size adaptations, etc.

4. The documentation consists of elements and components basic attributes and a detailed description of the behavior and edge cases.

4. The documentation consists of elements and components basic attributes and a detailed description of the behavior and edge cases.

3. There are sources of truth for designers and developers, but they are not in synch.

3. There are sources of truth for designers and developers, but they are not in synch.

4. There are multiple sources of truth for designers and developers, and they sync manually.

4. There are multiple sources of truth for designers and developers, and they sync manually.

2. The product has visual inconsistency, but in doesn’t influence much on user experience.

3. The product has randomly occurring inconsistencies in user experience or visual representations.

4. The product has consistent visuals and user experience with small exceptions for new pieces of functionality.

5. The experience patterns and their visual representation are consistent and fully reusable within the product.

3. There is some sort of communication established between design and front-end, but no actual responsible persons are assigned.

4. The design system implementation regulates by design and front-end representatives, but has no clear process.

4. The design system implementation regulates by design and front-end representatives, but has no clear process.

4. The design system implementation regulates by design and front-end representatives, but has no clear process.

3. Design system has visuals of the components and basic description of their behavior and usage examples.

3. Design system has visuals of the components and basic description of their behavior and usage examples.

3. Design system has visuals of the components and basic description of their behavior and usage examples.

4. Design system has full specification of the components, behavior, usage examples and edge cases explained with cross-links to storybook or analog.

3. The product uses a comprehensive design library of components that are reusable and consistent.

3. The product uses a comprehensive design library of components that are reusable and consistent.

4. The product has a design library with multiple front-end frameworks used, but they may not be fully integrated or consistent.

4. The product has a design library with multiple front-end frameworks used, but they may not be fully integrated or consistent.

3. The design team reviews work for each iteration.

4. The design team has design reviews three times a week.

4. The design team has design reviews three times a week.

5. The design team has daily internal reviews, sometimes with external experts invited.

3. Designers evaluate flows and screens using guerilla testing.

3. Designers evaluate flows and screens using guerilla testing.

5. Designers evaluate flows, not screens, using Qualitative and Quantitative methods.

5. Designers evaluate flows, not screens, using Qualitative and Quantitative methods.

3. Designers concentrate only on the happy path with some edge cases covered on demand.

3. Designers concentrate only on the happy path with some edge cases covered on demand.

4. Designed solutions contain not only happy path, but majority of edge cases.

5. Designed solutions contain not only happy path, but all edge cases with flexibility to scale in mind.

2. Design decisions are rarely validated with end-users.

3. Design decisions occasionally validated with end-users. Only high impact solutions.

5. Every design decision has a Quantitative or Qualitative basis under it.

5. Every design decision has a Quantitative or Qualitative basis under it.

3. Solutions are tested, however the testing approach is chaotic and never follows any guided process. So many bugs are missing in the backlog.

3. Solutions are tested, however the testing approach is chaotic and never follows any guided process. So many bugs are missing in the backlog.

4. Visual testing approach standardized, but not implemented (or in progress), so it’s still sporadic and not all the bugs put into a backlog.

4. Visual testing approach standardized, but not implemented (or in progress), so it’s still sporadic and not all the bugs put into a backlog.

2. There is a knowledge base or documentation available, but it is limited and not comprehensive enough for new team members to fully dive into the project.

3. There is a knowledge base and onboarding module available for new team members, and KT meetings can be easily scheduled on demand.

4. The team has a formal onboarding process with all information about the product, but it takes about a month for new team members to fully adapt.

4. The team has a formal onboarding process with all information about the product, but it takes about a month for new team members to fully adapt.

2. The team members just think that they know their roles and responsibilities, however their expectations are far away from reality.

3. Majority of the team understand their roles and responsibilities, however sometimes people overlap in the work they do.

4. Each member of the team understands his role and responsibilities. However sometimes expectations are inflated.

4. Each member of the team understands his role and responsibilities. However sometimes expectations are inflated.

3. The scope is significantly lower than a team’s seniority, so designers feel stagnation and overqualification.

4. The scope perfectly fits the design team’s seniority. However there is no points of growth.

4. The scope perfectly fits the design team’s seniority. However there is no points of growth.

4. The scope perfectly fits the design team’s seniority. However there is no points of growth.

3. The scope slightly exceeds the design team's capacity, occasionally causing designers to become bottlenecks.

4. The scope is perfectly aligned with the design team's capacity, allowing for efficient and effective design work.

4. The scope is perfectly aligned with the design team's capacity, allowing for efficient and effective design work.

5. The design team's capacity slightly exceeds the scope, enabling them to contribute beyond their primary responsibilities.

3. Designers provide options for solutions but avoid direct decision-making, and may not take responsibility for failures. Designers. Providing variants of the solution and consult with the better option from their point of view. However after failure try to avoid consequences.

4. Designers feel responsibility for the product success, try to find the best possible option and defend it in front of the customers. However if a failure appears, the responsibility for it vanishes in the air and the mistakes are fast forgotten.

4. Designers feel responsibility for the product success, try to find the best possible option and defend it in front of the customers. However if a failure appears, the responsibility for it vanishes in the air and the mistakes are fast forgotten.

4. Designers feel responsibility for the product success, try to find the best possible option and defend it in front of the customers. However if a failure appears, the responsibility for it vanishes in the air and the mistakes are fast forgotten.

2. Designers partly understand the product and the connections between the parts.

3. Designers fully understand the system with some exceptions, however they don’t see any gaps and improvements.

4. Designers understand the impact of their work on product success, and try to suggest some improvements and optimizations.

5. Designers have a holistic view of their work, including influence on the whole ecosystem.

4. The team has a productive atmosphere where team members are comfortable working together, but there is not much support and appreciation between colleagues.

4. The team has a productive atmosphere where team members are comfortable working together, but there is not much support and appreciation between colleagues.

4. The team has a productive atmosphere where team members are comfortable working together, but there is not much support and appreciation between colleagues.

4. The team has a productive atmosphere where team members are comfortable working together, but there is not much support and appreciation between colleagues.

2. The team is collaborating only on official occasions. Forced to do so.

4. The team is occasionally consulting with other streams and suits.

4. The team is occasionally consulting with other streams and suits.

5. The team is constantly consulting with other streams and suits, contributing to the ecosystem.

3. The delivery team is motivated enough to not avoid the work, however the new initiatives or additional value to the product is still out of their range.

4. The delivery team is highly motivated to do a good job and create a great product. Collaboration is easy, however still initiated by the design team or management.

4. The delivery team is highly motivated to do a good job and create a great product. Collaboration is easy, however still initiated by the design team or management.

4. The delivery team is highly motivated to do a good job and create a great product. Collaboration is easy, however still initiated by the design team or management.

3. Some best practices have been established, like ceremonies, but the efficiency of communication is still low. Retrospectives may be localized within individual teams.

4. A communication process has been established, but may not always be followed. Retrospectives are regular but may be asynchronous between departments.

4. A communication process has been established, but may not always be followed. Retrospectives are regular but may be asynchronous between departments.

5. Communication schemes are well aligned, all ceremonies are established, and communication is clear and effective with strong cross-departmental collaboration.

4. Designers have enough trust in the delivery team to suggest and defend their decisions.

4. Designers have enough trust in the delivery team to suggest and defend their decisions.

5. Designers have high trust in the delivery team to suggest their decisions without any confrontation, but support.

5. Designers have high trust in the delivery team to suggest their decisions without any confrontation, but support.