#20: You need a low-anxiety hiring process đ§ââď¸âŽď¸
Asking people what they'd pay with insight and empathy, building diverse technical teams, and defining a vision to differentiate your product.
Hi there,
Welcome to the twentieth edition of The 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 and the interwebz. So, stay tuned!Â
COVID hit home at Relay these past few weeks as India reels with the onslaught of the pandemicâs current wave. Weâre slowly getting back to regular programming. But thereâs a long, arduous road ahead for the country. For those looking to help, please check out this list. Thanks, as always, for reading; we hope you and your families are safe. Keep taking care!
In this edition, youâll find instructive and inspiring pickings from the brains of Geocodioâs Michele Hansen, Progressionâs Neil Cameron, and Wistiaâs Chris Savage.
#1: How to ask people how much they would pay â Geocodioâs co-founder, Michele Hansen, trains her astute, incredibly empathetic, customer development rigour on the pricing question. (Source: Deploy Empathy)
At a high level, the way to ask someone what theyâd pay without asking them what theyâd pay is to ask what theyâre currently paying.
They might be paying in terms of time, in terms of money, or, most likely, both.
What we also want to find out is the frequency of those time or money payments.
One of my favorite tools to use during interviewing is a Pain and Frequency Chart. Itâs similar to the Problem Size/Frequency chart used by Des Traynor.
The idea is to map all of the problems we hear on a 2x2 grid of pain and frequency. Problems that are highly painful â lots of time, people, or steps involved â and high frequency are our prime fishing groups for product ideas.
Low frequency/high pain can be a good quadrant (like buying a house) as can high frequency/low pain (conventional âpain killersâ). But you should avoid low pain/low frequency problems like a crowded indoor space without ventilation. (I used to say âlike the plague,â butâŚ)
In the same way that you apply this to the overall problem selection process, you also want to apply this to thinking about pricing and pulling information out about how much someone might be willing to pay.
âŚ
The next time you want to figure out how much someone would pay for something, here are the questions to ask.
Note that when youâre asking about what people pay for things, you want to be extra polite. Say âCan I askâŚâ rather than âWhat doâŚâ
1. Can I ask what youâre currently paying for that [tool] you mentioned
2. And can I ask how often you pay that?
3. Could you tell me how long [particular step] takes you?
4. Can I ask how often you have to do that?
When you ask these questions, keep the pain and frequency matrix in mind. You might find it helpful to literally map all of the different problems youâve heard onto that matrix to help you choose which problems to solve.
I suggest keeping an eye out for the high pain/high frequency problems in particular.
Once youâve decided on a problem, these questions will tell you what kind of billing model might work (usage-based vs subscription vs some combination).
Determining the final price will involve more work on your end (itâs one of the most complicated parts of having a business in my opinion), but finding those high pain/high frequency problems and nailing the billing model to match customerâs mental model of the activity is the first step.
#2: âWant to build a more diverse engineering team? You need a low-anxiety hiring process.â â Progressionâs co-founder and CTO, Neil Cameron, shares a thoughtful corrective to the dated yet abound, prevailing hiring approaches. (Source: Twitter)
It starts with the screening stage.
Make it a chat a between two humans rather than the first round interview between a candidate and hiring manager.
Tell them about the team, the vision the upcoming work.
Ask them to tell you about themselves, what they did in their last role and what theyâre looking for in their next role.
In my experience this is enough to know if they would be broadly a good fit for your team.
So far so good.
But the technical interview is where things can get anxiety inducing. Here are some things we donât do in ours:
Whiteboard coding
Fizzbuzz / algorithm challenges
Pair programming
Ask questions from a ComSci textbook
Here is what we do in our technical interview:
Ask about a time when they solved a complex problem that they are particularly proud of
Talk through security and scale
Work through a case study i.e how would they build feature X? How would they account for constraint y?
Oh, we also email all the questions in advance so candidates donât have to worry about getting stumped.
In fact we try to over-communicate through the whole process so the person applying knows exactly where they stand at all times.
But how do you spot those that talk-the-talk vs walk-the-walk?
Firstly, if the technical interview is done well, you can go deep into the details, ideally until you get to a ânot sure about that, Iâd need to checkâ.
Itâs hard to consistently fake at that level of detail.
Secondly, we find a way to look at code, any of these will do:
Open source contribs
A public repo
A peronsal project
A previous take home challenge
None of the above? No problem, weâll set a short (2 - 4 hr) take home challenge that fits with your schedule.
If you get to this stage with us, you will have invested significant time and we genuinely appreciate it.
If we donât proceed weâll do our best to provide actionable feedback and introduce you to companies that might be a better fit for you.
The final stage is a âteam fitâ interview. We donât want to create mono-culture, so we donât think of it as a âcultural fitâ interview.
We do a 1hr chat with Jonny Burch (Neilâs co-founder) and another team member. We talk about past experiences, future plans, values and what motivates us.
Weâre not looking for more people like us.
Weâre looking for life experiences and points of view that broaden our outlook, compensates for our blind spots and compliments our team.
And thatâs it! We normally get through the whole process in a week or two. Our hope is that we can provide a low-anxiety, dare I say it, an enjoyable experience where we really get to know our candidates.
Why is this important to us though?
Weâre building a product that defines what good looks like for millions of people so itâs massively important that our team reflects the diversity of our users.
#3: Define your vision to differentiate your product â Wistiaâs co-founder and CEO, Chris Savage, on a years-in-the-making realization: âWhen we buy software today, weâre not just buying into the current benefits, features, and price. Instead, weâre making a bet on the productâs future.â (Source: Wistiaâs blog)
When we were starting, we noticed that people used Wistia for a million different things including internal training, collaboration, sales, marketing, and more. That felt fantastic.
The hard part is that when people use your product for so many different things, itâs tough to focus on any one use case. This is doubly true early on when youâre on-your-knees grateful for every customer that you can get.
Our website during that time revealed to our potential customers that we didnât know where our product was headed. When you donât know who youâre building your product for, itâs difficult to imagine the future.
During that time, our business struggled â and that struggle lasted for 4 years.
But then, we made a change, and Wistia took off at an unprecedented rate. This change was both incredibly simple and profoundly transformative.
We decided that we should focus primarily on video marketing. You can use Wistia for collaboration, internal training, and more â but Wistia is built for video marketing.
That resulted in an inside-out change for our company. We focused our external marketing site on the video marketing message and carried that through internally to our product roadmap, customer success, and even the way we talked and thought about our company on an individual level.
Everything we did reinforced the video marketing focus. By honing in on the vision of where we wanted to go, we made it easier to make product and marketing decisions that reinforced our value proposition.
For prospective customers, that clarified the future of Wistia. People told me the day that they saw Turnstile for email capture was the day that Wistia clicked for them. They could finally see where we were headed and why we were so different. That moment fundamentally changed their perception of us.
Our audience could look into the distance and see that features like Super Embed and Turnstile would become more and more powerful. They knew that better analytics were on their way. They could envision being a part of a community built around video marketing that didnât exist anywhere else on the web. By honing in on our vision, we began differentiating our product.
Note: Chris Savageâs reflection was curated as part of a response to a founderâs question on differentiation. It also features founders from GoSquared, Userlist, Know Your Team, and FYI. If, as a founder, youâve deliberated over this decision, weâd love to join the conversation.
Recently on Relay:
AMA: With Flodeskâs co-founder and CEO, Martha Bitar
What Am I Missing: How to tell people your product is really different than the other tools they know that market themselves similarly?
What Am I Missing: Being a SaaS founder, I often wonder if Iâd be better off knowing how to code⌠Any other non-coding SaaS founders making it work?Â
Until next time,