A few pre-show conversations:
- The quality of the recording is better than it appears kind of like how items in a car mirror are closer than they appear.
- Doug keeps us on our toes 24/7 with his music and trying to connect it to a light motif. It’s like living in an episode of Whose Line Is It Anyway?
In actuality, we’re talking about one of Doug’s favorite subjects and one of Jess’s triggers, RFPs. More specifically why RFPs (Request for Proposals) for CRMs always fail.
Audio:
Video:
Additional Resources:
Show Notes:
HOT TAKE🔥: The best that RFPs fail is when they make it too complicated and you end up not making a decision.
RFPs in general suck.
While there are a lot of things that are not designed for RFPs, CRM is the worst because it always fails.
Why aren’t there RFPs for a position someone’s hiring for?
For example, we’re hiring a CMO. We’re paying them 300K base salary. They’ve got a 50% bonsu pool plus long-term benefit and stock. That’s worth filling our an RFP. You know why they don’t put our an RFP for that? Because it’s stupid. You can’t RFP a CMO.
Let’s talk about RFPs in general and how it ends up being applied to a CRM. Let’s be clear, if you are doing an RFP when is the last time you’ve RFP for something like a CRM or tech that your RFP schedule has been met?
The purpose of an RFP is not to enable you to make the best decision. So why do they exist? To make sure you don’t make a bad decision.
RFPs originated for and are used today to reduce the likelihood of a bad decision. When you’re buying ommoditized products, there is a clear specification.
Doug was on a call earlier this week where the company was not doing an RFP. They looked at demos and from that put together lines of technical requirements. THe way the RFP approach manifests itself is the lead tool in how you’re thinking about things, how you’re analyzing, how you’re asking people to present, etc. It’s a list of technical requirements.
What’s wrong with technical requirements?
They don’t take into account heuristics or the people. How do you RFP UI? We wouldn’t even know where to start with that.
You show someone an email that has no images and one that does. The one that has images is going to get verbal responses that it looks better, except the data shows that from an activation standpoint, every additional image reduces activation. In essence, we’re RFPing things that are not objective; they’re inherently subjective. Here’s the problem with technical requirements:
It violates the prime directive because the technology is now leading the process.
Do you know who spends a tremendous amount of money on technology?
The government.
There’s a lot of smart people who put together the technical requirements and RFPs. Here’s the thing, when was the last time the government rolled out a piece of tech that was worth anything? Why does government technology suck? Because in most cases they separate it from the people who need to use it and get the results from the people who are are deciding. What ends up happening is they speck out a lot of stone boats and they put it out to bid. You can build a great stone boat, it’s just going to sink.
What we’re doing is we’re separating the business specs from the tech specs. All of the things that really matter are at best intangible and are invisible. It takes a very disciplined process to judge on what’s important. It’s easy to fall into technical requirement.
If the first meaningful thing that goes on paper are tech requirements, you are now anchored on tech requirements, but you’re not because you can’t see the business process requirements through the tech.
Here’s what Doug knows, if we only gave you what you need to have, that wouldn’t be sufficient. A great example of this is permissioning and back-end configuration. Take HubSpot, the answer is yes. Take Salesforce, the answer is yes. The two of them are not equivalent. What do you need the permissioning for? What is that supporting from an implementation standpoint?
The problem, again, is if you’ve started off and you’ve defined this, the first thing that you put on paper is the requirements or you have a document with 273 technical requirements and you have 5 bullets for business process, you are defined techically. Then you are viewing everything through a technical lens and are reducing the likelihood of making the right choice of the tool. You’re lengthening and complicating the path to utilization and value. Even if the requirement ends up being right, the rationale isn’t there. There is no plot.
We talked about this on the episode on data architecture and structure. You have to break apart what’s going on. You have to ask yourself:
- What is the business motion?
- What’s happening?
- Where are things?
The first deliverable should be the critical user stories. You’ll want 5-7 or maybe 15, who knows! Doug hasn’t thought super hard about it. The point is you want to get to the point. The more stories you put together, the harder and the more you’re overdoing it. What are the outcomes from there? What are the tech specs? That’s where your tech requirements come in. Now start looking at the tech to see what you need to achieve the outcomes you’re looking for. What do you need to ensure so that this doesn’t blog up security elements? That’s a legitimate requirement.
From a tech requirement perspective, the only time tech requirements should be held against a CRM is the CRM fails because of this requirement, this project will fail because of this requirement.
What are the contributors to failure?
Adoption and utilization. A really good user story will include sophistication of the team. You can build the failure element into the user story. Invest in the user story.
Don’t let the tech people define the product. Get out and talk to the users.
The moment you start with tech specs, you’re always going to work sub-optimally. Start with your business motions. Create your user stories, define the outcomes, then establish your tech specs. Create a scoring rubric based on those user stories and use cases. If you do that, the RFP and tech requirements will align you with the right direction.
Technology will never be the reason you succeed. It’s often the reason that you fail.
Why don’t we throw out the RFP? Because it’s a failure prevention device.
Doug’s Final Statement: The tech requirements are there to prevent failure, but just because you’ve met the tech requirements doesn’t mean that you’ve bypassed the primary cause of failure. It’s the why elements that are ultimately going to determine success or failure. The tech requirements put you in a fail mode before you have a chance to be successful.
Jess’s Takeaways:
- The process that you outlined by focusing on business motions, laying out the outcomes and user stories first, that’s going to shorten your timeline to utilization and adoption.
- Focus on the outcomes, not the results.
- Remember what you’re looking for.
Next Steps:
-
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
-
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
-
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
-
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
-
-
Subscribe to the show on Spotify & Apple Podcasts
-
Check out Let's Play RevOps on Twitch for more commentary on this topic
-
Listen to Episode 63: Playing to Win - Defining the Role of RevOps in Strategy