7 Key Lessons From My Startup: Dabble

Here are 7 key lessons I learned from working on my startup, Dabble, from 2005-2008:

1. Take breaks -- weekly, monthly, yearly -- you need to do this to give yourself spaces for rest, be able to come up with solutions when you aren't faced with immediate pressure, etc.

I didn't do this, instead working often 18 hour days, 6.5 days a week. After four years, I was really burnt out. And it took me a year to feel rested again. Not good. For me or the company.

2. Take enough funding that you aren't stressed every minute and constantly looking for money.

3. Do your startup with a partner, a co-founder -- hopefully someone who meets you half way in terms of experience, depth in their field, and knows they want their job and not yours, and vice versa.

You really need someone who's all in.. who shares what you know that other's may not be privy to, shares the vision, and worries about the same things as you, and that forces each of you to pull your assumptions out of your head, articulate them, and justify them. You need someone to hold the fort while you take a break. And hopefully give you perspective, and for which you can give perspective, or the space to take a break themselves. It's just a lot better to have a co-founder. And funders like it better too.

4. Hire people that already know their jobs because you can't afford to train them, and you are already doing something that is hard enough, ie the business is new.. make that the new piece.. not the job.. and take time hiring to find the best people, not just the people who come to you first. Hire slowly, and hire the best you can get.

I made these mistakes, once or twice each. And paid for them. But I learned and I'm more cautious now.

5. Iterate on the business model from day 1 just as you iterate on the product from day 1. Make the business model your product as much as the product is your product. Revenue, revenue, revenue.

I took the advice of several well known, prominent VCs who in 2005 and 2006 said: don't worry about revenue.. get to scale. We did, and it would have helped so much more if we'd iterated and had some revenue.

6. Focus on one thing, do it really well.. and keep going on that without getting distracted by all the possibilities you can think of but that will add to or deviate from the plan.

We mostly did this, although at one point, we took a detour and tried to add one major feature group. Not a good idea. Focus focus focus. Get your one thing really right, really used, really solving people's problems.

7. Don't let big sexy outside entities (like a large well-known company that would make a great press release if you partnered) distract you from the vision because you feel flattered by their attention and the validation of your idea but they need "new features" or changes. Make sure the requested plan works toward your focus, and iterating on your product/business model first.

We didn't do any development for partners (we had a ton of requests), but we spent time with partners and got distracted and it didn't help.

Mobile Engineering: Why Coders with Old World Discipline Have the Advantage

A month or so ago, someone (I can't remember who) said to me that mobile engineering was hard for web engineers to do because it was so different. I've worked over the nine months on product development for several mobile applications at Apisphere, and more specifically the last couple of months seen coding for handsets up close. I can see why those who are great at coding the front end of websites that will go out to people with beefy computers might have trouble coding for tiny devices with limited memory, harddrives and processors. Even smart phones are no competition for the latest desk or laptop.

Working with engineers on Android, iPhone and Blackberry apps, where GPS data is involved, and each of these phones' quirks are being exposed, I've come to realize there is much more to this than just the difference between webcoding and mobile engineering. I started in tech in the 90's working on boxed software. Huge projects with 60 engineers making things for big machines of the time. Those kinds of projects required enormous specs, Market Research Docs (MRDs) and Product Research Docs (PRDs), etc. When I later switched and started writing algorithms for web apps, building little classification systems, and working closely with engineers on web apps creating the information architectures and meaning on sites, through interfaces and algorithms, I didn't think all that much about the differences between installed boxed software and web development, other than the specs I was writing were far smaller and we iterated a whole lot more on the web development in tighter cycles, and often the usability was built in a bit more from the beginning instead of bolted on at the end.

But now seeing development for mobile and creating mobile apps, I realize engineers who learned to code way back when have a huge advantage over web and large app engineers who've never been forced to economize. Those early coders know what it means to optimize for tiny amounts of ram and hard drive space, to create truly elegant code that is compact, efficient, and doesn't take over a device or machine.

In contrast, I find my Firefox usage often pushes my laptop out of control as javascripts go crazy on tabs in the background. Those pages were written by programmers unschooled in the art of system management, who may believe the system resources are unlimited or worse, dedicated *only* to the running of the browser+their webapp. They don't even seem to know they ought to be considering users and their resources based upon the pinwheel of death I regularly experience. I'm often climbing through FF tabs on pages open for work and play as I go through my day, trying desperately to locate that one tab that's going crazy, pushing FF to 125% according to Top. When I get it shut down, after massive frustration and system hangs, waiting to see if the next tab is it, I realize another tab is out of control. And so on until I get my machine back.

Building mobile apps, there is no way we can put that sort of strain on a smart phone, much less a little tiny phone. At this point after watching 9 months of mobile development, I'm realizing the preferred mobile developer is someone who has hardcore coding experience with languages like Java and C++/C#, who had to optimize for old computers with minimalist ram, hardrives and CPUs. People who code as if their program will be the only one open or up in a browser need not apply.

In fact, I would say that older coders with this sort of discipline will often have a distinct advantage over the young new web-only coders, and will be the ones who help us move mobile forward as a viable industry. Of course, those who embody all of these skills for all environments will have the best chances to work in mobile going forward, as I see mobile delivery of webpages as also key to this industry.