by Kevin Schroeder | 11:18 am

As much as I dislike country music Kenny Rogers sure got it right there.  I left Zend around May of last year, continuing work through June and did some sporadic work on ZendCon 2012 until it came and went.  I had left with the purpose of trying to get in on a bit of the mobile action with some simple, but good ideas.  To help shore up finances I have also been doing some work for Magento as a trainer and helping with their training curriculum as well as providing some guidance on consulting.

However, the time has come for me to admit defeat.  My desire to build a company has been superseded by reality.  Some of that reality has been imposed on me, some of it self-imposed, some of it just dumb bad luck.

But admitting defeat is not the same as admitting failure.  There is a great deal that I have done over the past 6 months and a great deal that I have learned.  Some of that is software related, though a lot is not.

One of the reasons that I started this blog is because I intend to dispense useful information to people that pertains to software.  With that in mind I would like to dispense some useful lessons of the past 6 months.

Don’t do it alone

This is probably my biggest mistake.  I did everything myself.  I could do everything myself.  I’m either that good or that arrogant (more likely a combination of both).  But I shouldn’t have done it all myself.  I really needed to have a partner.  You need someone who can be excited about your project when the other is down, someone to fill in your deficiencies and someone keep you on track.  You are not competent enough in all areas to do everything yourself.  My biggest failure was that I did everything myself.  Most of it I did relatively well but since you can’t be highly skilled in all areas it really shows when you are doing something outside of your skill-set.

What I should have done is go to the local PHP user group (headed by Chris Cornutt) and told them what I was doing and see if someone else who was not employed (intentionally or unintentionally) would want a part in it.  The entrepreneurial books would say that you need others to validate your ideas.  I would say support is more important.  You also need someone to be accountable to, to make sure that you stay focused.  Doing it alone is VERY difficult to do.

Don’t work from home

if you can.  Especially if you have kids.  But even if you don’t.  If you have kids you need to be incommunicado when you are working.  Same thing if you have a wife.  It is good to have a wife and children, but if you are working at home they will make demands of you.  They’re not evil, they’re just human.  Trust me.  When your 17-mo. little girl comes into your office and wants to dance on your knee to Pendulum you will not say “Sorry dear, but Daddy is coding.”  If you think you’re depressed because nobody is buying your software you will be more depressed by the sadness on her face when you say no.  Thankfully, this is something that I did right.  Only on a few ocassions did I ask my children to leave me alone.

Be aware of who you are impacting

This one is important.  One of the big reasons why our society is so messed up is because we are so %&@#$ self-centered.  “My wife and I aren’t getting along, so I’ll just divorce her and find someone new.”  Or “my boss is mean and rude so I won’t do a good job or I’ll just up and leave.”  Or “I don’t like what this person stands for so I’ll destroy their character instead of work with them”.  Lest you think that I’m point a finger at you, in a general sense I’m pointing a finger at myself as well.  I know that I am selfish at heart and so I intentionally have taken steps to make sure that my family comes before me.  As a husband and father it is my duty to lead my family.  The worst thing a leader can do is take the people they are responsible for and lead them over a cliff for the sake of satisfying pride, arrogance, greed or the desire to change the world for the better.  If you  make the world a better place but destroy your family and those who depend on you, you have failed.  Miserably.

Be mindful of those who depend on you.

Your biggest mistakes will be market-based mistakes

As a software developer we have a tendency to worry about things like “OMG, what happens if we’re successful?  Will our system scale?  Will it crash?”  These are important problems to address, but they are not the most important ones.  If you are visible, successful and have some means of generating revenue  someone will be willing to finance you.  Chances are that you could walk into an investment office somewhere with a chart showing exponential growth, talk to the secretary and say “I have a problem” and someone would be willing to talk with you.  Now don’t go into an office for green investment funds if you’re trying to build a bigger drilling platform, but if you’re having scalability issues that can be solved with money and engineering someone should be interested in you.  But don’t quote me on that.  I never got that far.  Plus, I am really good at building high-performance, moderately scalable software so that wasn’t a concern for me :-).  (Moderate means < Facebook, Google, Bing, etc.)

No, your bigger problem is going to be market based.  And the problem isn’t that you won’t solve a problem, it’s that people won’t know what kind of problem you’re trying to solve.  I’ve read a number of startup books and they all seem to say the same thing.  “Talk to your potential customers.”  Except one book.  IIRC, that book was “Blue Ocean Strategy” (I think that was it, but I might be wrong).  What this book (whichever it was) said was that what customers really want is what they already have but they want it faster and cheaper.  You don’t want your customer’s opinions.  What you want is to understand their pain.  Someone is much more willing to hand over money to you if you are making their pain go away.  Just ask me.  I’ve had some pretty severe lower back pain for about two years and I have spent GOBS of money trying to get it solved (it’s still there).

The pain does not need to be physical in order for it to be worth alleviating.  Remember the movie “Up In The Air” with George Clooney?  What did he do?  He was hired to fire people nicely.  Frankly, the managers should have the balls to do it themselves.  But they didn’t want to handle it and so Clooney’s character was paid to “ease the pain” for them.  Look around you?  What is painful for you?  Does someone solve your pain?  No?  Can you?  Yes?  You have just found a potential market.

Don’t build something cool

Yeah, you can point to Twitter and Facebook all you want but the fact of the matter is that neither of those could support themselves for years and it was only that their platforms were preferable to others that they were successful.  And, quite honestly, I don’t think they are.  Twitter changed their usage rules because they couldn’t sustain themselves on the path they had taken.  The value Facebook has for me is about the same as if I buy my lunch at McDonald’s once or twice a year.  I will grant that they have scale on their side which helps them with their low margins.  I guess that makes Facebook the WalMart of social media.  🙂

Instead of building something cool, try to explicitly solve a problem or alleviate pain.  Who knows how much VC money has been wasted on things that were cool.  Know what it is you are selling.  Hint; it is not your product.  If you are selling software that allows you to have a completely spam-free mailbox you are not selling software that allows you to have a completely spam-free mailbox.  You are selling reduced frustration and annoyance.

What you’re building should not be what you’re selling.  Sell what people get from buying what you’re building.  If you can’t identify that then you don’t have something worth building.

Communicate clearly

This goes hand-in-hand with the previous point.  I was looking at my network traffic one day and I saw a lot of traffic coming from one IP address.  It turns out that my server was inadvertently taking part in a Smurf attack (which I quickly fixed) but I checked the website on the IP address and it didn’t tell me at all what they did.  Turns out that they were a CDN, but it took me a very long time to see what it was that they did.  If it were not for the fact that my local gateway wasn’t getting pounded from the attack I wouldn’t have given them a second thought.  Now I use them (they have a free CDN account package which is what you are actually reading this blog via), but it took forever to figure out what they did.

The first thing that your customer sees is a precise, short and accurate description of what you do.  Notiffi is one of the things I was working on and I worked quite a while on finding the right wording.  In the end I chose “Send notifications from blogs, websites and private or public applications to anyone“.  Personally, I think that is great because it tells you what it does in a sentence.  It tells you exactly what the service does.  As developers we try to be as accurate as possible, but we often do that in lieu of brevity. Just take a look at the length of this blog post!  If you want to hook someone (and you do) make sure that you have communicated clearly what you are doing.  Accuracy can often get in the way of communication.

And if you don’t think it’s possible consider the  Twitter feed called leeclowsbeard.  Lee Clow is the guy who did Apple’s 1984 and I’m a Mac ads.  The man is a freaking ad genius.  A friend of mine decided to pretend to be Lee Clow’s beard spouted one piece of advertising wisdom per day on Twitter.  He also published a book of the tweets.  I bought the book not just because it was for a friend, but because it was damn good.  And not only is Lee Clow (the real guy) a fan, but Seth Godin publicly smacked down a bad reviewer on Amazon.

Think your idea can’t be communicated clearly in a single sentence?  Wrong.  It just means you need to work harder at doing it.  My friend proved that.

Or add a few more commas.  🙂

Know when to quit

This is the hard one.  History is full of examples of people who went down to the wire to become hugely successful.  You are probably not going to be one of them.  For every person who achieved this there are about 50 thousand who died destitute because they didn’t know when to quit.

I made a couple of miscalculations.  I had a Twitter-based application that I had started originally.  I had heard some grumblings about how Twitter was acting.  I knew some changes were coming but I never expected them to be so comprehensive.  I looked at what I had spent almost two months on building and decided that I had to gut about 80% of what I do to ensure compliance with Twitter’s new terms of service.

My second mistake that I made was stopping work on the Twitter app in lieu of a different idea I had that was simpler to build.  What I should have done was finished up the app, release it and then start working on the next one.  I had not taken into consideration some of the problems I would run into when integrating with some of the technology and some of the approval problems I had.  It was a simple app and API and so it should be simple to get it up and running.  Right?

When I had started I was saying that if I didn’t have a good idea of where I was going in 6 months then I would need to re-evaluate where I was.   Well, it’s six months later and I’m doing some re-evaluating.  I’m looking at the dependencies I had on third parties and the amount of work I needed to get done to launch a product and then market it.  While the ideas are good and mostly complete I am now at 6 months and a trajectory has not been established.  I could go for a few more months and get it launched but there was a point that I was willing to go to and I have now passed it.  I could, in my pride, push forward against all odds and make it work.  But the strategies I have are for my life, not my business.  If my business was my life it would be indicative that my priorities were wrong.

As such, quitting is not so much failure as it is a scouting party returning and finding that such and such a path is blocked.  I risked a little to find a good path and found that this path was not suitable.  Lesson learned.

Where now?

As disappointing as this is it is not the end.  I wrote this blog post in the hopes that you will benefit from my experience of the past several months.

And while there are plenty of things I learned I also did get to build a lot of cool software.  I built

  1. A worker queuing system that uses JMS and Apache ActiveMQ as the router, connecting to PHP using FastCGI.  In other words I could define queues that PHP would listen on for job processing requests and then provide an asynchronous response.  I did this because ActiveMQ supports stomp, but also web sockets.  By doing this I could use a system that handled persistent ws:// connections directly to a scalable backend processing system that did bi-directional communication.
  2. A Java-based persistent connection from PHP to the Apple APNS system.  The APNS system is like Homer Simpson praying to God. “If you want me to do this, give me no sign.”  This system maintained the persistent connection, thereby alleviating Apple’s potential dislike of multiple simultaneous new connections to the APNS system while facilitating multiple push notification origins and managing the notification queue.
  3. As cool as #1 was it was not really what I needed in the end.  I really like the concept behind the Zend Server Job Queue in that it uses HTTP to do process jobs.  I like this because it allows me to scale my worker queue by adding machines behind a load balancer without the need to modify the application’s configuration.  Scalability should be an infrastructure concern and not an application concern.  The system I built allowed for that.
  4. I got to build a few mobile apps.  Enough to get to know JavaScript a lot better than I used to.  But it also taught me that as cool as it is to build front-end stuff I LOVE the backend and I love working with PHP.  I would spend weeks building UI components only to spend days on the backend.  But the biggest difference was that I was smiling while building the backend instead of cursing the day I was born.
  5. Notiffi took about 8 weeks to build and had around 8000 lines of code split between PHP, JavaScript and some Java.  During the same time I was working through a business strategy, doing design (which I eventually contracted out for the website), recording videos, writing documentation and setting up a (mostly) self-managing production environment while also going through the final period of adoption for my three children.  As much as it pains be to have to withdraw from this endeavor I am horribly proud of what I did accomplish in such a short period of time.
    1. I actually did an intro video that I’m pretty proud of.  My wife had a cold at the time of recording.  But it was pretty decent for my first time as a video editor and director.  🙂
  6. I have also identified several weak points or process inefficiencies in development environments that could really use some work and creative thinking.  I started doing some work on some tooling to alleviate this problems but never got to finish them simply due to lack of time.  I think that the market is ready for some of these changes but if I went forward on this I would not have learned my lesson.
  7. Finally, once I had decided that it was time for me to stop work I decided to do some coding for fun.  There were two things that I worked on.
    1. A tool to use your phone as a stop-motion camera coupled with another tool that would help capture and properly sequence an animation.  Almost done with it.
    2. An infrastructure that would do what Twitter should have done, IMHO.  Twitter is basically an advertising platform, both for Twitter, Inc. and for its users.   I really think they could have been so much more.  App.net is a good option, but I don’t think that their business model will ultimately be sustainable, or interesting.  So I built a streamable web server using Netty, reused some of the Java FastCGI to allow PHP to handle data processing and communication.  Abraham Lincoln used to write letters to his detractors, defending himself, and then throw them away.  This is kind of the same thing.  I needed to do it to do it.

I’m excited to say that I have an interview with a well-respected company come this Thursday.  Having some time away from the corporate world seems to have been helpful for my disposition and it allowed me to explore a number of things that were not in line with my previous job description.  In hind sight, it was the right time to leave Zend and try some things on my own.  Similarly, it is now the right time to stop what I’ve been doing and change direction.

… unless, of course, you have or know of VC or angel money that would be interested in 6 or 7.2 🙂

Comments

SamHennessy

Great post, I hope when the time is right you’ll try again.

Jan 08.2013 | 05:08 pm

shaded2

Thanks for the informative post Kevin. It sounds like you’ve built and learnt some awesome stuff in a very short time. I’m also torn between working in the corporate world and doing my own thing. The good think about our industry is that as long as we are willing to keep learning there will always be new and exciting options open to us.
Not that you need it, but good luck with your interview.

Jan 08.2013 | 08:33 pm

dstockto

How did your interview go?

Jan 14.2013 | 10:26 am

    kschroeder

    It went pretty well. I have a second one coming up as soon as I can get it scheduled. We’ll see how the next one goes.

    Jan 14.2013 | 11:22 am

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.