Earlier this year, Wethos’ co-founder and CEO, Rachel Renock (@rachren) dropped a clarifying reminder on why product-market fit isn’t a “black-and-white” binary, but a complex trifecta. Inextricably and uniquely bound by a seldom-examined third element: a fitting business model.
Exemplifying how not just the problem you choose to tackle, but the software category you pursue it in, and the GTM motions you apply, can all be deliberately chosen to reflect your particular strengths, reasons, and aims.
— The “classic misunderstandings” of early-stage hiring
— How Eduflow founders operate as generalists to enable many specialists
— Why you don’t need “top talent” across functions
— Why they pivoted despite having hit PMF that still results in consistent revenue
— Moving extremely fast (like 30-minute-integrations fast) and saying no to meetings
Hiring pains (and their subsequent learning curves) can surface quite early.
Assume that you’re a business person, and you need to build a software startup. If you can’t write code, it’s a pain to not be able to develop the product you want to build, right? So if you cannot start out without a great technical base, you should probably hire somebody.
What I really want to advocate to people, though, is to not hire somebody just because you think you should have a person doing X and not necessarily a real need.
Let’s take marketing. Or even sales for that matter. Many hiring mistakes originate within those two functions. Founders might think: ‘oh, we should have someone run our Facebook ads because that’s what everyone else is doing.’
Then they try to hire someone with that vague impulse. But they don’t themselves yet understand what performance marketing means for their business, as they don’t have any direct experience doing it.
Or perhaps the founders are simply afraid. Not ready to sell, for instance. Afraid of the rejections inherent in sales conversations. So they’d say, ‘well, we should bring in a salesperson or onboard resellers who’d sell on our behalf.’
But it’s really important to market/sell on your own as long as you possibly can. And only when you’re overburdened with work, that’s real hiring pain worth attending to.
We learned this the hardest way possible. Bringing in and having to let go multiple salespeople. Because we didn’t realize that you hire for sales when you want to scale, not to get started with the function.
And this realization has since become a sort of hiring principle at Eduflow. If we wish to do something new, it is difficult to fill that position. But when we know what we’re doing, we know what works, but just don’t have enough time for it, that makes hiring much simpler. Because we know exactly who to look for in a candidate.
And, more importantly, it makes things simpler for them. A lot of founders think that it’ll be great for a new hire to come in and define their job on their own. That’s a classic misunderstanding.
I get that people value flexibility and freedom, but they also want (and deserve) absolute clarity on what they’re hired for. Founders overestimate the value of a blank slate.
Realistically, it’s just easier for technical people to learn business skills than it is for business people to quickly acquire technical skills. You can try to get around that point. But that’s just how it is.
You can’t just sit down for two weeks and learn enough code to create a web app. But you can read a book, listen to a podcast, and consume a few blog posts, and be ready to try out some real marketing ideas.
Luckily, we were three technical co-founders. Varied in our technical capabilities but we could all code and we started building from day one. Thus we had to learn everything else the startup needed.
For those other bits we didn’t take a course or anything. That’s what I’d recommend to others. Just learn the hardcore, technical skills you’d need and figure out the culture side, the marketing and the sales side, as you go.
Because if you can do 70% of sales, naturally, then getting to 80% or even 100% is a matter of studying, practicing, and just doing more of it. Even if you stay at 70%, though, you’ll still move forward.
Seven years into the company, we still take care of a lot of these non-tech blocks among the three co-founders. I own churn tracking. I spend time on chat support. I run daily sales conversations. My co-founder, Simon, who leads our product, also does sales calls.
In some sense, the three of us work primarily as generalists, covering many roles together. To make sure that the specialists we’ve hired can work on focussed things and not worry about anything else.
Aside from us, there’s one other generalist role. A person who operates on founder-level breadth with responsibilities that concern many small things including customer support, contributing to the blog, managing swag for conferences, and other stuff that I would do.
At this very moment, we’re hiring for a dual role. We need someone to take over customer support and also do some community management for the courses that we run.
Why can’t we hire specialists for each role? Because we know that both don’t quite make for full-time positions, but together, they do. This person will tend to chat support, host some customer-facing events, and help craft some courses.
I believe founders overspend if every time there’s a problem, they reach out to hire someone full-time. If you’re venture funded, maybe it makes sense and you can afford it. Pretty dangerous slide otherwise.
If there isn’t enough work, people will be forced to make some work up to fill the day. And if there are too many people on the team mostly doing this filler work, you’ll still grow but not in a unit-economics-friendly way.
Hiring for dual roles has obvious disadvantages. We’re not going to find the best customer success person in the market because they’d rather not have a dual, slightly generalist role. And similarly we’re not going to find the best community manager either.
We’ll likely find someone who is decent at both. In my opinion, it’s a worthy trade-off.
There are parts of your business that need top talent, and then other parts that don’t. I don’t need the best CFO in SF, because of Eduflow’s current finance requirements. But because we’re so product-leaning, we need the best tech hires we can find.
A related thread is one of focus. If everyone on the team has many things to do, it means everyone focuses on nothing. Take my case. I’m always in the middle of 100 things. Slack. Emails. Calls. Repeat. I’m Mr. Interruption. That means I don’t produce deep work.
Which is fine. Because most other people on the team can focus and experience the linear and nonlinear benefits that accrue from constant focus in areas where quality matters most.
With content marketing, a great blog post can easily outperform 10 or more blog posts that weren’t as good. So we have a specialist contractor owning this and only this. Isolated from the rest of the internal mess. Just getting this one piece right.
A core philosophy of ours has been that we don’t want a large team. It springs from the fact that none of us likes managing a lot of people. We’d rather make things we’re good at.
This directly informs our product choices. We have a freemium product where users can play around, try out the first few things, and reach out to us only when they’re ready to buy. And we can help negotiate pricing terms and help set up more sophisticated configurations.
Whereas a more traditional product will require many customer touch points from onboarding to closing a deal, which wouldn’t be entirely feasible for our small team.
So, we do have a fairly long sales cycle, but we only participate towards the end of it. Otherwise we will exhaust ourselves dealing with enterprise bureaucracy.
This self-drawn constraint isn’t perfect. We do limit growth because we’re not actively going out and knocking as many doors as we can. But it makes us incredibly profitable in terms of clean margins; a small team that does fairly large deals.
This mindset also informed our pivot three years ago. Before Eduflow, we had built Peergrade, a peer-to-peer feedback product. With very promising PMF signals that last until today (I talk about this aspect below), we found ourselves in a category-creation scenario. Ours was the best product for sure, but we had to drum up demand from scratch.
Eduflow, on the other hand, is a corporate learning management system. Tons of (legacy and new) competitors. And we deliberately chose this space, because we’re a great product team, not a great sales/marketing team.
We aren’t the team that’ll create a new market, but one that can out-innovate alternatives in an existing market. Here, too, growth will take time. It’ll be frustrating. Almost every customer says they’re evaluating us among four other products. But we believe we’ll win in the end as we continue to compete on our strengths.
When it comes to culture, the most prized principle is that we move extremely fast. I know a lot of people talk about this. But we really mean it.
If a team member has an idea, they can just try it out immediately. If someone in marketing feels we should sponsor an industry newsletter, they should just spend a couple of hundred dollars, buy the ad, and not talk to anyone about it for “brainstorming” or approval.
These are small decisions where it doesn’t make sense to discuss them, one can just execute.
Recently, on a sales call a potential customer asked if we had a Canva integration, and I said, ‘unfortunately, we don’t.’ Right after I dropped a note to the product team saying if we can launch a Canva integration ‘right now.’
30 minutes later, we had a Canva integration up, because of the way we’ve built Eduflow, it was easy to get that up. And I, a happy founder, immediately wrote back to the customer saying that now we do have a Canva integration in place.
Perfectly up our ship-fast alley. Sometimes, we have product people who’d ship something new from the roadmap, all in a single afternoon.
No meetings. No extra prep. No analysis. If we have an idea, given the amount of time we all spend with customers, we know we can just get it out there and learn. Anyway, like most ideas, it’s probably a bad idea. The quickest way to figure out is to fail fast.
And moving fast doesn’t mean we’re not building for the long run.
For example, we stopped working on Peergrade more than three years ago now. No product updates at all. No marketing, no emails. Nothing. And still today, three years later, revenue is exactly the same as we had left it as none of those customers have churned.
That’s crazy stability. So, yes, we’ve set an extraordinary velocity for shipping but it remains laser focussed in the direction of making something that’ll last.
The other, I’d say, enabling half of this principle is a few-meetings culture. I have a lot of meetings given that I need to talk to customers and so on. But internally, we have almost no meetings. Here are the few that recur:
- The only recurring weekly meeting we have is for co-founders, a chat on Zoom to talk about everything.
- Then there’s a monthly tech meet to prioritize what to build next, which is asynchronous by default, but if there’s something worth discussion, it’s followed by a ~45-minute Zoom sync.
- Then, every second month, I do 1:1s with everyone on the team.
What that means is that, if you’re a tech person at Eduflow, you’d mostly just have one meeting a month. That’s it. You can schedule your own calls, say, to run feature syncs with the CTO, but otherwise there’s nothing else. Just one standing meeting on your calendar.
The rest of your calendar is open for building stuff. Which, I’ve found out, is insane compared to most companies. A unique promise we can make to product folks.
I recall seeing a thread on the YC slack perhaps, where someone was requesting advice on how to do weekly all-hands on Zoom? And my first reaction was, ‘weekly WHAT?’ Why would you force the entire company to sit and spend a whole hour on Zoom on a Friday? Why does it have to be live? Just send them an email.