What's Salesforce? (2019)
retool.com
retool.com
1. Don't allow businesses to customize at all, make them fit to you. That can work with something like ADP, but little else. A lot of the cool B2B startups think they can displace incumbents by just building cool, fast software, and then they are perplexed why they can't gain marketshare when every other customer has some bespoke use case they don't support.
2. Build a general uber-programmable platform that businesses can customize themselves -- now you are in the "slow", "poor user experience" territory but at least it works and is cheaper than option 3
3. Hire consultants to write bespoke products from scratch for each business. That's the old IBM Services model.
So if your baseline is Microsoft Office, then the performance/user experience of your favorite online B2B platform is going to be terrible. But if your baseline is IBM Services, then it's a godsend.
I think it’s pretty sad that enterprise software is mostly stuck the way you describe. There are companies willing to invest in fast and user friendly custom software though; the company I work for is pretty successful at doing just that.
Really if you think you can do better than X, whether X is oracle forms or SAP or whatnot, it's important to understand where X went wrong. Hint: it's very rarely because they were "old-fashioned" or didn't realize that customers liked fast software that was easy to use. The founders of X were just as smart/capable as you are, but they faced a market challenge and made some choices with trade offs. If you limit your analysis to "they didn't know software should be fast", then you are not going to end up any better than they are once you reach their scale. I am not trying to say that every incumbent always made the right choices. But an understanding of where they went wrong needs to go beyond "they went wrong because they are old fashioned" or "they went wrong because they didn't realize software shouldn't be filled with bugs". There are real hard problems here that need to be understood before you are in a position to improve on what the incumbents are doing.
Then throw in all the regulatory and compliance stuff that businesses need to trust storing their data with you. Add EU regulations and you will end up building data centers in different parts of the world. Then you will want to spin up training to use your custom DSP. And localization packs. Then you will need APIs to pull data in and out as customers will fear lock-in and they'll want you to integrate nicely with some other service. Then you have to figure out how those APIs work with your metalanguage. Then other customers will demand the ability to reskin everything with their corporate logos, custom login screens, support for SMS and two factor auth, support for third party identity providers, scripts to enroll/unenroll users, admins will want scripting platforms to manage all the complexity created by adding the other features, Etc.
the problem is not everyone can afford a IT dept with software programmers that can build out custom software.
If IT is not their core most companies seek out software that is already out there with somewhat decent reputation.
edit: at one of my previous job, they have a in-house software that was build with older technology that needs to rebuild. they outsourced it to Capgemini. it started when i join the company and by the time that i was out (4 yrs). they still didn't get it covert. they kick out Capgemini around two years in and hand it to another consulting company and the new consulting company junk out Capgemini's code and start from scratch.
i'll like to know more details on how they botched this project, it always make me curious how they botch it up for 4 years and two million wasted.
Agreed, though isn't this often just a problem at a strategic level? C-level doesn't understand digital transformation, so there is no strategy and no budget, or they think they can just buy it with platforms like Salesforce.
Having custom software built is only getting cheaper because our development tools are getting more and more powerful and managed cloud infrastructure is extremely compelling due to removing most of the ops from devops and being cheap at the same time, so costs could hardly be an argument anymore, right?
But yeah, there's always the risk of hiring a firm that has a quality problem, or uses terrible tools to build software in the first place (which is what I was referring to with the joke in my first comment in this thread).
Enterprise software is a minefield, how can we fix that? :)
Q: Can your system do X?
A: Yes (doesn't matter what the question is, or that an entire add-on would have to be built that could never be cost justified).
Q: As a company we do things like this, will your system work?
A: Yes, our product works with your process, no matter what it is.
I have observed this to be true. Customers particularly love the second one, so telling someone that they must change their process to work with your super simple un-customizable product can often be a deal-breaker.
Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.
It's a sliding scale. You have to pander to them to some degree - there's no choice. But it takes grit to refuse to e.g. branch your core code or otherwise compromise your architectural integrity.
The problems are when the sales team does not appreciate the downstream costs of just letting this one patch in. And when you're a struggling startup, sometimes they're right and the social proof of the deal (and the revenue) make it a good choice to compromise your principles this once.
I am currently working on a large project, which unfortunately needs to communicate with DB2 and interact with AS400 (old ERP system). At this point nobody knows how things work and how the business operates exactly. Managers hold pieces of information but it is not documented at all. I have hit many road blocks because one thing was said, which turned out not to be true after a bit of investigation.
I could develop this software in 3 months, but it is taking 1+ years due to lack of documentation, developers not being on the same page, and nobody understanding the current systems.
Every time your client slows down, somewhere an executive was promoted.
This is geek poetry.
And I say this out of experience with using it as part of a sales team at a car dealership I worked at years ago. Every sales person in the company was expected to log all the customers they interacted with, track phone numbers & other info, set reminders to makes sales calls, make notes of what you talked about in said sales calls, et cetera, et cetera. And management was adamant that we did these things.
And for good reason. Sales is a very data driven industry, so to your point yes, it’s great for upper management to be able to track & aggregate all of the data company wide.
It’s been too long since I used it for me to really remember or comment on the performance of the software. But if it’s as bad as the OP is saying that’s a real problem. If you have a whole sales team using this, and performance issues are constantly slowing them down and wasting time, that’s something that should seriously be addressed.
I guess you’re saying though that they just don’t care if the sales team experience sucks? As long as management gets their data?
Alas, intended users are seldom the ones writing checks. As the old saying goes, decision to go with Oracle happens on golf course, not meeting room.
Or wined & dined.
Salesforce's response to the client-side half of the problem is migrating from Aura to Lightning Web Components. LWC is statically analyzable and Aura is not, so they can get some optimizations in that way. On the flip-side, LWC is a piss-poor framework because of how they've stunted it for optimization's sake.
Half of the beauty of Salesforce as a developer is the fact that I can build in a month what would typically take a standard web dev team a year to piece together. That's only true so long as my team works in Aura with all of the scaffolding tools and libraries we've built over the years.
The platform is both powerful and pretty clunky. Salesforce development is consistently 20 years behind established best practices. Learning Salesforce means learning the thousands of limitations and broken parts of the ecosystem. And it’s non transferable knowledge.
and or
Implement & run
NEVER OPERATE
this is obvious, everybody knows this :)
""Sep. 13, 2019 Updated: Sep. 13, 2019 10:29 p.m. Oracle OpenWorld, a tech conference with some 60,000 attendees" https://www.sfchronicle.com/bayarea/article/San-Francisco-wa...
"...From December 2 to December 6, we expect more than 60,000 attendees will spread out across six venues on the Las Vegas Strip, promising to make re:Invent 2019 the biggest re:Invent yet..." AWS re:Invent 2019
"...Well, here we are: a little over a week after Salesforce’s 17th Dreamforce. As a lush green forest burgeoned in downtown San Francisco, over 171,000 people from 120+ countries around the globe came together to have the time of their lives with fellow Trailblazers, learn how to help their customers succeed, and promote equality, sustainability, and trust — in short, to transform their businesses and the world we share..." https://www.salesforce.com/blog/dreamforce-2019-infographic/
The downside of that is it means every query, no matter how simple, is a join against multiple internal tables to enforce those rules.
On flip side, meticulous saving of cpu and memory means your solutions are super constrained. You need to do all sort of tricks like 90s game programmer and still can run yourself into corner on larger systems. Back end is supremely unevolved - their serverless functions have been in beta forever and apex is like 20 years old Java.
One thing we never used Lotus for though was mail, calendar or contacts.
A calcified org like that can't move fast.
A CMO can go from shop to shop delivering nothing but broken ad tech integrations with the job of fixing the mess from the last person.
Its clunky, slow and overly complex if you ask me. But their success cannot be denied, thus they must have an amazing salesforce.
... Great observation. But what did you replace it with?
Come in, shake things up by changing a big system to put their stamp on things, (no telling if productivity would’ve gone up if nothing had happened, e.g. company was already growing), then bounce to the next executive gig before the honeymoon wears off.
> [I’ve been an executive] 2 times. First I left because of a disagreement on strategy after 2 years. The second I left because of mismanagement at the highest levels.
I’ve looked like an ass before, but I think I did OK w/ my original comment.
We obviously didn’t stay with excel :)
Great, you've replaced your CRM with Office365 spreadsheet and a documented process in a wiki. Your spreadsheet has history, so audit logs are captured and you can backup. You have a documented and adhered to process for altering data in the spreadsheet.
But depending on your use-case, Salesforce may never have been a good fit. If you're following processes that can actually be adhered to by reading a document to manage your business - your business is extremely mature, well defined and unchanging, has no bad actors (because hitting "Download" on the top-right literally exports all of the company private data) with little compliance requirements, and doesn't require international or external integration, and will never experience unprecedented growth.
If these assumptions are wrong, please share some detail because I'd love to hear about the workflow in your organisation.
How many times are we talking about here, like 2 or 20? And why did you end up leaving those roles?
Also, you can see the humor of a company’s executive saying this right?
> The second I left because of mismanagement at the highest levels.
I worked with Real Estate Agency (<20 employees) and they were looking into CRMs. After trying out half a dozen CRMs they ended up commissioning a custom one. There is no single CRM out there that is designed for you.
Oftentimes when people think they need a completely custom solution, it's because they're getting caught up on the default naming conventions and/or default sales processes (which are customizable in basically every mainstream CRM).
I would agree that no CRM is designed specifically for anyone -- that's the whole reason why any of the remotely good ones are built with configurability and customization in mind. The out-of-box-experience with most CRMs is always a traditional "product sales" paradigm, simply because that's the most common. You can definitely customize it to work with other types of models though.
- There is a special place in hell for the person who made the decision to have leads and contacts as separate objects. It creates all kinds of complexity. Some may have a need to work with leads but for clean reporting, you almost have to dump leads. Most B2B companies I know don't use the lead object and autoconvert everything to Contacts. But it has always seemed like a bad decision to have both.
- There is a long line of companies that have tried and are trying to disrupt Salesforce - none have succeed and my take is that this is because of the ecosystem and app exchange. That makes it very challenging to overcome.
- Salesforce has made improvements in their interface (Lightning is, by most counts, an improvement), but an entire industries exists to make up for the shortcomings of Salesforce. Sending emails directly or programmatically is pain, so we have Outreach and Salesloft. Entering data is too slow - so there's Dooly. Their marketing reporting stinks - so there is Fullcircle and Bizible. They own Pardot, yet somehow still can't top Marketo, Hubspot or Eloqua - which is a pretty amazing fail imho. And the Pardot integration really doesn't add a ton of value over other solutions. But as noted above, this weakness is also a strength because you've got a huge ecosystem.
If I'm starting a company right now, I'd probably go with Hubspot because there is just enormous power in the simplicity of having all of the data for both marketing and sales in a single system. Not that Hubspot doesn't have it's own issues, but reporting has always been a huge problem at every company so if I can't avoid this pain even a little, I'd consider it a big win.
They way leads is originally intended to be used, is that you'd dump a bunch of garbage into that table -- b2c data from web forms, incomplete records, mass-imported lists from affiliates/events/etc -- and then it would be the job of sales to sort through it to find the records that are of any value. You wouldn't turn them into a contact until it was determined that there was an opportunity to sell them something.
But, leads as a concept really don't make sense in some industries. In many b2b industries, by the time you interact with anyone at a company, it's already well determined who you are and what product you're interested in. This is properly entered as a contact/opportunity.
There are many reasons to keep leads out of contacts, messy imports and the unstructured nature of what a "lead" can be are big ones, traceability, unauthenticated data capture issues and ease in reporting are a few others.
It's always less of a kludge to have a system that keeps them separate but lets you seamlessly convert or associate a lead object into a contact object, when it makes sense (for lead objects that have sufficient similarity to a contact), and has an option to bypass the lead table and create a contact directly.
In my experience trying to shoe horn into a _contact only_ abstraction creates more problems because the abstraction is too simplistic or even flat incorrect for many businesses.
edit: From a sales agent "user" perspective you do often want to hide these abstractions from the UI depending on the industry and/or lead type, too many systems force their users into unnecessary duplication of effort.
Given that Salesforce is the only CRM I know in my fairly young career, I can definitely see many of its shortcomings and do not envy the engineers/product managers that have to address those.
I think if someone is starting a company, Salesforce is not the right option, both because it is extremely expensive, and its not exactly plug and play if you're looking for customizations.
Source: former Adobe employee
These types of posts are a refreshing change from what company blogs have become (or maybe always were?): garbage vendor content pushing their agenda.
I understand how Retool could be used to do some really cool stuff on top of Salesforce, but this post is also just an informative expose of an industry giant.
Justin recently did another one about Accenture, whom I worked for a while back, and really appreciate the story that is being told.
Kudos for these fantastic posts. I look forward to reading these every time i see reool.com pop up.
although all credit for this one goes to Taimur!
And while sales people tell other sales people they need Salesforce in order to not maintain a software stack of their own. Those same other sales people turn around and tell developers to maintain integration with the Salesforce APIs.
You can't restore backups! You can export your data, but there's no way to import it, because you can't set the object Id or autonumbered fields (like the case number, which gets communicated to the customer). They used to provide an extremely expensive recovery service, but they stopped doing that. That's just unbelievable for a business product.
I also can't count how many times I looked up an issue and found an "Ideas" post that's over ten years old, with 10k upvotes and no reaction from Salesforce at all. Id doesn't seem like they work on the core product anymore, they just release new things that you need a license for.
Have you tried marking fields for user set IDs as external IDs. This field can then be used while doing upsert. But what do you mean by there is no way to import it? Apart from Dataloader there are a host of companies that offer this feature.
Luckily, we used the weekly export feature and have all our data, we only need to get it back into Salesforce. But how do we do that?
- Dataloader can only restore one object at a time. We have 350 different objects.
- We need to restore the relationships between objects. They are saved by Id, but we can't keep the original Id. So we have to keep track of the original Id and the new Id for each inserted record, and replace them in every other object. That also means we have to insert the objects in topological order. If there are any cycles or self-relationships (like Account.ParentAccount), we have to fill in the Field with NULL first and update it later.
- Even after all this effort, we still can't recreate the values for autonumbered fields. If it's a custom field, we can change the type to text, insert the values and change it back. For standard fields, there is no practical way to do it. No company can help us, because it's just impossible to do using the Salesforce API.
And even those can't change autonumbered standard fields, like the case number. That's problematic, because they don't only live in Salesforce but get referenced from outside.
One of them upgraded to lightning required by some feature. The experience nice with lightning (even slower) has been worse than classic. Meanwhile the other instance is till on classic.
We made the mistake of embedding business logic into sales force and integrated with their API only later to find out it can take upwards of a minute to just convert a lead to a contact via API depending on the current load on the system.
Enterprise systems are fun.
Much of Salesforce implementation development also goes unvetted by the client. I have worked and currently work on projects where I constantly ask 'how did this ever make it into production...and how has no one noticed that this is hot garbage for 4 years'. Eventually someone digs deep enough and whoever is managing that project at the time gets the brunt of the blame unfortunately...
It’s “SaaS” which was an upgrade on what they replaced initially, but seems like they’re increasingly the ones bound to be “disrupted.”
Resolving merge conflicts in json (which is what defines a retool app) is another area where the benefits of “yes code” become more obvious. “No code” is not something I’m convinced is good. I personally think embracing code (but making it optional) leads to a platform more developers would enjoy
To pick on salesforce a bit, notice how the example of how to define the drop down they are using XML. That’s not “no code”, it’s just a constrained form of coding. Basically any library or framework that embraces code can also offer higher level abstractions just like Retool or Salesforce, without having to have the “no code” part to solve the problem. “No code” is also tangential to being a saas product, these tools could work more like codesandbox than dreamweaver or frontpage, for example.
This reads like I’m a zealot. I’m not. But there is nothing that I’ve seen that can do what it can do and, if you know how it works, you can leverage it for incredible time and efficiency savings for developing and deploying business apps.
Not because it’s hard to make a better product, many already exist. But because it’s engrained into the DNA that makes up an enterprise. At some point you just buy Salesforce. Not because you need it, or even because you want it. It just manifests itself. You don’t get fired for buying Salesforce.
- Salesforce is slow, expensive after adding add-ons, costly to customize, and visually unappealing. The older and less tech-friendly workers I've surveyed found it painful to use. The same might be said of many Salesforce competitors, including MSFT Dynamics and Netsuite. SugarCRM also has many of the same failings, but its UI/UX is better IMHO.
- Close.io, Pipedrive, Salesloft, Nethunt, Nutshell, Nimble and few others have a simpler and more engaging take on CRM that seems to be easier for a wider variety of users to adopt.
- A big chunk of CRM's perceived value is better found through sales training that focuses on qualifying customers and good work habits.
- CRM cannot turn most under or non-performing salespeople into performers.
- Many performing workers will resist adding contacts and data to a CRM for several reasons, self-preservation instinct being most prominent.
- Nurture marketing, once a CRM innovation, has become an annoyance for client/customer prospects... particularly over email.
- Predictive CRM requires either a lot of data to train, or hard to obtain signals. The concept underachieves.
The next great thing may very well be inversion of CRM, whereby your customers/clients automate the acquisition, evaluation, negotiation and purchase of products or services. At the enterprise level this exists for commodity products & services, but it's largely non-existent at the SMB/SOHO level. The normalization and quantification problem is significant, but I'm confident ML will address some of these challenges in due time.
Tl;dr ... there's still no substitute for hiring the right people. Charisma, emotional intelligence & motivation always surpasses sales automation.
I'm only half joking.
Salesforce just has a weird flow. I think I have the gist of it, but man do you have to use it for quite a while before it starts to make sense - all while you wait and wait and wait for anything to happen after you submit something. Ugh.
This thread seems dedicated to picking Salesforce apart from the technical side but you should really look at it from the business value side and as an ecosytem.
Salesforce has certainly defined digital transformation for a lot of companies.
Anyone that wants to beat Salesforce is going to have to be 10x better or come in from a new or niche angle.
No code, slack/chat interfaces and AI assistants seem to be viable paths.
It’s amazing content in an otherwise opaque category of enterprise software and services, which are so strongly embedded in part because no one knows what they do and how they’re used in practice.
Yeah it’s slow but honestly you’re spending most of your time looking at the data and writing it up, the slowness doesn’t matter that much in the long run imo.
As a user I am firmly in the camp that believes it is garbage to use and overpriced.
As a developer and contractor it paid for my first home.
It's incredibly powerful software that when implemented well, can streamline processes, provide easy access to information, and make teams really efficient.
However, it rarely seems to be implemented well.
What other typical company functions have this sort of provider?
Conversely, what other company functions need this sort of provider?
Cruddy apps like Servicenow and Salesforce are goldmines for process management. All you need to do is be marginally better than Oracle/etc.
* A single developer can be incredibly productive at automating a company's business processes. Fresh out of college at my first job I was the only developer supporting hundreds of daily users across our sales, customer support, operations, and finance departments - most of whom were basically working out of Salesforce full-time. Salesforce also proved really adaptable for supporting all of the crazy sales campaigns or operations initiatives that management could dream up - often with quick turnaround times. For me there is no question that the Saleforce licensing costs (or some other low-code alternative) are worthwhile for most businesses vs. trying to build internal systems from scratch.
* Developers are in high demand, and I have received lots of requests from former colleagues looking for a Salesforce developer - even a decade after I moved away from full-time Salesforce development. When I have accepted these offers I've literally been told I can charge however much I want (although I do tend to keep it reasonable).
* You tend to have much more direct contact with your users than in other B2B or B2C development roles. And users are often super-appreciative of even simple changes. It really is a great feeling to see the difference that your work makes firsthand, and I have had some great working relationships with sales and support managers over the years.
* The core Salesforce platform (forms and data modeling, workflow, API integration, etc.) is actually an incredible piece of product design and engineering in my opinion. I know it's getting long in the tooth these days, but the team that built all of that deserves credit for getting so much of it right. All the stuff that Salesforce has built or acquired since then, unfortunately, has been much less impressive.
* Salesforce is expensive for sure, but not as bad as the pricing on their website would suggest. Apparently nobody pays the list price for Salesforce licenses, and a 50% discount from the list prices is not uncommon in my experience.
Ultimately I am glad I decided to get out of Salesforce development if only because the developer experience with almost any other programming language is just so much nicer. But I learned a lot from the experience - and I think those early interactions with users and firsthand experience of how business are run have made me a more well-rounded developer. I was also able to use the skills that I learned while doing Salesforce development to transition into a role building web applications, and pursue a more traditional development career.
And now as I am eyeing retirement, I am contemplating getting back into Salesforce consulting on a part-time basis.
Have I wasted my time in learning Salesforce?
I know that there is what is effectively a cult following of Salesforce evangelists but I was hoping this would be valuable in the long term.
Cannot wait to see “What’s Adobe?” =)
I mean is google still just a search engine?
Us devs often try to invent groundbreaking software, while all they needed was to automate a rollodex...
I shared it with a friend that recently joined them.
JAVA BY AVON
Seems analogous to Wordpress for building websites, without actually knowing how to build websites, yes/no?
The value is in the sheer size of the ecosystem and the idea of everything being plug and play, even if the reality often necessitates actual code when you get past the happy demo path to your business's weird edge cases.
Now, I know all tech companies buy other companies. That's not new. But most tech companies also have some capabilities to innovate and building new stuff. That's an important difference. Buying a small tech company to accelerate development of a particular product is different than buying a company like Slack which already dominates the market and can be integrated into the eco system and then transition to mostly maintenance.
Plenty of companies in other industries (e.g. consumer goods) are conglomerates, often a result of acquisitions - it doesn't make them pure "investors."