The key differentiators that can make a tool unique can vary widely, depending on your perspective and the relevant audience. The most successful tools have established niches and differentiators in multiple categories, cementing their success. But, achieving true differentiation in any one category can be sufficient for breakthrough.

Among the categories to consider differentiators:

• Licensing, purchasing, security - for procurement team, security teams and managers, how does the tool make their life easier? These areas are often out-of-sight, but gaining differentiation here can be key to easier approval/purchasing or scaling broadly across an organization. Differentiation here is hard, but rewarding.
• Usability, flexibility - better usability can *always* be a compelling point of differentiation, but so can flexibility - does the tool adapt to new use cases effectively?
• Supportability & reliability - how easy is it to support, or gain support, when something goes wrong? How does the reliability compare to other tools? Reliability has become table stakes for so many tools and services, but genuinely effective, differentiated supportability remains rare
• On-boarding - the cost of on-boarding tools can be prohibitively expensive for some companies to consider adopting. Any tool that takes longer than a few hours or days will become a "project" -- something that most organizations have little time for.
• Integration - no tool exists in a vacuum; providing valuable integrations with commonly used applications/services or domain-specific tools/products is a proven approach to demonstrating differentiation. In fact, a tool can announce their presence and shape their brand by delivering a unique set of integrations that establish their difference to competitors in the market

Traditionally, organizations are structured around fixed budgetary and planning cycles, for efficiency. This makes sense for the Finance department, but poses challenges for most others. Any requests to spend money on new tooling that was not pre-approved in a budget cycle faces a outsized effort to be justified. Therefore, a number of frequent roadblocks are very common when making decisions on RLT tools:

• The ROI of RLT tool can be difficult to quantify up-front and may not be deemed sufficient to meet the bar for out-of-band budgetary spend
• If teams cannot secure budget immediately, and must wait until the next budget cycle, it is possible that the critical need for the tool will have diminished - either because "good enough" workarounds were found or the team learned to live without the tool
• The chain of decision making can be opaque and will inevitably involve individuals with minimal knowledge of the genuine needs and benefits sought - the greater the distance between the tool requestor and the final decision maker, the greater the justification required to gain approval

The most common barriers arise with tool and service selection across organizations and can be considered as "features, not bugs". Organizational budgetary control exists to purposely limit ad hoc spending. While this provides financial constraints and controls, it risks curbing agility, flexibility and autonomy among teams.

Barriers:
Senior management asking for the monetary benefit of attending courses, conferences and training.
The inflation urging companies to focus on profitabilty and cutting on training.
Ignorance: Not knowing what is out there, not being aware of the opportunities related to the raise of employees' knowhow.
Traditional mindset with a company, with groups or with individuals. They think they know it all, that all knowledge if available in-house and that no additional training is required.

To get a sustainable competitive advantage in the area of research learning tools, you need to be a large organization that sets aside sufficient resources for investing in the unknow, and hire experts from the outside.
They need to be flexible enough to integrate this new knowhow into their company philosophy and make these new experts feel part of the family in a short time.
Then an area of a free experimentation field can be built where these experts get together, run brainstorming about what is out there and what isn't, and in what way they could develop something that noone else is able to copy in a short time.
With a few decades of experience in different kinds of jobs and organisations, bringing together experts with a different mindset, you stand a good chance to develop learning tools that are unique. With the right Marketing you can sell it to clients, convince them that you are better than anyone else, and thereby build a sustainable business.
Of course you need to remain alert and see what is ongoing. Attend conferences, talk to your competitors, to colleagues that come from competitors, and talk to your clients to understand what their basic needs are.

Long before Covid, we used to organize trainings globally. A group of global experts and leaders travelling around the regions to bring the local teams up to speed as regards to their knowledge base. This would involve basic training around essential know how, but also innovation, to ensure people are on top of what is new and relevant.
The benefit of this format was that people could in person meet their global colleagues that they are otherwise dealing with only virtually.

Today most of the training is virtual, and the focus is on innovation rather than the basics. For the basics, people need to take an online course to be an accredited user of a specific tool or approach. The decision making about who to send to the training is very much local and ad-hoc rather than systematic.

In an ideal world training would be seen as a global responsibility involving the whole organization, involving both the managerial levels as well as technical experts. There should also be people following the web daily to understand what is hot, what is new, and where are the opportunities for training. This could then be raised to a committee for deciding which topics to take over, maybe modify, and then teach the organisation on.

Innovative Design
Ease of integration
Offered as a Service
Free Trial Period
Ease of User Management
Device Agnostic
Say in to the feature roadmap
Frictionless sales & Support
Frequent Releases & Upgrades
Online webinars to educate users

I think a barrier that we always tend to overlook is a sense of choice paralysis and the grass potentially being greener.

Rather than looking at the tool/software (or whatever) objectively, there's always a sense that there might be a better quality / better value tool out there.

I think longer term contracts becomes a catalyst for this feeling.

The barriers would be reduced tenfold if suppliers were more flexible with contract lengths

The decision making process should start with writing down the requirements that we need to cover with the tool and sharing them with all the relevant stakeholders (usually done by the product or marketing team). This step is often omitted, at the cost of organizational alignment on the final decision.

Also, another critical point is to have the procurement team onboard from the start. It really pays to have them as an ally in the evaluation of new tools rather than a gatekeeper for costs.

Finally, if there is to be any major investment in a vendor or tool, there has to be clear and concrete communication to the senior leadership team, explaining the need, the cost of not taking action and the path to ROI.

Things that have derailed decision-making processes for me in the past...

• Unexpected manager departures
• Stakeholder or team member departures
• Reorgs
• Vendors changing their pricing
• Vendors getting acquired by another company
• Budget cuts
• Finding out another department is working on something similar and having to start over together
• Mergers of your own company

You never know what is going to happen or when. It's always worth the little extra time to keep documentation up to date and always be prepared to re-justify where you're trying to go and what you've already accomplished when the ground shifts.

Key differentiators to be able to compare and contrast against for me have tended to include:

• Subscription vs. Perpetual licensing models
• Named user licenses vs. org or flexible licensing seats
• Pricing for number of applications/integrations vs. data volume, traffic, users, etc.
• Integrations with common existing platforms in a tech ecosystem
• Multiple points of access from mobile through desktop
• Adaptability--what will we do with the tool to start today vs. what might we want to iterate/augment with tomorrow
• Niche player vs. broad and universal player (RLT aimed at a specific use case or market)
• Longevity/viability of the vendor behind the tool

As with any investment/purchase, hopefully at the end we end up with something that is actually valuable and worth the price required. Somewehre in the middle, if not carefully orchestrated, competing interests can chip away at the potential value and wander far afield from the original reasons and needs for selecting an RLT.

Who is involved?

• People who actually need insights/information out of the tool
• People who will act/make decisions based on that data
• People who will be configuring the tool
• CUSTOMERS--if they will be directly interacting with it--this should NOT be an internal-only selection/decision process
• Anyone who has $ influence/authority

We need to include anyone who ultimately could object but also advocate for our ideal choice of tool.

What is the decision making process?

1. Determine initial needs/motivations
2. Examine the competitive landscape
3. Engage with qualified vendors
4. Evaluate demos/trials
5. PoC
6. Obtain CUSTOMER input
7. Decide

Ultimately, we want to get to the end where there are just enough choices to allow for compromise against certain aspects but not too many that we could end up with an undesirable choice. Sometimes I advocate for putting a choice up that is obviously UNdesirable in order to steer decision-makers to the 'right'/best choice. Sometimes when there are a few 'good' choices and not enough bad ones, the deck isn't 'stacked' enough from those who know which thing would be best in front of the folks that have the $.

I am always thinking about this. as explained in detail in this discussion.

We as the product team and marketing team worked together very hard for weeks and sometimes for months, to find the best tools in the market, write down requirements, evaluate and shortlist 2 vendors, and do the POC for 1-3 months with the company. Then after all of this, we have to go to a committee to approve the budget and start from scratch to explain it in detail

• why do we need this tool?
• what is the business value?
• why this module is required, it is an expensive one, shall we proceed with basic features only?
• what is the ROI?
• etc

I have no doubt about the value of the committee and the value to answer all these questions, is it right to have the final decision in the committee more dominated by the finance team? To what level product and marketing team should go ahead and purchase if they are happy with the results of POC, it is part of their budget and they should be accountable for it, right?

I still can see in most big companies a big challenge in the final purchase decision, which sometimes takes weeks if not months after the final POC to get the approval and issue PO, senior leaders should think about this process and try to simplify it

It's been touched on previously with Personalisation, but getting tailored approaches is so important.

Mostly it's about how many licenses you want to buy, or the level of access.

It rarely starts with what your'e looking to get out of it, and a custom package designed for you.

I'd have invested in so many more tools if they had looked at what I actually would use

The committment of the business units during the DM process is not high enough because tipically they are not officially in charge of them
Budget constraints (limitation of budget but also which organization is the owner of the budget? Which one will directly benefit of the revenues increase if any ? Will the rewards shared with all the stakeholders)
Previous relationships with vendors that could be different depending of which stakeholder is approaching the decision

• Vendor
• knowledge and coverage of your target market
• solid trusted references from peer competitors
• Reliability and Time to deliver
• Availability for pilots
• Presence in major analysts reports (Gartner, Forrester)
• running integration partnership (i.e. with CRM tools or Database)

• Product
• Flexibility/modularity
• user experience
• AI leverage
• ...all the one we've mentioned so far
• 
  

1) Collect your requirements
2) discover the 5-10 solutions that best fit
3) make a thourough analisys (RFI and internal due diligences) to shortlist the 2 best
4) run an agile pilot project (2-4 months) early on-boarding all the stakeholders to test the 2 shortlisted solution on the same use case
5) shared selection of the winning one and IT project to integrate IT in the ICT informative system

I find there are 4 impactful differentiators in RLT's:

Adaptability: Tools that can intuitively be adapted to changing landscapes allow a tool to grow with my team as opposed to becoming obsolete.
Ease of Use: Ease of use impacts time spent building/reviewing (I don't need more time suckers in my job!), and it also allows more users to access the tool with effectiveness. I will always favor tools that are efficient.
Multiple Engagement Tactics: I need a tool that gains feedback in multiple ways. Not just a survey, not just a panel, but that offers me multiple ways to engage depending on product/topic, while pulling the data back into consistent and familiar formats. This allows tactical tailorability, with streamlined data processing on the back end.
Scalable Costs: Solutions that allow cost flexibility allow younger or less cash heavy teams to access these tools early (which is when they REALLY need them), and become more sophisticated as the company grows.

> Yearly contracts rather than a monthly subscription - it's a big commitment for something you may not be fully convinced of.
> No account sharing - products that charge per user rather than per organisation. We might be able to afford the cost for one user but not multiple - all the work will just fall on to one user and others won't get upskilled in using it
> auto-renewals for yearly contracts - when does that ever benefit the customer?

The most unique differentiator if have seen with an RLT is a 'university' feature.

All users of this RLT are automatically enrolled into their 'university'; a community of other users. You can connect with each other, contribute to forum chats (about how to use the tool and other research-based topics) as well as access interactive training modules. So as well as fulfilling its primary function of researching customers, it also directly supports many of our team's CPD needs.

I also agree with what others have said about low price points, flexibility and personalisation :-)

I think this has partly covered bY Alex Jones, but I'm going through this right now with a tool.

It's a brilliant piece of research software that looks at investment trends, personnel changes and market analysis. For me it's a great tool.

But for the people signing it off, it's purely an expense.

They don't immediately get the value of it, the role it can play, and what it will help us change - understandable. But even after I make a case for it, for them it's not going to change their day to day. They won't use it (much if at all).

Ultimately it comes down to presenting it as investment vs expense, but that's easier said than done. IF we can live without it now then why pay?!

We submit a proposal to the senior board highlighting the business need (including any risks faced from not selecting an RLT) alongside a market analysis of the RLTs that fulfil the need, including the recommendation of the most senior end-user (normally a researcher). 

The researcher will have likely trialled the RLT - trialling is essential to generate conviction in the recommendation and illustrate the total value the RLT offers the business in the proposal.

The amount of energy that goes into this work will be dependent on the cost and any commitment (contract) involved. An RLT costing less than $100 a month, cancel anytime, would not require the same level of trialling or senior sign-off from CFO that an RLT costing $30,000 a year does (we have examples of both!).

Similarly, if there is already a budget line and it is one RLT ‘replacing’ another the conversation to approve is more straightforward than if selecting an RLT that has yet to be allocated budget. If there is something I have my eye on I would try to submit a business case for an RLT towards the end year when budgets are allocated for the next.

For RLTs that represent a new and significant cost, we will demo it to our Head of Product (most relevant senior stakeholder) to get an initial reaction before writing a proposal – they have a good ear for seeing the potential of an RLT and have a closer read on whether the business is likely to be financially receptive at any given time.

Who is involved : CTO , CIO , CPO , Procurement Lead , Investment Committee
Process : Its somewhat unique per organization but generally follows the steps of

• Business Need
• Business justification
• Benefit Definition
• Formation of Project Team
• Selection from a list of potential candidates
• Approval by the Selection committee

Most of the Roadblocks I have experienced trace back to Scope & Perfection.

1. Scope: If scope of need is not clearly defined on the front side, these processes can become more of a tug-of-war than a collaborative review of a technology. Scope will create a hierarchy of features and will keep multi-department input collaborative instead of competitive.
2. Perfection: The pursuit of the 'perfect' product is a dead end. Understanding that RLT will forever be a dynamic topic, perfection cannot be found except for temporary periods - therefore, the process should weigh total advantages/improvements added by a technology and spend much less time on what it doesn't deliver.

Although the labels/titles may change from company to company - the business units responsible for for the business case, developing the product, marketing the product, and selling the product should have some level of input. The goal is not just to create a product - it is to create a product, create market demand for the product, and sell the product for profit - so the experts in each of those initiatives should be involved. Ultimately, Marketing typically chooses (and pays for) the RLT, and is responsible for utilizing the tool in a way that incorporates perspectives from the other business units.

The decision making process often begins by highlighting critical insights your current RLT is not giving you. With clarity on unmet needs, vetting prospective technologies that can cover current needs as well as current or future unmet insights becomes the next step. Running a case study through the technology can help uncover gremlins or unforeseen benefits, while also providing and understanding of the levers within the technology. This can also allow you to see if the output is as useful to you and and the other business units as you desire. After confirming capability, a business case is necessary to demonstrate how any 'new' expenses would be offset in positive business goals. If a technology makes it through all of those evaluations, I'd submit it for full company approval and begin an implementation plan.

Decision makers might not have an updated knowledge of the latest and best tools and might really on their unconscious bias to opt for older tools they are more knowledgeable about

Depending on the size of the organization, if Procurement or Buying departments are in charge of negotiation the tool acquisition, these areas tend to have a different view of the actual need of the tool. When this happens, it is because of organizational misalignment or organizational silos.

For example Marketing department needs a specific tool, but procurement would find other alternatives that might be cheaper but not quite the tool needed by marketing. This creates inefficiency,

To make a tool unique is to be flexible enough to allow the user to customize it or personalize it in the way the user/company needs the tool the most. There is no such thing as a "one product for all" tool, because this leaves too much value off the table. Every company is different, and for such, customization plays a vital role.

The decision making process has different stages and due to that, it has different stakeholders with different decision powers. Nonetheless, senior management, usually a Director/VP of Marketing tend to have the last word.

As said before, there are different stages of the process. It starts usually with a middle manager building the case the the RLT is needed. This middle manager should recommend which type of RLT to invest and with which partner/software to implement it with.

After the proposal is done, a top level executive should give the "green light" or not, to the proposal. If the green light is given, depending on the type of organization, procurement would go through the investment negotiation.

Once a clear partner is selected or a specific software is selected, the Director of Marketing or the VP of Marketing should be the person to give the final confirmation that the RLT selected with the partner/software selected are good to go.

A key differentiator is how much a provider helps to lower the purchasing risk and letting customers trying before they buy. Providers that offer full featured trial periods with additional help to set things up have a clear advantage against providers that don't offer trial periods or offer them exclusively in diy mode.

A common challenge in the decision making process is that many times the people who have requested to purchase and use the tools are not the same people that are authorized to make a high budget purchasing decision. Providers should actively try to bridge the gap between them and give the means to the people that will use the tools to 'convince' the people who pay for them. For example, providers can offer readily made material that addresses the main pain points in a management compatible language, or that shows the potential ROI of the purchase and explains in detail how the unit economics are better compared to other providers.

Projects are notorious for changing direction or scope.

RTLs have to be flexible enough to adapt.

I have seen umpteen times that corporate priorities change and shift the timeline of a product selection. Other factors that can complicate a decision making process are:

• > Stakeholders from different divisions (who will both use the product) disagree on selection
• > Corporate leadership change (CIO, CEO)
• > Surprise! A new top priority arrived and this selection is now bumped.
• > Budget
• > Disagreement among internal staff on HOW we will solve the problem. Not necessarily

Some of the favorite applications I have used offer a decent level of flexibility so we can mold their solution to our business.

Nothing is worse than buying an "out of the box" "canned" solution that promised the world but actually has roadblocks and inflexibility at every turn. Salesperson smoke and mirrors, empty promises!

Even if a company/software cannot directly solve your problem - being able to have a path (customer success manager, tech support) to provide your need and actually be heard is key. The customer is not always right, but they need a path to be heard.

When selecting any software, not necessarily an RLT, I find it is imperative to have an end user (or more) present. While they are not the ultimate decision maker, their opinion and input are almost the most important because they are the ones who will ultimately make the launch/adoption successful or not. They will be able to hit the road running and be a champion for their peers once a solution is selected. Obviously exec management and business unit stakeholders should be involved in the first round of (high level) Yay/Nay. Once the short list of software providers is selected, go ahead and bring in those end user(s) and let them be a functional part of the decision making. While executive stakeholders will be concerned with budget, contract terms, vendor due diligence etc -- these other folks will be looking at software through the lens of usability.

One bottleneck not mentioned yet is institutional inertia, and corporate culture with resistance to change. For example if a company were a heavily sales and marketing focused organization and had a certain way'of getting their market learnings (sales calls, customer visits) and they are transitioning to a product-led company, selling through a different way of gathering that market data, especially in a way that can be read as 'disempowering' or threatening the status-quo of long-held and otherwise successful methods can meet a lot of resistance.

While it's a common part of being an agent of change, it takes a lot of experience and internal selling to become proficient. I've found that getting people to make a series of small gradual shifts instead of a single seismic shift will bring people along.

I've seen some tools shared in this channel that seem awesome, but I know they would be 'too rich' for the company I'm at right now. The differentiators should be considered in light of the goals and capabilities of the team to execute on those goals. All the bells and whistles in the world won't matter if you get a tool that requires too much support, expertise and skill to turn the insights into action. A company that offers a range of tools that can be added incrementally has an advantage.

Different org structures have different delegations of responsibility - in some Marketing is responsible for market listening, in others its Product, some instances it might be Sales in a Business Development arm. Depending on the cost and the implementation (will IT need to be involved or not) and if the company has formalized procurement processes or has delegated authority to each department independently the process will be more or less complex. At my current role it would be a combination of Marketing and Product and we'd need to make the business case to the C-Suite if a vendor exceeded the signing ability of the stakeholders. Then IT would be engaged for implementation and integration if required.

I like tools where you can add on options / users as you get more comfortable and see the value.

I prefer to make small purchases as opposed to jumping in feet first.

Org's have limits on signing power at different levels. The first question is always how much does it cost? The second question is what do we get?

Proving the viability of any tool is required to justify the cost.

Often RLT's are linked to a specific project or opportunity. The hope is then the lessons learned can carry forward to other aspects of the organization / sales department.

Once budget is established you can start to look to differentiators for the RLT's and choose based on what you are attempting to achieve.

Often there are three main challenges:
1) Agreement on the right technical solution. The larger the organisation, the harder this can become. The solution generally is to produce and share/ collaborate with key stakeholders a weighted scoring evaluation matrix. Get them involved in the weighting and criteria - so that there is consensus and then score the solution(s) using this tool. In most cases, it provides a clear recommendation that is hard to argue against since all key actors have been involved
2) Business case. This requires a cost-benefit analysis and a forward commitment on the benefits side. This can be hard to quantify sometimes eg "more accurate or faster data?. Looking at how this data is sued can often offer some guidance on the business benefits
3) Stakeholder management - socialising and having separate conversations in advance of the decision-making meeting can really help with this to ensure that everyone is on side and all concerns are addressed.

PS Mary - you have a minortypo ".....about teh course of action.... " in your theme summary :-)