Episode Description
To build or to buy? When it comes to finding a solution for your business’s needs, that question requires more consideration than you might think.
The decision comes down to a lot more than cost or ease. But before even weighing those factors, the most important thing admins can do is understand the problem they’re trying to solve.
“It seems really obvious. But I think having a strong approach is the hardest part,” says Emilie Jensen, who joins us on this episode of Serious Insights for Salesforce Admins.
Emilie is another accidental admin who at the time of recording was the Sales Operations Director at Infrascale. In the first half or our two-part series on the topic, we discuss some of the biggest pros and cons of building versus buying.
Listen to this episode to learn:
- The basics of finding a solution to your organization’s problem
- The different costs of building vs. buying
- A shortcut to building smarter
##
Episode Summary
To build or to buy? When it comes to finding a solution for your business’s needs, that question requires more consideration than you might think. And purchasing the solution to the problem or building your own is likely a debate most Salesforce admins have stumbled across before.
Simply understanding the core problem you’re trying to solve is the most important part, but it can also be the most challenging, says Emilie Jensen, who first started with Salesforce as an accidental admin and now works as a Salesforce administrator for CashApp after over 7 years in sales at Infrascale.
The best way to plan your solution? Think like a journalist, and imagine your program as the story you’re trying to tell. In order to tell the story of your solution well, you need all the details. Think about the ‘five W’s’ in journalism: who, what, where, why and how.
“Before you can even approach a ‘build or buy’ conversation, I think the idea of asking ‘why’ five times and really digging into those requirements, and really understanding that business process is a key part of it,” adds podcast host Kristi Campbell, Senior Salesforce Admin & Salesforce MVP.
Tune in to this episode of Serious Insights for Salesforce Admins to hear Emilie and Kristi talk through some of the biggest pros and cons that complicate the ‘build vs. buy’ decision. They discuss strategy, cost and product options; Emilie even shares a few of her own secrets — and tips for what not to do — that she learned as an admin and problem-solver herself.
##
Key Takeaways
Know the core challenge.
Understanding the core problem you’re trying to solve before even beginning to think about whether you should build or buy the solution may seem obvious. But having a strong approach is often the most challenging part of the process, especially when the solution needs to satisfy multiple departments across your business. Operating on a budget only adds to the challenge.
Think of the solution as a story. Imagine yourself as the journalist who needs to convey that story to your audience. That means you need to ask all the right questions — Who? Where? Why? — to land at the best solution.
Know the costs of buying vs. building.
Sometimes, the answer is more straightforward — a tight budget may force you to build your own solution rather than buying an easy fix.
But the time spent on researching and creating the right solution comes with a cost, too. Building a solution from scratch takes time and expertise, not to mention the time an admin will have to spend training users on how to use a new feature. “A lot of the time when I was considering, do I build it, or do I buy it? I would lay very heavily in the, do I have to train people to use it? column,” Emilie says.
Know the types of products you’re willing to spend money on.
As a Salesforce admin, you’re dealing with a ton of moving pieces. If the right solution to your problem is to purchase a product, you also need to think about what kind of product you’ll be purchasing and how billing works.
Some solutions may require a one-time flat fee, or a subscription, or a product that may come with upgrades down the line. Knowing whether you want to purchase, for example, a flat-fee product when all of your other products are subscription-based is an important question to answer when planning your solution and defining your business’s needs
##
Featured Guest: Emilie Jensen of CashApp/Infrascale
💥 What she does: Salesforce Administrator at CashApp and former Sales Operations Director at Infrascale
💻 CashApp on the web: Twitter | LinkedIn
💻 Infrascale on the web: Twitter | LinkedIn
🔗 Emilie on the web: LinkedIn | Trailblazer
🧠 Emilie’s big idea: “You have to have a strong architecture philosophy before you implement things that have object creation-based specifications. If the architectural philosophy is there, [if] it makes sense, then you don't really need to develop one.”
##
Episode Highlights
Key excerpts from the episode transcript
💡 Building doesn’t always save as much as you might think.
[09:43] “There's a lot of different resources in the question. There are time resources: Does your admin have time to spec a new solution? Does your admin have time to research the variety of solutions that are out there for the business need? Does your admin have time to install it and then train users to use it? For me, the training of users was such a big part of the equation that a lot of the time, when I was considering, do I build it or do I buy it? I would lay very heavily in the, do I have to train people to use it? column.”
💡 Purchasable solutions could confuse users.
[12:36] “Getting hung up on user interface differences is a huge issue for human beings in general. And this is why when you switch from an iPhone to an Android, you're like, What do I do? What is this alien technology?... And it's the same if you're moving between different operating systems, or something slightly different: the contact page layout in Lightning looks different, columns are in different places, the phone number isn't in the same place or the email is slightly off to a different direction, and someone's been trained to look in the upper left hand corner for that information, you're going to have to do a retraining.”
💡 Change can be hard, even for trainers.
[13:50] “Especially for your salespeople, you don't want them to have to think about [things like interface changes]. You're trying to make a smooth process for sales enablement, to enable them to sell the things to keep the lights on and to try and make things easier. But sometimes the change itself feels hard. I over-explain things sometimes because I'm thinking about all those little background things that matter to me that maybe don't matter to my users.”
💡 Just Google it.
[20:28] “I didn't Google a dang thing. I didn't look up, did anybody do this before? I was just like, I'm gonna just do it…I'm just gonna gung ho into it. And man, I really wish I hadn't…You spend a lot of time when you don't do research in finding the little bugs, in finding the little gotchas. For me, I really had to accelerate what I knew about automation in Salesforce within the span of a few weeks. And not a lot of people have the luxury of that kind of time to figure out errors. Fortunately, the company was in a position, and I was in a position where I could experiment like that. But I don't think a lot of admins get to do that. By looking into, what are the limitations of Process Builder? or, what's going to happen if I create race conditions in Process Builder? How many? How many versions is that going to take for me to figure out? For me, it was about 17 versions. So I don't recommend it.”
💡 Know how different products are billed.
[23:07] “[There are] one-time products versus subscription products versus tiered products — Now we want to introduce a training? That's a flat fee. So how does that fit in when everything else is subscription? And then partner selection becomes a big part of it, too…So depending on the size of partner you're working with, if you do make a suggestion or need a feature, then how long might that take to get? And can you work around it? Which, again, goes back to where we started, of really having your requirements defined. And if it's just kind of a ‘nice to have,’ then maybe you can wait a little while.”
Top Quotes:
[10:33] Emilie: “When you're in sales operations and you're an admin, you're wearing two very similar, but very different hats. You have sales operations, which is very user-based, very sales-focused, very sales-driven…And then sales administration [where] you have the other departments behind you asking for assistance. So you kind of have a conflict of fires. And then you add in user training into that confluence of fires, and you're like, oh boy, how much do I have to spend on the phone training sales or reinforcing training with sales? And is that worth my time?”
[19:49] Emilie: “ I didn't Google a dang thing. I didn't look up, did anybody do this before? I was just like, I'm gonna just do it. I'm just gonna gung ho into it. And man, I really wish I hadn't.”
[24:57] Emilie: “You have to have a strong architectural philosophy before you implement things that have object creation-based specifications. If the architectural philosophy is there, [if] it makes sense, then you don't really need to develop one.”
