5 Lessons Learned From A Non-Technical Founder

Here are a few things I’ve learned about web-based businesses and entrepreneurship in this journey over the last two years:

In 2009 I set out to bring the benefits of a big business consulting firm to small businesses at a price point they could afford.  This was on the back-end of five years at a big consulting firm and at the front-end of an MBA.  Consultant and MBA. Some might say I was ripe for real-life business lessons.

Many business owners often hire companies which will help them improve their production process, but they usually have their own set of rules which many owners are ready to accept. Of course, it is always better to have a professional support, but when it doesn’t match your needs, then you are in a problem.

On the other hand, non – technical founders can provide you much useful information which can help you with your company. They have a raw knowledge, and they are always in touch with regular people, which is a great way to find about peoples’ needs. So let’s look at the things I have learned so far.

Don’t try to manage overseas developers on your own. They will do whatever you ask. And that’s nota good thing.

Web Based BusinessBased on my consulting experience, I had done some technology stuff. I wrote requirements docs, design documents, test scripts, blah blah blah. I even did some CSS and HTML, more or less. When it came to web development, I knew just enough to be dangerous.

So, I set out and hired a team in Ukraine through Elance. I gave them a hundred pages of design docs and got a fixed price job for $13,000.

They were off to the races. They took the specs and did exactly what they said. That’s where things went wrong: They did exactly what I told them! Never did they question the specs or make suggestions on how to actually design a system or business that people would use on the web.

I ended up with a platform that technically worked, but missed the mark in terms of being a viable web business. And never did these guys say, “Wait a minute. What are you trying to accomplish here?” or “This functionality doesn’t make sense.”

Oh, and I tried to save a few bucks and do the web design myself by learning Photoshop on the fly. That was hilarious. Here… see for yourself.

Get someone on your team who will give objective feedback. Keep that expert at an arm’s length.

The Ukrainian developers were getting paid to do what I asked them to, not to tell me I was wrong. And my friends and family who were helping me either drank the Kool Aid, incorrectly believed we were doing everything right, or didn’t want to hurt my feelings and tell me when we were headed down the wrong path.  Do yourself a favor and hire someone whose job it is to tell you when you’re wrong, why you’re wrong (so you don’t do it again), and how to fix it.

I found some guys who go by the name “Web Cardinals” who did this in 2010 but they were so brutal that I fired them after 10 hours.

Six months later, after all what they told me would happen happened, I went back to get their help. We’ve been working together successfully for a year now.

Just because you can dream up a feature doesn’t mean you should add it.

One feature I wanted added in Whinot 1.0 would have allowed users to help finance the business in a crowdfunding-type model. I thought it would be cool. Oh, and another one was the ability to share and sell documents.

Well, now I had three business models within my tiny little startup. None of them worked, and together they were really confusing. I was trying to fly a plane with three or four wings.

Designing the concept is work, too. Don’t be too anxious to jump to development. You will save money in the long run with well-thought-out designs.

Fast forward to 2011, after I spent $18,000 on three-wing aircraft that crashed and burned. The whole 1.0 process was not a waste, by any means. I learned a ton about what customers and experts wanted. It was time to start over. Back to the design documents.

In January, I re-hired the guys (the brutes) I fired last year because I knew they were what I needed to succeed.  From January through September this year, we worked on process flows, wireframes and use cases.

In June, I was more than anxious that we were over-designing the site and business. And I was annoyed because all of this work wasn’t real work. It was design! In my mind, the real work was development.

I remember complaining to Michael one day over Skype. He replied: “Design is work, too.”

He was right. We were developing the system; it was just on paper instead of PHP. We had wireframes that I was using to do usability tests and get user feedback on the new system. And when we discovered something wasn’t right or clear and had to be fixed, all it took was a few mouse clicks to fix things. This was in contrast to expensive development time if we hadn’t discovered these things until the system was built.

That may be one big difference between technical and non-technical founders. Technical founders have the liberty to start development sooner. Non-techies have to rely on solid designs before moving to development because it’s harder and more expensive to make changes when someone else is pounding out the code.

No lorem ipsum on wireframes.

Web Design

Speaking of wireframes, I think we had 90 of them or something crazy. When I started wireframing some time around March, I did what I always saw in wireframes: inserted “Lorem Ipsum” wherever there was text that I didn’t know what to write and I didn’t want to think about it just yet.

“I’ll figure out the text later, that’s easy.” HAHAHA

Writing copy is hard too. Copy isn’t copy. It’s your tagline; your unique selling proposition; it’s your 10-second pitch. It’s all that stuff that … wait … makes customers open their wallets!

So why would you put some jibberish latin text in there? Not using lorem ipsum forced me to think about the messaging. And it made me explain how users would/could/should use the platform. You can’t do usability tests on wireframes with lorem ipsum, either.

Bottom line for non-technical founders:

Know your limitations. Find an impartial expert. Think the strategy through carefully. Don’t underestimate the importance of the design process. Write the copy; it’ll force you to think your strategy through again.

Are you a non-technical co-founder? Did you struggle with these things or something else? Be HONEST!