Startup Lessons

We've "been there and done that."

It's not much consolation, really, to have had the "experience" of a failed start-up venture, and in its aftermath, stuck with debt and burnt savings and time forever lost, we grasped at whatever therapies we could. Moving back home to friends and family. Taking time away from the industry. Lots of beer.

A part of us seemed to insist upon deriving some benefit from the experience. Making a list of "lessons learned" started out perhaps as a way of venting ... but after some back-and-forth refinement, a simple Google Doc has turned into a sober manual of things we'd do differently if we could turn back the clock.

Perhaps it's a mission statement for the next time we throw our hat into the ring. Hopefully it's not evidence to support the adage that "they who cannot do, teach."

In any event, we bequeath this manual on what not to do to the folks out there thinking of starting their own business. We can't claim to have all the answers, but hopefully we can help others not to repeat our mistakes.

1. Build correctly.

Build your product for a specific group of people.

Be able to name names of users or potential users. They need to have a specific problem or pain point. Master that before moving on to bigger or better things, even if those bigger and better things are really tempting. If your product can serve multiple purposes, make sure it serves one of them completely before moving on to the others.

Have a clear and consistent vision, but refine it as often as needed.

Ensure that all employees and team members share and understand the vision. Target specific strategies and milestones to that vision. Have a plan for the next six months.

Design is important.

Recognizing that design is important is also important. The final product should look and feel the way it was designed to look and feel, and should be built the same way the code should be written: robust, modular, and with each piece informed by the design goal.

Build your product well.

Don't take too many shortcuts. Brute-force algorithms should be used judiciously. Encourage modularity when possible. Remember that ultimately components of your product might be worth money independently of the whole.

Iterate often.

Not once a year. Probably once a week, or once every two or three weeks. Whatever product or service you are offering: build it in such a way that incremental changes can be made quickly, tested against the market, and either rejected or accepted into the next version of the product. Quantitative metrics for user feedback should be built in from the start, and all user feedback should be tracked in a central place.

Do your homework.

No matter what product or service you're building, it's likely that someone else somewhere has done something similar. Do your research, see what others have done. Take the good ideas, improve the bad ones. If you're working in software, the computer science literature should be your friend. Doing your homework also ensures that you check that your idea is not a rehash of an old idea that others have proven will fail.

2. Have the right working conditions.

Work (mostly) normal hours.

Work late when you need to, but don't burn yourself out. When your team is sick or tired, they do poor quality work. If there isn't a consistent schedule, it's easy to think you've worked a full day when in fact you've only worked five or six hours. You want all of your foundational work to be top-notch, too. 24 hours of tired work won't be as good as 8 hours of concentrated work backed by a healthy amount of rest.

Have an office.

This should not be someone's apartment. It should not be a bunch of couches, though a couch for naps is good. It can be a coffee shop, though that's far from ideal. It should have tables and good wifi -- and some whiteboards if possible.

Have a budget.

Track your finances closely. Review the numbers with all key team members regularly. Everything should be written down and company expenses should be approved by all key members. Members who overspend should be taken to task, and the practice should be nipped in the bud. Nobody and no transaction is "above scrutiny." This game is, in the end, a lot about money.

Be direct when dealing with personal differences.

If there is tension between employees, handle it early, and handle it completely. "Diplomacy" is not good enough. Issues should be exposed and solutions reached. Leadership especially should enforce this concept.

Hold one another accountable.

Have set schedules for work to be done, including deadlines. If deadlines are not met, discuss soberly why they were not met, and fix the issues so they are next time. When dealing with public releases, always overestimate time tables; and if you still miss your deadlines, adjust further. By the third or fourth iteration release prediction dates should almost always be met.

3. Your company is only as good as its leadership.

Leaders need to execute decisions responsibly.

This goes far beyond presenting a strong face. Leaders have to be able to collect and synthesize the intelligence of the entire group. Your CEO needs to understand the product, but doesn't need to be the lead engineer. Similarly, your CEO needs to be able to draw on other team leaders' strengths and respect their judgments on things they know deeply. He should assimilate more than create. In business decisions, your CEO should be decisive, but never a loose cannon. The endorsement of the team is not a prerequisite for the CEO to make decisions -- but making decisions the rest of the team can get behind is the essence of his responsibility. Ultimately, the real strength of a good CEO is derived from the transparency and informed nature of his actions, and not from his charisma or his gut.

Leaders need to handle company resources impeccably.

The CFO of your company and his team should have enough time set aside to handle all financial transactions thoroughly and without obscurity. The company's fiscal status does not have to be Fortune-500 worthy, but its credit and cash flows should be crystal-clear and its contracts ironclad. Good employees especially deserve to be backed by a company that handles its finances professionally. While the company is fledgling especially, your CFO and his officers need to ensure that the rest of your team is aware of the company's financial status through periodic updates, best if in written, standardized form. Beyond that, paperwork and contracts need to be clean, complete and on file at all times so that employees have access to them when necessary. Nobody's status at the company should ever be unclear for a lack of appropriate paperwork. Do not cut corners in this regard.

Provide communication channels.

Everyone on the team who should have a voice needs to have a voice in company decisions. Structure meetings such that each team member has an opportunity to speak and to be heard on important decisions. Foster critique and dialog. Leaders should be accessible to all team members and aware of each person's views and concerns.

Use your human resources wisely.

Have people do what they're good at. Furthermore, don't have everyone waste time with administrative work. For example: when seeking funding and pitching to investors, don't use all your company resources; have one or two people take the initiative, and don't distract the whole team with it.

4. A successful product is synonymous with good marketing.

Be conscious of the brand and user experience from ground zero.

As best as you can, take a fine-toothed comb through every bit of the user experience, from the first point of contact, to purchasing/downloading/signing up, through every error message the user could potentially see. Are there points of confusion? Does the language match the company's image? Does the implementation of your product or service match the brand? This can easily constitute a team member's entire job description.

Poke your users often.

Remind them you exist. Remind them how great your product or service is. Remind them how wonderful they are, and how much your company appreciates their attention. The world is a noisy place, and you will have to shout to be heard. Don't count on your product speaking for itself.

Build a solid and regular communication network.

Don't try to start a regular blog, newsletter, or communications network and then let it peter out. Building a user community is a vast undertaking, so measured small steps are important; and people need to be assigned and then dedicated to maintaining communications. Having a social network that grows for a month and then stops suddenly can be worse than never having had one in the first place. Be responsible in your communications to the public.

Co-author any outgoing messages.

Never release information, blog posts, or company commentary publicly that you've done entirely by yourself, with minimal exceptions. If you write a post for the company blog, have another team member review it. Maybe assign a good writer on the team the duty of copy-checking all such materials before they go public. Team leaders should be able to personally speak for the company, but their commentary should be based in common vision shared by the team, and not used as a means to venture into new ground singlehandedly.

Use language your users (and potential users) can understand.

Don't use impossible-to-pronounce-or-read words in your company or product names. Branding should accomplish two basic things: First, to be memorable in some way, and second, to elicit the right sensation when heard the first time, e.g. "professional," "state-of-the-art," "artistic."

changed December 2, 2009