One of the key takeaways, and one that was really obvious in the last interview is that you should do things that don't scale. It's hard to distinguish between actual roadblocks to your business as compared to itches that you just need to scratch, especially when you are a developer and your itch can be solved through a technical solution. Developing a solution for that non-critical problem allows you to feel like you are making progress when, in fact, you aren't actually moving your business forward at the pace you should be. Having someone question your roadmap with an external viewpoint really makes it clear when you are going down a rabbit hole and that is where the value of these office hours seem to lie.
> Developing a solution for that non-critical problem allows you to feel like you are making progress when, in fact, you aren't actually moving your business forward at the pace you should be. Having someone question your roadmap with an external viewpoint really makes it clear when you are going down a rabbit hole and that is where the value of these office hours seem to lie.
It's all about balance. In the first year or so you can afford this but later on you definitely should make room for non-user visible items on your roadmap otherwise sooner rather than later you'll find your development stagnating due to mounting technical debt. And just like real debt there is an escape velocity element there: too much technical debt and your progress will slow down to nothing while your competitors are still moving forward (provided they do a better job).
This is a real risk, one I've witnessed in several start-ups over the last couple of years. Fortunately, once identified it is relatively easy to get moving again but it can really creep in unseen.
The office hours was a great experience! We got valuable advice, learned where we were weakest, got experience with public speaking, and it was free marketing. Would love to hear what y'all think.
Philip here from MoonlightWork.com (the last team in the video). The advice from Sam and Yuri was great. In our startup school office hours after this on Friday, we were also advised to take a more depth-first approach.
So, takeaways:
1) We found an invoicing system that's compatible with Stripe Connect, so we're working on completing a first project this week.
2) We're focusing just on code for now, rather than design and code at the same time. We want to partner with some open-source project maintainers with the goal of helping them earn money and build a job ecosystem. Our first Moonlight projects have been through my own open-source projects (github.com/staffjoy). If you maintain an open-source project, we'd love to talk about how we can help you create jobs around your project - please shoot me an email philip at moonlightwork.com.
Apparently they saw us post an intro in the "Loc: Bay Area" chat channel in startup school. Beyond that, I'm not really sure. From what I understand, they are doing this type of group office hours a couple more times during the course.
Hey Laktek! I reached out to Philip and Emma because they were Startup School founders in the Bay Area. That made it a lot easier to have them come by.
Several years ago some YC partners noted that the startups that did poorly had a common attribute: they tend to ignore advice given during office hours.
The interviewers are experts at office hours, but the interviewees are not. I think it would be interesting to see a) startups ask more questions in their responses rather than make assertions, regardless of whether they are "sure" they have the answer b) have a mechanism of action; for example, stop developing x and start getting revenue -- because otherwise nothing will be learned. Then follow up in a couple weeks to see results iff they decided to act on the advice.
