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.
