What a classy way to set your tools down. Also the new startup sounds great. Reading this made me trust this guy and want to work with him if I ever had the chance. I'm sure he and the rest of the team will pull off something good one day.
Thank you for doing this -- all of it. It seems like you've built up a tremendous amount of goodwill and I hope it will pay off for you, in what seems like a much more focused new venture. If you can capture 10% of Craigslist's reach without the sketch, you should be OK :-)
> Control money to make money. In workforce management, I now realize that controlling payroll data is key. It’s tough to quantify the creation of value otherwise.
My (fuzzy) interpretation: since we weren't integrated with the payroll/hr/accounting systems, we could not prove the efficiency gains our product was meant to bring with hard numbers.
On the one hand I agree that integration with payroll systems is probably critical in this space.
On the other hand, if your product brings a 10% efficiency improvement (which is still huge, not discounting that), it's still going to be hard to prove that, even with access to raw payroll data. Raw payroll data is probably too noisy.
What I meant is that we were not a key link in the workforce lifecycle chain. Without us, people still got paid.
Our V1 timeclock product garnered a lot of interest because it directly led to people getting paid, and it integrated with scheduling to make it easy to tell whether records were correct. I now understand that many more established players, like Kronos, started with payroll as a core feature, then diversified to scheduling.
How this lesson applies to my newco Moonlight - we're charging a transaction fee and managing payments, rather than doing something like a SaaS subscription model.
The challenge that I'm sure you're aware of is the risk of being disintermediated by your product (consultants) and/or your customers (people needing consultants). I'm not convinced the situation is impossible, but the history of such marketplaces isn't a strong recommendation for building more of them. I totally agree with the thesis that the future is remote work, but personally I would focus on ways to improve the notable problems about remote work as opposed to matchmaking. There are many people trying to do matchmaking, and not nearly as many focused on improving the challenges once the match is made. I suspect that's at least partially because it is hard, but hopefully your current direction will give you an unfair advantage when it comes to finding solutions to this hard problem.
Anyway, first rate blog post and handling of a difficult situation!
I'll join in giving kudos but I want to be a bit more explicit.
There are two categories:
Both are multiple good/service providers
Both are multiple goods/service recipients
I think the difference for something like Uber and Airbnb is that they embrace chaos. It is better for them to have someone take a different Uber or stay at a different Airbnb everytime.
The problem I think it's that you have to be sleazy enough to pull this off. You have to be like Airbnb with its promotion of instant booking going side by side its promise of community and kumbaya blah blah. I trust I don't have to say anything bad about Uber. Plenty of ink had been spilled already.
You want a constant stream (or late enough pool) of work and of workers.
Here's an idea to test: do employees react favorably to "quantization" of work?
Example: we think our conversion sucks because blah blah. We want to create a new set of landing pages and develop a way to show it 10% of the time. We want a whole new team to do it so it doesn't distract of full time staff from the fires they're putting out with the real application.
Just spit balling... Would love to hear what everyone thinks about it.
Back in the 1980s I worked as the "computer guy" for a McDonald's franchise. Even then we had a crew scheduling program, it was written in BASIC and ran on a '286 IBM PC.
Thing is, it was part of a comprehensive system that handled accounting, inventory, and payroll as well as scheduling.
If we didn't have the integration with payroll, to know who the employees were and their status, it would hardly have been worth using a stand-alone scheduler if that meant maintaining a shadow copy of the employee file.
> Good technical talent is hard to find. When in hiring mode, I spent about a third of my time trying to source and close candidates. Hiring a candidate through a recruiter can cost $20K or more.
Good, cheap (and let's be honest, gullible) technical talent is hard to find.
What a downright decent human being. I like the part where he concerned himself with finding his employees jobs. I like to think this is the kind of CEO/Founder I would be if I ever start a venture.
Yes - Mobius used a lot of the Gurobi API features, including tuning the model before deploying. It's a pretty vanilla use of their library.
I'm more proud of the Autoscheduler algorithm in Julia, which uses a bunch of different models in a kind of Dynamic Programming approach. Check out its README for an explanation:
If anything this suggests the opposite. They showed initial promise, raised seed funding, tried to grow, couldn't, so they gracefully wound down before they wasted any more investor money and employee time. This is exactly how things should work in a healthy economy.
