Dropping reference checks (and biases) ❌🧐
Dropping reference checks (and biases) ❌🧐
Replacing reference checks with post-offer feedback calls, assumptions that distance product teams from the rest of the org, and crafting a sales back-end first.
Welcome to the 57th edition of The SaaS Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay (curated with 💛 at Chargebee) and the interwebz. So, stay tuned!
In this edition, you’ll find following instructive and inspiring pickings:
#1: Float’s co-founder and CEO, Glenn Rogers, on pausing to introspect what a treasured hiring norm (reference checks) actually delivered (often: stresses and biases) and how they went about recasting it.
#2: Apptentive’s co-founder and CEO, Robi Ganguly, identifies assumptions that weigh down heavily on product’s inter-team collaborations.
#3: BurnRate’s co-founder and CEO, Robert McLaws, lodges a note on why chasing top of funnel in the early days is a senseless exercise without structuring (however leaky it might be) a sales back-end.
🗞 Recently on Relay:
Heuristics and Hunches — Founder-Led Customer Success, Bringing in a Senior First Hire, and Other Early-Stage CS Lessons with Claap’s Head of Customer Success, Angela Guedes
Quite like sales, it’s always good for founders to be the first CS person. To get to know the users from a service end. To really understand how the product addresses the problems post sale. Not to mention, making sense of the first, new use cases that show up.
#1: “Why we stopped checking references for new hires”
(From: Float’s co-founder, Glenn Rogers) (Source: Float | Blog)
On the surface, reference checks feel like a free round of insurance. But insurance is never really free, is it? It comes at a cost that’s borne by both sides:
It creates stress for the candidate. Without a formal offer to fall back on, the candidate must navigate tricky waters with their current employer by contacting co-workers who may not even be aware of their intent to move on. They do so without any guarantee of a job offer at the end of the process.
It adds risk to the hiring process. Introducing new people to the final stages of a hiring process adds an unknown variable. Contacting references can be time consuming, as you must align on a time and a medium to share feedback (which can be difficult for a fully remote team like ours). Timing is everything when hiring, and any delays compound the risk of losing the candidate entirely.
The results may be biased. If a candidate believes they’re close to an offer, they’re likely to reach out to references they know will maintain a narrative we want to hear. They rightfully stack the deck in their favor.
When we analyzed the results of our last ten hires, none of the decisions we made were impacted by a reference check. So we’ve simply stopped doing them. Instead, we’ve started a different conversation.
…
Post-offer feedback calls
When we’re ready to put forward an offer to a candidate, here’s what we do:
1. We put forward the offer. No strings attached. No reference checks.
2. They accept the offer (we hope) and submit any follow-up questions.
3. We ask them to connect us with a current manager or co-worker before their proposed start date. We make it clear that this is not contingent on the offer.
4. Once the contract is signed, the person’s new manager at Float reaches out to their contact to schedule a short Zoom call.
…
Needless to say, we won’t be going back to the old ways. Not only has it reduced candidate stress and improved our time to hire, it’s also delivered an additional benefit that I wasn’t quite expecting: the quality of the conversation with the person’s co-worker has dramatically improved.
They’re aware that their co-worker is moving on and speak openly, even nostalgically, about their time together. They delve into the qualities they loved about the person and the projects they enjoyed working on together. They also candidly share detailed annoyances—the small things that they think the person can improve.
#2: Internal assumptions that impede product teams
(From: Apptentive’s co-founder, Robi Ganguly) (Source: Product School)
The question about metrics, the question about how you measure success as a product person, how you influence others in the org and how you get them aligned around the same metrics is an ever-present question. Regardless of the size or the complexity of the company.
…
What we see is really successful product teams are able to connect the company goals to the metrics they’re trying to drive. And they get agreement on the connection between the two.
Product teams that tend to struggle have company goals and product goals that are not clearly connected. And as a result every 3, 6, 9, or 12 months planning cycles come up. Strategic decision-making comes up. And the conversation about where to go with product almost feels random.
Because they don’t have a set of metrics that map to the agreed-upon north star of the company. Making sure that these things are connected helps refine the way that product shows up for the company as a whole.
As they can always come to the table and say, ‘we’re moving these metrics and as a contextual reminder, it moves this piece of the business forward, this is why this metric is important.’
‘You might disagree with what we’re doing to move that metric. And we can have a very healthy conversation about how this piece of feature work that we’re prioritising is more important than this piece that you say is going to move the metric more.’
But a lot of times conversations that product [teams] find themselves in is, ‘we have a feature, we have some capabilities, we’re investing, and we’re moving what we think is important to our metrics.’
Then somebody else says, ‘you should do this other thing, it’s more important. And we can’t have a dialogue about why it’s more important because the metrics are different…’
That’s the first step. If you as a product team can really align your metrics and your measurements to the company goals you always have an opportunity to be more agenda-setting and be more conversant with people on the same level.
…
There are so many tools and there are so many options for people to access the data out of those tools that I would say, one of the problems in the ecosystem now is: self-service is not enough.
What do I mean by that?
If you’re a PM and you exist in an organization that has multiple teams responsible for the agendas that you’re driving forward. And you say, ‘well, I publish my data or my data is available in this tool, you got to login to see customer data and what’s prioritised…’
Just because the people on your team or people in the organization could doesn’t mean that they do. So what I see sometimes is, ‘hey, there’s a lot of data available, but then the job of the PM is still to contextualize the data and present them in a way that for the audience, it resonates…
‘We look at this every week. We’re totally familiar with how the dashboards work. We’re completely familiar with what we take as real information and what we discount because we see it a lot.’
Those kinds of choices that you do on a day-to-day basis when you’re living it. But that doesn’t mean that the audience that we need to convince that this is important is [as good] at looking at the data.
It doesn’t mean they log into the dashboards when we tell them to, it doesn’t mean they interpret the reports the way we think they should.
So part of the motion becomes: Once a month, once a quarter, maybe once a week, you’re walking the relevant stakeholders through ‘hey, here’s an update’ so that they’re conversant enough for everyone to be on the same page.
#3: “Where startups screw up really early is not having a specific sales process”
(From: BurnRate’s co-founder, Robert McLaws) (Source: Minimally Viable)
[In the early days] worry less about your top of funnel. You can have four new leads come in a month. Where startups usually screw up really early is not having a specific sales process and testing that sales process early.
Where we benefitted was I knew how to build a sales pipeline. It was leaky but I knew the basic concept and the structure and so we didn’t have self sign-ups on the website. We still don’t.
You got to go through a person to get onboard. And the reason for that is I want to test the back-end of our sales process first and make sure that works.
Because if you make sure that leaks as little as possible, with as little spend as possible, when you add outbound to the top, you add paid ads to the top, you’re not leaking 90% of your customers out the back-end because you don’t know what you’re doing
So when you’re testing outbound or messaging, you’re testing that and not your sales process too. Because you end up testing too many variables, you can’t control for any of them and you learn nothing.
In the mean time, you’re burning cash like crazy, and you die well before you get to those answers.
🤝 Founder social:
Until next time,