Wednesday, September 26, 2007

The Problems With My Startup

Preface
I'm typing this up in order to collect my thoughts, in hopes of eventually showing them to my coworkers. It's here because I'm interested in the commentary of passers-by and because I figure people might find it interesting. I'm initially going to type this in a single sitting, so if I have further thoughts later I'll probably make an addendum section for them.

If you are one of my coworkers and you've stumbled across this prior to my relating these ideas to you, congratulations—you've found my secret blog. Knock yourself out.

A Bit of Background
The startup (I use the term loosely) I work for is composed of four guys—myself (programmer/sysadmin/general technical hotline), two designers (one of whom designed most of our site and one of whom also does Flash programming and did a couple applets on our site), and an people/phone calls/ideas guy. We've been working on our project for over a year, and we provide free basic services and a number of premium, for-pay services. It's largely Web-based, and is not a social network, though it integrates with the big social networking sites, excluding Facebook.

1. Focus and Direction (and Hiring)
When we started our project, we had a single goal. We figured no one was doing our idea, exactly, so why not give it a shot. So we did. And soon we came up with a twist or two to throw in to make the project even more original, namely a client-side application that syncs with our site. But, in my estimation, here we committed two mistakes. First, although we had not yet finished working on our original feature set, we embarked on developing this application simply because it seemed like a great idea. I'll explain the significance of this in a bit. Driven largely (and unconsciously) by desperation to churn this great idea out, we committed our second mistake, which was to enlist a friend of ours, an individual who was intelligent, busy, long-distance, and marginally qualified to develop our application (in particular, as regards Java experience, which he had little of and we needed). This was great for a while; it freed me up to work on core site features. We soon found, however, that communication with our coder was difficult, as we couldn't count on him to meet deadlines even when he set them, and that his idea of quality control didn't match ours. So we said, "Enough is enough," and told him so. At that point the software he had developed was mediocre at best.

So, what to do when the dream isn't panning out? Ask yourself, "What is everyone else doing?" So we did. (Technically, this was sometime during Java application coder's time with us, not after.) And it turned out that Bigger Fish X (code name, of course) was involved in the same sector of business as we were and was providing a service we didn't have to thousands of users of the same ilk as ours. So, why not clone their feature and offer it in addition to our core service? So we did. Another coder (another friend, this time local, thankfully) was drummed up and he began work on the feature. A few months later, we had something that mimicked some of what Bigger Fish X's site did, although many features were missing. And we made a few sales with this feature (to be exact, 10 to date).

Sometime after our web coder finished the Bigger Fish X feature mimick, and I say "finished" in the sense that the barebones functionality was present, he began to drop off the radar. It became apparent that he didn't want to work with/for us—some form of compensation would be required, preferably in the form of pay, and failing that, equity and share in future profits. The latter was not an option amongst the more opinionated among us, who believed that he should prove himself (e.g. dedication, ability to meet schedules, communication, etc.) before being given part ownership of the project/company.

At some point (I'm thinking it was around our startup's half-year anniversary, though it may have been slightly later) we "partnered" with an up-and-coming social networking site catering to a particular niche. The end result was that our services would be advertised to all signups to the social networking site who had an interest in the services we provided (such interest could be determined based upon the type of account they signed up for on the social networking site), and in return our media company would do some audio/visual production work for the site. Our signups increased immensely. I estimate that to date 75% of our signups have been referred by this site. One problem, however, was that these users largely did not have the money to afford our premium services, and thus the "partnership" has not delivered what we hoped.

Over the course of what I've described thus far (around eight months) many, many ideas were thrown onto the table, largely by our idea guy, who has an knack for noticing a random Bigger Fish and suggesting we copy something they are doing. Many ideas were shot down. Some were not, and went onto the drawing board. We gained, notably, a hackish SMS interface (because we couldn't afford an SMS short code; more on that later) that we immediately tried to beta test with several of our more loyal and vocal users, with disappointing results.

Because I'm our only coder for all intents and purposes (we did hire a new Java guy, but he teaches college and has a family and thus makes slow progress), my responsibilities include fixing site bugs, whether in code I wrote or code our late coder wrote, sysadmin tasks, and new feature development. Between bug fixes and new features that we "just had to have" I never had the time to test our core functionality and make sure it was really robust. This is coming back to bite us. Just recently we became aware of a huge deficiency that will need some coding attention and will prevent large clients from using our services effectively until we get it fixed. It's something I wanted to look into more at the beginning, but couldn't because other features were going to make us way more money. Or so some said.

Lately, we've actually gotten the attention of a Big Fish that might want to sponsor a group of people to use our site. This is great, except that it means three months, possibly more, of work to implement features they want that we don't have.

To sum up my issue with our focus I'll attempt to write in generalities. I could go on and on about how our focus has gone wrong. Our "people person" guy preoccupies himself constantly with our startup, although he is a full-time schoolteacher. I would estimate that 50%, possibly more, of my conversation with him involves him telling me about a new feature he's been thinking about lately. Now, mind you, he's probably told me about it before but he's telling me about it again because he's given it further thought and is just this much more convinced that it's largely the key to amazing profits and I know he can't wait until it's implemented. Problem is, I'm our lone coder. I'm working on fixing our current features or fixing a bug discovered by a client or a new feature that's actually work-in-progress, not a few-months-in-the-future maybe. Sometimes I just want to scream, "SHUT UP!"

I see this as probably our biggest problem, and I could go on and on with examples of us allowing ourselves to get tied up doing things that could conceivably be complimentary to our core services, and hopefully will make us money, but at the moment at which they are commissioned are little more than wishful thinking.

2. Innovation
Put briefly, there's little room for it. Sure, I've gotten to write some nifty code, and I was able to put some time into rewriting a particularly key component in our system and tailoring it specifically to our needs, replacing what our Web framework provided. But innovation that will make us money? Innovation that will make our users say, "Wow, that was easy. I love this site!" Nope, we're moving too fast for that. If it works, let's test it for a few days and put it live and cross our fingers. Somehow, we forgot that you can't just copy Random Bigger Fish—you have to be better, and in a way that users notice.

3. Funding/Pay
We knew close to nothing about seeking funding for our startup when we started. We hardly know any more now. The one person who probably knew something about it, because he took the time to research it, was our Web coder friend who declined to work anymore for free. The rest of us wouldn't have known what angel investors or funding rounds were if they smacked us upside the head. One member of our team likes to consider himself business-minded; he once told me that he's a "business geek." Well, you could have fooled me. We never sought any funding, and have never taken any.

Because we were friends when we started, we all worked for free, hoping to share in the rewards of success. Such does not work so well when you're trying to get someone who doesn't see the project's "obvious" merits and potential for success.

If we'd had venture capital, even a little, we could have employed more coders, and they would have wanted to work for us, because money generally has that effect. And who knows, three coders working full time (instead of myself, largely, working when I could) might well have gotten us to where we are now in...dare I say four months?

And then there are growing expenses, like an SMS vanity short code. If we had one, and a bit of money to subsidize messaging costs until the feature began to pay for itself, our SMS feature would not be dead in the water. And it's not like the people who've beta'ed our SMS feature can't tell that something's not right about it. For starters, we're asking people to text to an email address.

If we'd had the money to do so, we could have done press releases as we rolled out our half-baked features, thus at least exposing ourselves to potential users and hopefully, Big Fishes who might possibly sponsor numerous users. Furthermore, in our sector, a press release is a near necessity. Incidentally, press releases are still on the perpetual drawing board, for a later date when we've more money to throw around.

4. Public Relations
As I've mentioned before, our PR guy is a full-time schoolteacher. This means that he doesn't have enough time to call users, to do tech support for users, to answer feedback, to call potential Big Fishes, as is necessary for us to even maintain any momentum we had at the end of the summer.

5. Information Presentation
I believe that when people hit our front page, it's not immediately obvious to them why they need our service. Sure, perhaps they'll come back and check it out on the weekend when they have time to poke around, but our front page does not outline what we do and why people should at least try out our services in a succinct and simple manner. Instead, it's wordy and cluttered and we over-explain (or is that over sell) everything we offer. But we've gotten feedback asking, "Uh, so, what is it you guys actually do?"

This is by no means a jab at our designer. First off, I don't think it's his fault, and second he's been working on a simplistic redesign that gets down to the essentials, but he's being pulled off that by tangential projects that are pulling in some money but are not letting him focus on our core service.

Conclusion
In summary, we suck at staying focused on one idea. If you don't see the merit in that, look no further Flickr.

We suck at hiring (or enlisting) help on our project, and we've blown off a few feet in our desperation.

We suck at allowing ourselves to make something that's actually good and that people will want to use on its own merits. That might be a bit strong, but I'm referencing the innovation thing.

We suck at even understanding how Web business works today, but we don't have enough time to educate ourselves.

We suck at having enough time to respond to the questions, comments, and concerns our current clients, and time to pursue new clients and new venues of acquiring clients.

We suck at explaining to potential users exactly what we provide and why they should use our service.

This is stuff I've been batting around in my own mind for quite a while. Some of it has slipped out in conversation at the office, some has not. I have really enjoyed working on this project, I love the guys I work with, and I think our idea has potential, but I am becoming increasingly disillusioned with where we think we're going, how we plan on getting there, the process through which we decide either of the two previous items, and the manner in which my concerns are often dealt with. Sometimes when I hesitate about something at the office, some part of what I've mentioned runs through my head. I've put it all down here so that I can present it in a comprehensive manner soon.

8 comments:

Anonymous said...

Joseph,

Fascinating rant, thanks for publishing it. I commend your willingness to go public so that other folks can learn from your experiences.

My startups - SmartFlix and HeavyInk (launching in October) - haven't made anyone billions yet, but they do consistently make the payroll for almost a dozen people...all without angel or venture capital.

If I can offer a few bits of analysis to complement your own:

* Committees suck. You've got four peers, and no crisp division of labor. Thus, your marketing guy is designing features, your business guy is doing who knows what, etc. A ship needs one captain (yes, Google is an exception to this rule. That's because Google is an exception to every rule.) For your next startup, you'd be better off flipping a coin to figure out who gets 51% of the stock, and letting everyone else split the other 49%. Yes, I'm exaggerating, to make a point, but the point needs to be made: someone has to own the overall direction of the company.

* Software companies need software people. One engineers out of four founders is too few engineers. A software startup should be from 66% to 100% engineers, for the first three or four people. Two designers? Pardon my bluntness, but that's insane. One full time designer is more than you need.

* You don't need more capital, you just think you do. Every company that runs into problems runs into the "too little capital" problem. But most of the problems that take place in a hospital end up with a "dead patient". Your real lesson you need to learn is not "we should have less dead patients" - the real lesson is "when the patient chokes, clear the obstructions; when the patient bleeds, stop the bleeding; etc."

* You have too many immature, incapable people in the boat with you. This is a hard one - you may be young, or you may not yet have the track record that makes rockstars want to get in the boat. I don't have a blanket solution for that. One thing I suggest, though, is that in your next go-around, try to get just ONE superstar in the boat with you. Then you've got a high average skill level, and that makes it easier to hire more excellent people when you have the revenue to hire anyone.

* You have parttimers. Anyone who has a dayjob isn't prioritizing the startup the way they should. Paul Graham has said it, and he's right.
* Lack of focus. I don't know exactly what you're doing, but it sounds like you're heading in lots of directions. Generating cool ideas is easy. Executing one of them to the point of success is hard. Executing two of them to the point of success is impossible. Seth Godin has a great little book called "The Dip" - his thesis is that things ramp up, until they hit a snag, and the snag is hard. You either get past the snag, or you don't. Don't screw around in the "dip" - either bull through it, or back the heck up ASAP. When you pursue multiple goals, you get yourself embedded in multiple dips simultaneously. I can't design a better strategy to kill a small startup.

I can't tell from this distance, but if I had to guess, I'd say that your startup has too many fatal flaws to be saved. If you conclude the same, then the sooner you get out, the better.

Quit, get some contract work, and build up your bank account. Then try again in a year. When you do:

1: Pick 1 rockstar engineer as your cofounder, or 1 rockstar engineer, and one rockstar business guy. Decide how ties are broken.

2: Don't waste your time pursuing capital. Get your first product to market ASAP, and start making revenue. If you can't see yourself making revenue in 3-6 months, then you've picked the wrong business model for a new entrepreneur who's bootstrapping. Pick a new business model.

3: Bull forward. Deliver version 1.0. Then deliver version 2.0. Do not spread your focus, do not get distracted, do not throw darts at a board to pick new features. Be ruthless in analyzing every suggested feature: "This is going to take 20 engineer hours, which cost $50 in virtual money. Will this feature bring us $1,000 of revenue in the next three months? If not, write the idea down in the wiki, forget about it for now, and come up with a new feature idea."

4: see rule 1 again

5: see rule 2 again

6: see rule 3 again

David Q. said...

Interesting comment.
One of my favorite estimates on valuation of startups like ours www.collabomatic.com comes from Guy Kawasaki in the famous art of start.
His formula is pretty straight forward:
Value = 500K*number of full time engineers - 300K*number of MBA's.

Obviously his point is drilling home that you really need doers and implementers ... something else he goes on at length about.

I'd agree about part timers. Starting up is intense. The whole wanting pigs instead of chickens analogy from agile / scum methodologies.

Anonymous said...

Joseph,

I so totally feel your pain. I love the advice that tjic gave, and perhaps I can offer something myself.

Until you are ready to quit, you have to make the best effort to get the house in order. Start with "people guy." I sense he is a large source of stress. Tell him that ideas can't just be stuff he dreams up, but have to be presented to others first. Require him to mock up the UI somehow (even powerpoint pictures, or sketches on a page will do) and get feedback from coworkers, other parents at kids' sporting events, legit focus groups, etc.

Also charge him with getting the word out. There are cheap press releases and other ways of doing it. But everybody in the co has to actually produce something, and his product is "marketing and market research."

Secondly, make your code design process systematic, with the idea that you could create a robust design and outsource the coding. This requires some self-discipline and practice. The idea here is that you will be able to use entry-level coders if you can create a workable design that others can follow. You also may be able to off-load some coding by outsourcing--it's a lot cheaper if somebody else doesn't have to architect it. Maybe a student would do it for a few bucks...

Anonymous said...

It seems to me that your most important problem is the easiest one to fix.

You say, "We suck at explaining to potential users exactly what we provide and why they should use our service."

... obviously you're not gonna go anywhere if you can't explain to your customer what you're doing. So redo your homepage. And you don't need to wait for a new design! Just work on your text copy. Cut it in half, and then in half again. Google for 'copywriting tips' for some inspiration.

Joseph said...

Thanks for your well-thought-out comment, TJIC. When I show this to my team, I'll certainly be showing them your comment as well. I'd heard about "The Dip" before, never got around to checking it out. I will try to do so.

Anonymous said...

I didn't go through a situation kinda like this - I went through a situation so exactly like this that my partners would easily mistake your "secret blog" for mine but with a clever obfuscation that it is happening now instead of six months ago. It wasn't a huge company (we had 2-5 employees) but I'm keeping this post fairly anonymous because the guys and I are still friends.

+1 on everything TJIC said except the bullet point that one partner must be the decision maker. If four people can't agree unanimously on the direction of the company you are screwed. Trust the area expert but otherwise go unanimous or bust.

I was the lone software guy in a company of two designers and one idea guy. All three of the other guys were ex marketing/ad agency. The idea guy was a lifelong best friend.

I can't over emphasize TJIC's bullet that a software product needs software people. It is human nature to use magical thinking about things you don't understand. Here is a real conversation:

MG (Marketing Guy): Hey, I just got off the phone with my friend at agency X and we are a shoo-in for a $1.5 million project if we put in a proposal. Is [project description] possible?
Me: By us? No.
MG: but they need a database backed web application with reporting and we do database backed web application with reporting.
Me: Well, first I would need three months to find three top notch guys. Then we would need a year to make the product. Finally we would need to build a help/call center for the resulting product. Basically you are pitching we start a new company.
MG: So that's a no?
Me: That's a no.

Those were the easy ones. Our biggest problem was that the non-me guys only understood hourly billing. The monthly fees for our application were considered free money so they would solicit customization work from our new customers. Increasingly work on the core product stopped and the core product grew a hodge-podge of half-baked features. The next new clients wanted those features plus a customization, etc.

It was unsustainable. Designers do something and throw it over the wall. It takes a lot of effort to explain that tech is doing something and then carrying around the result forever. I couldn't or didn't explain that adequately.

There was zero chance it would end well so I tried to quit gracefully. We agreed on a six month schedule to finish outstanding client work and then six months for me to do the work I thought was neccessary on the core product and train my replacement.

Of course that didn't work out. Every day someone that was not me promised two days of my future work without asking (and at a bad price). So I hurried up my quit. The money was good but the hassle wasn't worth it. I helped them find a replacement and transition him in but I was off the proj.

Epilogue:

They are doing much better without me; the new guy said all the same things I did but he was a second voice and not a lone vote so everyone else took the ideas more seriously. They cut back to selling just the core product and spent 40k to beef up the servers. Likewise new (and spurious) feature development is on hold.

As for me, things couldn't be going better. Literally the day after I got out I was approached by a publisher to write a computer book. That is over and now I'm starting another startup with the decent sized warchest from my last one (I'm applying to YC not for the funding but for the contacts).

Most importantly to me is that I am still friends with the "idea guy." At the end it really came down to if I wanted to pick a fight and only possibly make a company that would make bullshit money or bow out gracefully and try to make the company I was leaving as healthy as possible.

If I had it to do all over again differently would I? No, unless you mean very entirely differently. One startup vet and software guy plus three marketeers equals grief for everyone. Don't do it.

Anonymous said...

Joseph,

It sounds like you have a problem with setting priorities for the startup.

I believe you need have a discussion about the future direction of the startup. As a team you want to ask yourselves and come to agreement about the following: What are your goals for the startup? You should have three or four at most, and these need to be fairly specific and concrete.

After you have agreed on a set of goals for the startup, you then should compile a list of everything that is going on related to your company. Every project currently underway, stalled, dreamed about, and every pending client request should be included on this list.

Next go over this list, asking yourselves the question "Does this item contribute directly to our startup goals?" If the answer's no, then scratch the item off the list (you may find you have to follow up with a customer to explain why their feature cannot be added at this time).

Finally, after you have narrowed your activity/feature list down, you should then go over it again, this time asking yourselves two questions:

1) How does this item help us in the immediate future (1 - 4 weeks out)? and
2) How does this item contribute to our long term success?

The key here is having a concrete and specific set of goals for your startup. With a clear vision, you will easily cull out unnecessary activities and focus your efforts where it will contribute the most.

Anonymous said...

Kaizyn,

That's an excellent strategy until the point where you need sales. Then, the plan is out the window because you now, you have competing forces.
Marketing Guy knows:
1). It's easier to sell something else to somebody you've already sold to, and
2). It's easier to get a guy on the phone to convert than to get a new guy on the phone.
Thus: their pitch is feature-creep.

On the other hand, you know: feature-creep can bury a new s/w company.

It takes more research than most of us startups can afford to know exactly what will sell before we start trying to sell. Yet we can't sell anything until we have something. That is the startups' dilemma. The only thing I can think of to solve the dilemma is to test the waters before building too much.

But I read these posts not because I think I have the answers, but I'm hoping others do, so if somebody knows a better solution please share!