Snaptalent Lessons Learned - Lesson Three - Spend Time on Things That Matter

We mitigated these sorts of issues in TicketStumbler by having clearly-drawn lines for who was responsible for what. This was easy for us because we had a two-man team consisting of one technical person (me) and one business/everything else person (Dan). I would occasionally explain technical decisions to Dan, especially if they were going to take a while to implement (rewrites, etc.) This had the added benefit of forcing me to talk out an issue and better justify it to myself.

This made for some fast decision-making. The only downside has been that following his death I am still being charged for services I wasn't even aware we had and for which I have no non-violent method of cancelation. However, this is obviously a rather extreme edge case that most people won't have to deal with.

The main issue highlighted in the post regarding cell plans is a bike shed-style decision. These are problematic because anybody can take a few minutes to research the space and come up with valid arguments for/against another person's recommendation. Generally, the best thing to do in these cases is to simply defer to whoever broached the topic and have them make a decision; they had a head start on research and cared enough about it to bring it up so it makes sense for them to own it.

I gotta admit it takes a lot of guts to fess up things like this. I looked at the "Stupid Things We Did" and was shocked at how stupid some of it really was considering that these people were calling themselves founders and even had investors. But then I suddenly got reminded of how I once spent a week creating a scrollbar from scratch in ActionScript for a product that nobody cares about now. I've also spent a lot of time writing my own libraries because they are cleaner/more-efficient than existing utilities out there only to throw them out completely because the specs changed. Had I used a slightly bulky off-the-shelf library, I would have saved a lot more time and could have replaced it with my own code if the library caused a bottleneck.

As I work on my new project now, I keep asking myself "Is this actually going to matter to anyone except my OCD-self/ego?" If yes, then I do it. I've wasted too much time because I'm a stickler for file-naming-conventions or got stuck with one weird bug that only affects 0.1% of my target users.

I think that everyone pre-revenue is almost by necessity focused on the wrong things, because there's no way to quantify actions. Post-revenue, everything's easy.

"Does it make sense to buy a $3,500 27" iMac for someone whose development effort generates $35,000 a month in value?" "Uh, duh".

Before revenue everyone jerks off about being founders. After revenue, everyone focus on building more income. When you have investors, you have to worry about the optics of how it'll look to your investors, instead of just doing whatever's going to make more money. When you're profitable it's hard to focus on the wrong things.

It's scary how often the decision making process is more expensive than making the wrong decision.

Really appreciated this one. We've been guilty of spending too much time on stupid things, mostly business related to date. Time spent building features, building tools to measure user engagement, revenue, and ways to optimize conversions, all good uses of time. Talking to a potential synergistic partner about a cross promotion and significantly disrupting workflow for a day or two? Not worth it. Actually, I would add to this and say that if you are just starting out, avoid partnering if you can, especially with bigger companies. It takes forever, and what you really need to answer isn't something they can offer up front and that is: will the partnership make us money soon? At this point we still get partnership offers from folks but instead of having big discussions about it anymore, we tend to just shoot back and say "That sounds cool, why don't we try something out next week and do X, measure results and see from there." It weeds out people who want to discuss their six sigma with you and selects for people who want to make money and get stuff done.

Boy, we wasted a lot time. Thanks for sharing the Snaptalent lessons.

Either that, or just have one person who is the leader and who has override authority on everything. Team consensus is not really a way to build a company - in the end there will have to be one overriding vision.