Prioritizing product requirements in alignment with product objectives

In all my earlier blogs, I was focusing on discovering and anticipating needs and who can help Product Manager discover those needs. After Product Manager collate all possible needs and start drafting requirements, there will not be dearth of product requirements but the next challenge is to prioritize those requirements. Product roadmap is a reflection of the product strategy and rightly so, product strategy should provide guidelines on what requirements to prioritize and it should also provide justification on why those requirements have to be prioritized.

Identifying Product objectives (aka Goals)

Product vision is the foundation for any product. Product vision encompasses everything related to the product – who are the customers, what does the product do, what is the competitive edge of the product, what is the unfair advantage that product has over competitors and finally what are the product objectives (how does the product help accomplish organizational goals). Rightly so, product vision provides guidance for every decision making related to the product – How sales should sell the product, how engineers should build the product, how marketing should promote the product and how Product Manager should draft the product strategy. Product strategy outlines the path to accomplishing product objectives abiding by guidelines laid by product vision. Let me revisit the product vision again and dissect it. At a high level, product vision embodies the following:

  • What needs to address?
  • Which customer segments to target?
  • What is the USP of the product? How effectively does the product will address the needs?
  • How the value is captured?

A little deeper look will reveal that product vision has 2 broad categories

  1. Product purpose
  2. Product objectives

Product Vision

Product Purpose (Customer Centric) Product Objectives (Organization Centric)
·        What needs to address?·        Which customer segments to target?

·        What is the USP of the product? How effectively does the product will address the needs?

·        How the value is captured?-   Increase in profits

–   Expansion into new markets

–   Opportunity to cross sell other products etc

 

Product purpose and Product objectives do change as the customer needs evolve, organization growth objectives change and product traverses through various stages of the product life cycle (launch, maturity and decline). Understand from your CEO or VP Product Management, how the product should contribute to overall organizational goals, accordingly Product Manager has to formulate product objectives. Product Manager would later perform thorough analysis of customer, market, competition and technology to understand what kind of augmented needs are valued most by customers and how effectively do those needs has to be addressed to achieve product objectives. In short, product prioritization process is all about identifying the set of requirements that fits within the framework of product purpose and yet has the potential to collectively accomplish product objectives.

Identifying attributes

When Product Manager starts prioritizing requirements, there should be an effective mechanism to understand how each requirement contributes to both product purpose and objectives. So we identify attributes (related to both purpose and objectives) that can help measure how each requirement is contributing to the overall product vision.

Attributes of product purpose

Product addresses lots of needs, but there should be some primary needs that focus on the key pain points of the customers. I call them as core services and rest of them are allied services. List some of the core services as attributes. For the sake of discussions, let me assume a fictitious B2B IoT product targeted for retail stores that help in following

  • Insight – Provides insights on how customers are accessing the store
  • Generate revenue – Notifies customers through smartphone about the availability of goods that might interest them based on the behavioral pattern
  • Cut costs – Eliminates the need for sales person by flashing all information about goods on his/her smartphone
  • Operations – Aid in ordering of goods that are brought together (replicate Amazon model)
  • USP – Does the requirement contribute to enhancing the USP? In case of the fictitious product, the USP could be as simple as ‘easy to use’, ‘easy to maintain’, ‘compatible with all mobile devices’, ‘mobile payment to avoid long queues’ etc

Pick relevant attributes that represent the augmented needs and assign weights in accordance with how customers value them. Efficacy of product prioritization process lay in effectively picking the attributes that are valued most by the target customers. Existences of those attributes in the product should provide compelling reasons for target customers to buy the product.

Attributes of product objectives

Product manager identifies similar attributes for product objectives as well.

  • Revenue – Does the requirement directly contribute to increase in revenue
  • Customer – Does the requirement is applicable to all possible target segments or to only a section of target segment. It is an essential attribute if the focus is on expanding market
  • Competition – Does the requirement provides competitive edge or merely puts the product on par with competition
  • Cross sell – Does the requirement facilitate sale of other products
  • Stickiness – Does the requirement increase the switch over costs or create a stickiness factor facilitating recurring revenues

I have dropped down all possible attributes that I could imagine. I suppose it would be ideal to stick with utmost 3 attributes in purpose and utmost 2 attributes in objectives, otherwise the weights would be thinly scattered and it might be difficult to effectively prioritize the requirements.

Scorecard technique – Brainstorming

Every product would have a distributed team of Product Managers, each managing different components of a product or separate target markets or combination of both. The process of adding weights combined with brainstorming exercise would ensure that the respective Product Managers have done due diligence in evaluating each of their requirements, so relative prioritization could be done lot better.

There is no better option than brainstorming to discuss, debate, and argue on the ability of each of the requirement to contribute to product objectives. Brainstorming session when done effectively provide revelations that was not comprehended before by the Product Manager or rather by any other participant. How many times have we felt ‘Oh GOD, I never thought about it’! Brainstorming would help to identify such facets never thought earlier when done effectively. Efficacy of brainstorming sessions lies in the following

  • Each participant should challenge and be willing to be challenged.
  • Each participant should build upon the thoughts of other to add better clarity to ‘WHAT’ and ‘WHY’ of each requirement.
  • There should be a commonality of purpose, vision and direction among all the participants
  • Each participant should engage in dialogue. In dialogue participants aim for collective good and not for win of any specific participant
  • The session should be skillfully facilitated by one of the Product Manager

Much of what I had described above was borrowed from a book called ‘The Fifth Discipline’ by Peter M Senge, the book offers lots of tips for effective and efficient brainstorming session.

The process might be chaotic, exhausting and mostly Product Manager might feel tired about justifying each need. Yet such process adds pluralism ensuring healthy discussions and debates among divergent minds leaving no room for human errors in prioritizing requirements. The exercise is also an attempt to prove everyone that product requirements prioritization exercise is driven by a process backed with data and does not happen as per whims and fancies of the Product Manager.

It is also on opportunity to introduce BIG PICTURE to the engineering team:

  • What are the lists of product requirements?
  • Which segment of customers need those product requirements?
  • Why do the customers need each of those product requirements? What specific business challenges or pain points would be addressed by each of those product requirements?

I often insist that engineering should inculcate system thinking to have a holistic view of how each component in the product inter-operate to deliver value to customers. Engineering should be aware of the customers using the product and what are the essential needs for which the product is used. Unless engineering imbibe those details, I could only foresee lots of friction between what they should develop and what they develop. Including them early in the prioritization process is one way to reduce the friction even though I insist that during on boarding process of every engineer into the product team, (s)he has to undergo detailed training on (i) what is the product, (iii) who uses the product, (ii) why the customers are using the product, in addition to the regular agenda of (iii) how the product is built.

Involving engineering early in the process helps them obtain the bigger picture to avoid any ambiguity during development, estimate efforts required to address the requirements and most importantly Product Manager tries to instill a sense ownership highlighting that their comments are valuable to evolve the product. Making engineering realize that delivering right product is the priority and not delivering product right. Constantly attribute success of the product to their efforts and make them realize that they are entitled to demand more details from their Product Manager on why certain features are prioritized and for whom as much as Product Manager has every right to ruthlessly demand more from engineering team.

End of the brainstorming session, scorecard would be completed with appropriate weights for each of the requirements for all possible attributes. Further every stakeholder would be on the same page with regard to prioritization process. Remember, I was talking about inclusive approach to product requirements prioritization process under discovering needs section so every stakeholder would feel they are valued and they have better clarity on how requirements are prioritized. Guess there is no better technique than brainstorming to achieve an inclusive approach.

Why I don’t use scorecard methodology?

Wonderful… we got a scorecard that can let Product Manager pick the ‘top X’ requirements. But wait, did I ever say I will be using scorecard methodology to prioritize features. With all due respect, scorecard is an excellent methodology that helps Product Manager to ponder and diligently assess how each product requirement can help achieve product objectives. Yet, I do not rely blindly on scorecard methodology or any methodology. I merely use them as reference to understand the relative importance of each requirement under a specific category to make effective prioritization decisions. Let me assume for a moment that the primary product objective is to generate more revenues, so obviously revenue attribute would carry relatively higher weights along with other attributes corresponding to the product needs that are valued most by customers and can either directly or indirectly contribute to increase in revenues. If we apply scorecard, undeniably all the features that contribute to increase in revenue will be prioritized and Product Manager would have done a fantastic job.

Nevertheless did I not discuss in length about being market focus – delivering requirements that might excite customers, generate demand, attack growth. I also discussed about imbibing new technology to stay ahead of the curve and ensure the competitiveness of the product. Focusing on them (WoW requirements, new technology) will fetch revenue in long run in addition to allowing the product elude strategic inflection point. Customers will be glad to have those value adders but they would never ask for them explicitly. Scorecard methodology will not be able to strike a balance between short term and long term requirements.

For those exact reasons, I have earlier attempted to categorize the requirements as i) tactical, ii) strategic and iii) disruptor. In addition to avoid prioritization conflicts between requirements in each of those categories, I strongly advocated the need to allocate a portion of product roadmap for strategic and disruptor. In spite of all the categorization, I am still not convinced with using scorecard technique for prioritization of requirements within each category. Prioritization is more of an art than science, so employing pure scientific methodology might be disastrous. Even though I use scorecard techniques to ensure that I have done my due diligence in understanding how each requirement contributes to both product purpose and objectives, I firmly believe that common sense prevails over scorecard methodology.

In addition, prioritization of strategic and disruptor features is done after evaluating the degree of uncertainty and amount of efforts required to build product increment to eliminate uncertainty. Attributes and weights do not work in this situation. Little gut feeling and thorough analysis of the amount of efforts required to eliminate uncertainty, extent of risk and amount of efforts required to deliver product increments (apply lean techniques) plays a vital role in selecting requirements under strategic and disruptor category.

How to prioritize smaller features

I call them as low hanging requirement that will deliver reasonable value to customers and does not take too much effort to deliver them. Those requirements are not deal breakers but definitely good to have. When the small features are pitted against bigger ones, they would never find space in the roadmap. In OS, I could recollect the concepts of starvation wherein OS would employ aging technique to avoid any low priority process from resource starvation. I would be glad to employ such aging techniques; nevertheless I am not heading in that direction. Product Manager has to negotiate with engineering team to prioritize such features without impacting the original set. The efforts are little less in delivering those features and the risk to overall development would be minimal, engineering team can deliver those features by optimizing their development and test cycles.

Roles, responsibilities, authority, hierarchy etc nothing would help Product Manager to have his way as much as personal relationship does. The relationship between engineering team and Product Manager should be symbiotic in nature. Product Manager has to offer something before asking for favors. Among many other things that Product Manager can do to let engineering focus on what they do best in most optimal way is to

  • Add lot more clarity to the requirements (ensure it is actionable)
  • Freeze the requirements and clarify on all the open items before start of the development
  • Do not let engineering team wait on Product Manager for prioritization decisions.
  • Remove any obstacles or deviations that is clogging the development or test activities

I always believe in the principle ‘Do it right the 1st time’. The above activities of Product Manager would definitely aid engineering team to head in that direction and facilitate them to do ‘Deliver more (features) with less (resources)’.

Prioritizing defects vs requirements

I have seen some debate on how to prioritize defects against product requirements. Now my belief is that both are different and quality precedes everything. Yet Product Manager does not pit defects against product requirements. No product is defect free and every requirement added to the product begets defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate and accordingly allocate a window open in each release for resolving defects avoiding any conflict with product requirements. Ultimately it is the responsibility of engineering team to prioritize and resolve defects within that window. I firmly believe that engineering team owns ‘Product Quality’ and they should have complete authority to mark the severity of the defects and resolve them within the guidelines of quality SLA. Product manager will be encroaching into the engineering space, if (s)he starts prioritizing the defects.

Collaborative discovery of customer needs – Who can participate?

As a Product Manager, one of the constant fears that I have is: Competition identifying a need before I or my peers do – Honestly, I don’t feel bad about it. Such situation can only testify that the discovery process is not rock solid and there are gaps. It gives one more reason for Product Managers to believe that they should think beyond themselves to expand their sources that can help them discover needs. Product Managers are always outnumbered in an organization by Engineering, Sales, Account Manager, BDMs etc. One best piece of advice that I received from my manager is that stacking more Product Managers is not feasible and it is not the right solution too. Instead Product Manager has to scale with existing stake holders to perform his/ her activities.

Impact: Collaborate effectively with all the stake holders to discover needs

[PS: Please read my earlier blog post on the need to discover customer needs]

Product Manager is not a lone entity while (s)he is exclusively responsible for discovering needs, corroborating needs and sometimes synthesizing inputs from various disparate sources to formulate a need. It might sound cliché, the fact is Product Manager does not have authority to demand that every stake holder has to discover need and Product Manager cannot set goals for discovery of needs. What I have mostly seen is that when Product Manager walks that extra mile to facilitate Sales Manager close the deal, help Account Manager maintain better relations with their customers, and aid Development team to build products faster, the entire stakeholder too walk that extra mile in assisting the Product Manager.

To better know how each stakeholder can help Product Manager in discovering needs and what kinds of needs can they discover, I have provided some illustrations and it would provide some idea on the kind of needs that each stakeholder can discover

Needs from support team

  • Product/ Non-product enhancements (Usability/ Features/ Documentation etc)

YouTube changed the VIEWS variable to 64 bit to accommodate more than 2 billion views as ‘Gangnam Style‘ video by PSY was viewed more than 2 billion times (source: https://plus.google.com/u/0/wm/4/+youtube/posts/BUXfdWqu86Q). Every product is initially created with certain scale parameters assuming it would suffice, however as time progresses and customer business grows, product might soon start hitting the limitations on certain critical scale parameters. Customer would raise a panic button immediately after hitting the limitation but support team can pro-actively raise an alarm through monitoring the critical parameters of the product. Support team will use support cases or other methodologies available to monitor and track the critical parameters of the product. When the critical scale parameters reach a threshold level, support team should immediately alert Product Manager to increase the value of the affected scale parameters.

Support team is also equipped to analyze the support cases and understand the trends to figure out the most common issues faced by the customers, such analysis can help Product Manager understand the list of needs that is not optimally solved by the product. Any improvements can lead to better customer satisfaction thereby triggering higher retention rate leading to more up-sell or cross-sell opportunities. Increasing trend of support cases on a specific feature could also throw lot more possibilities to ponder upon the following

  1. The feature might be buggy – Wakeup call for engineering team to immediately address those issues, while Product Manager can plan for interim release to avoid further customer dissatisfaction
  2. The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is not intuitive (usability constraints) or documentation is not clear. From the perspective of HW product, documentation often plays a key role
  3. The feature is incomplete – The customer needs are not fully met, wakeup call for Product Manager as the customer needs are not properly analyzed. Product Manager needs to take quick remedial action to bridge the gap between customer needs and product capabilities ASAP.
  • New use-cases/ solutions

There are classic examples of customers using the product quite distinct from its intended use. Every product has few innovative customers who are always step ahead of the product team in implementing either new use cases independently through innovative changes in configuration or new solutions through successfully aligning the product with other products. Those innovative customers whom I would comfortably refer to as Innovators or Visionaries as explained by Geoffrey Moore in his book “Crossing the Chasm” do dare to exploit the complete functionalities of the product to resolve the challenges faced by them. Such customers constantly pose technical challenges and help Product Managers build better products which eventually puts us ahead of the competition. Personally it is good to have such customers and my opinion is that they are worth more than a million dollar customer.

Support engineers when consciously look out for such unique use-cases or solutions through the aid of support cases can help Product Manager identify innovative customers and capture their innovations. Product Manager can later use the data to enhance the product that can supplement those innovations or draw plans for new product offering for new ways of positioning the product (aka demand generation)

  • New product requirements

Customers ask about non-existing features through support probably because of lack of understanding of the entire functionality of the product. Product Manager could use those inputs to understand new product requirements; this set of requirements will predominantly be incremental extensions of existing product capabilities.

Sometimes support system is the single window for customers to vents their ire on lack of any features that should have been available in the product by default. In B2C, customers do not think twice to raise their concerns through social media. If your support system does not have the facility to track the digital foot print for such messages, comfortably fall back on ‘Google Alerts’ to track.

Needs from engineering team

Engineering teams are masters of technology while product managers are presumably masters of problem space. Closer ties between the two entities triggering frequent discussion (not necessarily structured, probably unstructured discussions over coffee, lunch or in corridors) can create wonders. When engineering teams are kept informed of the problem spaces, they can evaluate how advances in technology (probably new components in case of HW products, new algorithms) can address the customer pain points in a much better way. For instance in case of VoIP products, engineering/ folks can suggest alternate mechanisms to increase voice/video quality, reduce latency and BW required etc. For same reasons, it is always better to let engineering team provide outside view of the world. Engineering team has to be updated with details about competition, customers, wins & loses, what differentiates our product from the rest.

To further illustrate the importance of working with engineering team, while I was working on new virtualized product I was interfacing a lot with engineering team to understand more about virtualization and how the performance could be improved. I did earlier talk about increasing the adaption rate of new technology. I saw performance as one of the primary roadblock for customers from adopting virtualized product. Engineering team did throw lots of ideas on how to improve performance and in fact they did introduce me to docker technology. Docker technology is gaining ground and engineering team did keep me informed on how it work and the potential advantages over virtualization. I could leverage the technical details provided by the engineering team to understand how docker can help provide better value to customers. End of the day, underlying technology does not make much difference to customer as much as the value rendered by each of those technologies does.

Most would advise Product Manager to hang out with customers, sales, and account teams. I would rather insist to hang out with engineering team as well provided if you are in same location as them to build better products. When Product Manager is close to engineering team, it is better to leverage the opportunity to facilitate more frequent exchange of thoughts, ideas, problems etc. I could only say that MAGIC would be created out of such interactions and if there is distributed Product Management team, I would prefer to hand over the responsibility of building the product to the Product Manager closer to the engineering team. Such interaction might not often enable Engineering team to communicate new needs, but they can deliver solutions that can amaze customers and create a WOW feeling.

Needs from sales

No one interfaces closely with customer as much as Sales Manager does. Sales Manager can provide specific details on how each customer is using the product and they also help discover needs of individual customer. Sometimes Sales Manager can also help understand the gaps with competitor that is haunting the product in closing deals. In addition, Product Manager can also seek Sales Manager input on the below items to get better knowledge about the product

  • Why is customer happy with our product?
  • Why is customer whining?
  • What deals did the product lose? Is there any trend?
  • Is the product losing to any other product in the adjacency space?

Another big source is RFP that most often neglected by Product Manager to identify product needs. In case of B2B segment, RFPs mostly precede sales and the RFP would contain more details about customer needs. RFP would also validate the ability of the product to handle future needs of the customer. Analyzing multiple RFPs provides the direction in which customer businesses are evolving, look out for patterns of new needs and record them.

Ideally spot star Sales Manager to better know about customer needs. Star Sales Manager sell more not because the product is in demand or the product is great or that (s)he is lucky. They sell more because of the deeper understanding of the customer and the product combined with ability to position the product effectively at the intersection of problem and solution. Working with such Sales Manager is really a boon to understand more customer needs, further such Sales Manager are always on lookout for opportunities to generate the demand for the product. They equally look up to the Product Manager to share or contemplate new use-cases providing additional compelling reasons for customers to invest on the product.

Needs from BDMs

BDMs can mostly help discover strategic needs that can push the growth of the product. While talking about discovering needs, I stressed on the importance of pondering on the following topics:

  • Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?
  • Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager has to look out for such possibility. Otherwise Product Manager has to spot customers trying to use the product differently from its intended use and check if the variations of the product could be built to generate additional demand for the product.
  • Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices)

BDMs do definitely play a greater role in helping Product Manager ponder over the above topics. BDMs by the virtue of their responsibility to identify new markets for the product and put the product on growth trajectory will gain better knowledge about the market, trends etc. While interactions with Sales Manager(s) boil down to specific customer needs, interactions with BDMs will mostly be centered on discovering market needs.

BDMs role might not be just restricted to help discovering strategic needs, they can also play a greater role while the market is on cusp of technology change. During discussions around inflection point, I did mention that Product Manager should also focus on accelerating the technology shift triggering the migration of customers from old to new technology. BDMs can help identify factors which when accomplished can trigger the acceleration of technology shift. The factors could be improvement in performance of new technology or identification of wide spread applications of new technology.

Basic tenets of collaborative discovery

In all the above cases, Product Manager do not blindly accept the needs and record them rather he opens a dialogue with the respective stakeholders to understand more about the need (WHAT part of the need) and develop a complete awareness of how unmet/underserved/latent need is impacting the customers (WHY part of the need). Without the complete grasp of what and why of the need, it might be extremely difficult for Product Manager to convert the need into requirements and appropriately prioritize it. In certain cases, the stakeholders can merely provide some hints on the needs and they might not be equipped to provide complete details. Incomplete information is still fine and Product Manager might have to build upon those hints. The stakeholders should neither be discouraged to share any kind of information about the customer needs, pain points etc. nor be penalized or reprimanded for sharing incomplete needs. The basic premise is that any information on customer need is worthy unless thoroughly corroborated. Product Manager should also follow inclusive approach while prioritizing requirements thoroughly communicating the yard sticks used for prioritization to the entire team of need discoverers for allaying any fears of unbiasedness in prioritizing the requirements.

Needs from confluence of multiple minds

Needs are not always discovered by a single entity, certain needs emerge at the confluence of multiple minds. Especially in case of emerging technologies such as IoT, Virtualization, Big Data etc. where the problem space is not clearly defined as technology is evolving and the applications of the technology is also evolving; culmination of engineering, domain experts, Product Managers is essential to synthesize divergent thoughts into a concrete need. Unlike in the earlier scenarios, I am focusing on structured methodology (like brainstorming) because each entity has lots of thoughts and they are worthless individually. The focus of the brainstorming session is not to pick the best idea, instead Product Manager has to effectively moderate to facilitate a freewheeling conversation among all the participants to put on table all the divergent thoughts including their assumptions, later participants would built upon other thoughts to provide a shape to a new product need. The scenario is akin to each one holding a partial solution to a riddle. Product Manager has to identify and bring together all the entities holding the partial solution to solve the riddle. To ensure success of this entire exercise, Product has 2 challenges

  • Identify the right set of participants
  • Facilitate effective participation from all the participants

Importance of ‘WHY’

‘WHY’ does not essentially mean that Product Manager fires a barge of questions either during brainstorming or while collating needs from various stakeholders, ‘WHY’ should not sound like an interrogation. The power of ‘WHY’ lay in enabling other person to ponder, to reason out their findings. Primarily ‘WHY’ should also let the other person break their assumptions. Every person has certain set of assumptions and it guides their thinking process. Higher the assumption, more the limitations exists in expanding the thought process of an individual. Because of the limitation or inability to question the status quo, retailers thought people will never buy clothes without touching. Execs at Nokia and BB thought mobile users will always be comfortable with QWERTY. ‘WHY’ is critical when Product Manager has to think beyond the existing needs of customers and anticipate how new technology could impact them. ‘WHY’ would dug out all the assumptions related to customer behavior and ‘WHAT IF’ hypothetical analysis could be used to understand what changes in technology or product would trigger change in customer behavior. The examples that I had highlighted is related to disruptor technology as ‘WHY’ makes much larger impact, nevertheless ‘WHY’ is essential for critical understanding of tactical and strategic requirements as well.

Ability of Product Manager to facilitate collaboration

Honestly, there will never be a dearth of stakeholders discovering or contemplating needs based on their role and experience. Product Manager has to facilitate an environment for free flow of needs and also information related to product (drawbacks, needs, limitations etc) from every stake holder to Product Manager. Even if any of the need sounds dumb, Product Manager should not duck it away, (s)he should explain the reasons for discarding and elaborate the yardsticks used to measure the value of a need.

To check whether Product Manager could create a collaborative atmosphere, Product Manager(s) should try answering the following questions with YES/NO

  • Are you approachable?
  • Are you enthusiastic about listening to ideas that resolves customer problems?
  • Are you eager to know about the new business challenges of customers?
  • Are you interested to keep yourself abreast with latest technology advancement surrounding your product? Also eager to know about the kind of implications that new technology can have on the product?
  • Do you have list of blogs or analyst data on your reading list as everyday task?
  • Do you feel spending time with engineering is your primary responsibility?
  • Do you feel bad about bad dragging engineering team into all your calls with customers?

If the answer to all the above questions is emphatic YES, then Product Manager is desperate to fill his/her head with information. Such Product Manager would never forego any opportunity to learn and (s)he would naturally facilitate an atmosphere to collaborate.