A “pivot" is startup-land terminology for changing some aspect of your idea. It could be changing what problem you’re solving, how you’re solving it, who you’re solving for, or something else.
As a founder, it’s hard to decide when it’s time to make a big change. On one hand, building a successful business from scratch requires persistence and perseverance. On the other hand, it requires constant strategic iteration.
There’s a lot of advice online on the topic of pivoting (I like this piece). With this post, I thought I’d share why and how I’m approaching it for Rubric.
Why
The main reason is the lack of a market for easily creating and using structured interview rubrics. Most hiring managers that I have spoken with are not searching, evaluating, and paying for ways to solve the problem that rubrics are hard to make. I shared my concern with this “value risk” in more detail in my last post.
Since that post, I completed another five sales calls. The calls were positive but, again, have not yet resulted in a paid customer. All of these calls concluded with a version of “yes I think this could be useful, let’s follow up with next steps via email”. These were the results of following up:
2 resulted in not hearing from the person again, despite multiple follow-ups.
2 resulted in asks for a couple of enterprise features and involving multiple stakeholders within the company for review and approval.
1 resulted in a customer asking for and getting set up with a 10-day free trial. 🥳 It felt great to have a cold lead (not someone I knew nor was a referral) convert to a free trial user! This was a first for me.
It’s likely possible that I could convert one of the existing leads into a paying customer with further follow-up. But, eventually, I believe I would need to make a larger change anyways in order to retain these customers or acquire more new ones.
How
Pivot path #1: Solve a related problem
In at least two of my sales calls, companies were also in the process of evaluating technical interviewing platforms — specifically CoderByte and HackerRank. These platforms focus on helping companies assess the technical skills of engineering candidates.
There is considerable overlap in the benefits that these products claim and that which Rubric provides. The difference is that these platforms focus on the technical interview while providing a more comprehensive solution for that type of interview.
There’s an established and growing market for these tools. The challenge, as with any established market, is that it’s crowded. So, are there meaningful opportunities to differentiate? Even for a subset of users? This is what I need to find out by talking to companies who are using these products and candidates who have encountered these during interviews.
If you’ve used or evaluated one or more of these platforms before, I’d love to chat!
Pivot path #2: Solve a different problem
Going back to early user interviews with tech managers, finding high-quality candidates was the most common and painful problem. I could tackle this urgent and important need directly. Hiring marketplaces like Hired and TripleByte are examples of one approach to solving this problem in a scalable way.
Again, it’s a crowded market of recruiting tools and services but the winning differentiator is going to be the number of quality candidates. It’s also important to note that the recruiting team becomes a primary stakeholder, if not the target customer, in facing this problem.
The exciting part of running a 2-sided hiring marketplace is that candidates are also customers! It’s also the riskiest part. How can we provide value to candidates in order for them to join? This is what I need to de-risk by talking to candidates who have been or are considering entering the job market.
If you’ve used or looked into using Hired/Vettery or TripleByte, I’d love to chat!
Pivot path #3: Target a new customer
The first issue of this newsletter stated the importance of choosing a customer that I’d be excited to serve, has tractable problems, and has paid money to solve them. So far in this journey, I’ve focused on tech managers (eng managers in particular).
I’m excited to serve them and I believe they have access to budgets for valuable tools. But, in observing the landscape of tools, there are few that tackle eng manager problems directly (outside of 1:1 trackers like 15Five or Fellow.app). Instead, there are hundreds of tools that solve problems for developers or solve problems for tech teams.
Maybe it’s a consequence of the role. The best managers I know practice servant leadership. Maybe I should be looking to solve meaningful problems for the people that managers serve.
If you’ve got problems, let’s chat! 🙃
Note to self
It’s a marathon.