As a company grows, it eventually deploys technology to enhance its marketing, sales, and finance efforts and effectiveness. These technologies comprise a technology stack. Often, these internal investments end with the company having to call in an external expert to fix the initial technology stack deployment problems or hire someone to manage them full time.
Here are the four steps to having a successful technology stack deployment.
- Define your operational and go-to-market model,
- Have a dedicated technology owner(s),
- Data hub implementation, and
- Company onboarding.
Companies that follow these steps tend to fare better than companies that deploy technology willy nilly, then attempt to integrate their pieces later using a development shop to write APIs, or pay Zapier or N8n for an off-the-shelf integration.
Table of Contents
Defining your operational and go-to-market model.
Will your prospects find you, or will you hunt them?
Are you targeting large companies and need to do account-based marketing and account-based sales?
Will you be very tactical in your approach identifying a single persona within your ideal customer profile?
Depending on how you plan on gaining your market share should define your operational model. That operating model will eventually inform the technology that will be part of your technical stack.
How so?
If you want to develop an inbound model, your primary consideration should be your marketing automation and how it tracks, recruits, and ingests visitor data.
If you are an enterprise hunting model, you will focus on lead sourcing and outbound engagement tools.
That only goes for the initial customer acquisition phase; the operational model needs to also include what happens after the sale.
For example, will your company have an aggressive land and expand strategy, or will building a referral network be essential in your company’s growth?
What is the payment model? Monthly recurring revenue via credit card, or will you be running purchase orders (POs) and processing statements of work (SoWs)?
Once the executive, c-suite, or board have defined every step of the go-to market model from where prospects come from, through to acquisition, payment, and expansions, then you can move to the next step.
Dedicated technology owner
The first failure with a technology stack lies squarely on the shoulders of the technology vendor.
Why?
They need to inquire when this technology is deployed, who will own it? Who will do any of the analysis required, and who will be the administrator.
For example, when I sold a sales enablement platform Fatstax, I would get stopped by the VP who said they wanted the incoming Director to decide, so we would need to wait. To this, my team or I would retort, “Will they be the one owning it and managing it?” as well as, “do you have a dedicated operations manager who will oversee the day to day of this technology?”
More often than not, the company wanted the incoming VP or Director to have a say on the technology, however the person who manages it day to day was already onsite. If they weren’t onsite and there was no hiring req, we’d put them on the low touch model as if we did sell them, they would likely churn or be a problem client.
While it is exceedingly important to get buy-in from the executive sponsor, knowing who will be living in the system on a quarterly, monthly, weekly, and sometimes daily basis is key to ensuring a low level of churn.
Consider deploying a company’s first CRM, either the lightweight and free HubSpot or bulky and expensive Salesforce.
In the lightweight scenario, everyone has equal access and control. Custom fields are created with impunity, and everyone syncs their email so every conversation is logged and tracked in the CRM, including the bad and bounced emails.
The issue?
While HubSpotCRM can support up to one million contacts, the marketing side pricing goes up for every thousand contacts added. So an aggressive sales team with a lot of outreach can quickly blow your HubSpot budget with a ton of junk. I’ve heard from several company owners that every year they get into a knife fight with their HubSpot rep and need to do a database purge to keep within budget. Then they tell their team to keep it reasonable…and the issue pops up again the following year.
In the heavyweight scenario, the company decides that as they will eventually need SalesForce, why not get it now? So they do. With nobody knowing how to run the platform effectively, everyone becomes an admin. Similar to the HubSpotCRM scenario, everyone creates custom fields; worse, they create custom objects.
Then they go to town connecting Salesforce to anything they can.
I’ve seen fresh Salesforce instances turn into sales data pig pens within six months.
The solution?
Every technology needs to have a singular owner.
That particular owner can answer to the head of the department.
That particular owner can own several platforms.
The commonality is that for every platform, there is a single throat to choke.
For example, the VP of Sales wants to add a field. Great, go to the technology owner; the owner knows about all the user’s needs and aspirations; perhaps that field already exists in a slightly different format, perhaps it would benefit other user groups with slight modifications.
Recycling and upcycling are always better options than field creation.
Data implementation
The database of record is the database that acts as the single source of truth for your data. Contrary to popular opinion, this could be, and typically is, several different systems.
For instance, while customer relationship management (CRM) contains the sales data, the customer’s financial data is usually a financial platform such as Quickbooks or Xero.
Trust me when I say that accounting keeps records more accurately than sales, customers get rather grumpy when they get invoiced for the wrong amounts.
The first step is defining which system will be the single source of truth for which data.
The second step is ensuring a unique global identifier so data can be tracked between different systems. This is usually done at the topmost level or account level. A unique identifier is usually an alphanumeric identifier assigned by one of the system.
The reason it is not the name of the account is two-fold.
First, it could confuse and duplicate accounts if the account is put in with different spelling or nomenclature (eg P&G vs. Procter and Gamble vs. Procter & Gamble).
The second is for security reasons. With a unique identifier that is not easily linked to the common name, you can safely store and retrieve non-critical data with lower security platforms saving some money.
With the growth of CCPA, GDPR, HIPAA compliance, everyone should be security conscious and data protectionary.
Company onboarding
Once your organization has come up with the plan, the owners have implemented their systems, and everything is working as it should, it is time to onboard.
While this is the last step in the process, it is easily the most critical.
Why?
The greatest strategy can never be effective if the players don’t follow the plan.
To onboard personnel to parts or a whole technology stack requires several steps;
- education,
- training,
- practice, and
- testing.
One of the best systems I’ve seen implemented was from Lars Nilsson, who had a non-compliance dashboard.
Reps that didn’t have their data adequately updated would show up on the dashboard. If they were on the dashboard at the end of the month, they would lose a spiff—easy money for the reps that kept the database clean.
Once onboarding is complete, the staff needs to have access to the documents to refer back to them in case they need help or a quick refresher.
To make this fun, when I was at Duo Security, I had the sales operations manual hosted online. If a rep asked me a question and it was in the manual, they would have to pay me a dollar. If they asked me a question and the workflow wasn’t in the manual, I would pay them a dollar.
Diane Sheldon-Ku framed the dollar she got off me.
Your teams should also be updated on a regular cadence of standard workflows and changes to them. This is analogous to how all the technology tools update the administrators on their version changes. That data needs to flow to your users.
One area that is usually missed on onboarding is ensuring that people who may only touch the platform from time to time, think the VPs and some Directors for a sales engagement or marketing automation platform, are coached on the proper use and usage.
Why are they a critical group to train?
Two reasons are; tenure and tactical manipulation.
Even at small companies, VPs and Directors generally have both a longer tenure and hold a lot more sway than the front-line sales reps.
During their one on ones or even during water cooler conversations, subordinates will be asked to provide, update, or manage information on one system or another. Suppose a VP or Director does not have a depth of knowledge of the platform. In that case, they can easily request the subordinate add, change, or in the worst case, create fields that would adversely affect other users as well as disrupt normal reporting functions.
Just think, when an entry-level or even journeyman BDR is challenged by their superior to do some CRM work on behalf of a vice president or a director, it becomes very hard to say no.
I’m not saying make your VP and Directors power users of Koncert or Outreach; what I am saying is they should be part of the monthly use and usage call, so they know why things have been set up the way they have been.
Conclusion
There are many ways your technology stack can fail. However, by following the advice laid out in the article accrued over years of experience deploying and managing technology stacks, you will stand the best chance of launching a successful technology stack.
Furthermore, with a thriving technology stack, your organization will also stand the best chance of measuring where you are finding success, leaning into those areas (and out of others), allowing you and your team to accelerate your growth.
Great insight! Thank you for this valuable information!