Archive for 2005

You will go to your technical co-founder with a half-baked idea and thy will implement it how they think it should work.

A valuable lesson for you is that you need to understand how to document and build a feature that leaves no room for interpretation rather than leaving it up to someone else’s interpretation.

If you don’t learn how to do this, as your technical team scales, it will reach a natural upper limit of implementation velocity as people wait around for you to figure out what else needs to be done or fixed.

It will also lead to frustration (mostly yours) as you forget that you asked for that, or didn’t ask for that, or asked for something completely different.

In six months’ time you will be dazzled by someone with an opinion on the best way to implement this and your current technical co-founder will get offended.

Your relationship with your technical co-founder will be tested, and sometimes needs to be tested.

I cannot emphasise enough that it is your perseverance, your doggedness, your tenacity, your refusal to “just quit and get a job” is what will drive you to far greater success in your start-up endeavour than any other skill or character trait you may possess.

Gross margins by product vertical may be boring to talk about, and almost as boring to think about (trust me on that), but they are a strong indicator of whether a start-up can be profitable.

If you have a start-up and the only unique feature, in fact, your unique selling point, is delivering a product or service, that someone else manufactures, with a very minimal gross margin, then you’re in trouble.

You will make a lot of sales, but you won’t make much money.

You will start a discussion about a feature you would like, that you thought of the night before, and your technical co-founder will quite evidently stop listening.

And that’s okay, because you need to learn how to plan by planning.

You will not understand why your technical co-founder is taking so long to implement a simple feature and they won’t be able to articulate that there is still foundational work to undertake.

And that’s okay, because that inarticulation is where the developer’s knowledge of how to communicate the concept simply ends and where your lack of foundational knowledge begins.

Your technical co-founder will present you five ways to solve a seemingly simple problem.

And that’s okay because you have to understand that all technical solutions are really a series of trade-offs; money, time, effort, and so on.

You will ask your technical co-founder “How hard would it be…?” about two hours before you launch your new app.

And your technical co-founder will have a breakdown.

Because you need to learn, not every feature needs to be done right now.

Usefulness is contextual.

A sharp knife in the hands of a meat butcher is useful when cutting up meat.

A sharp knife in a gun fight fought at 100 meters… not so much.

The thing is, if you attempt to design a product that is useful in as many scenarios as possible you end up with weird products sold on late night TV shopping channels.

Invariably your customers would rather have two items that do two distinctly different task and do them exceptionally well, than a single item that does two distinctly different tasks mediocrely.

When you’re planning your SaaS or product offering or consultancy service, don’t just segment your audience, segment your features too.

Some of the rudest actions I have ever been witness to is a non-technical co-founder asking me for a status update on a difficult problem.

Pulling me out of flow.

And within a minute of me starting my explanation the co-founder is staring at their phone; checking their email, checking messages, or whatever.

At that point in the early days of a co-founder relationship the three foundational aspects of a good co-founder relationship (like, respect, trust) become one (trust) and it will take a lot of effort to gain back the missing two.

Employee referral programmes for future hires are known to work.

All too frequently though I run in to an employee referral programme with exclusions built-in that you only find out about after the referral – this has been one of the biggest complaints that I’ve heard repeatedly from people who refer other potential new hires to the company they work for.

“Oh, we don’t pay out referral bonuses if you are a contractor.”

“We don’t pay referral bonuses when we hire a contractor on a temporary basis.”

“We don’t pay referral bonuses if the new hire is related to you.”

“We don’t pay referral bonuses unless the person gets hired in to your department.”

“We’ don’t pay referral bonuses if the person gets hired in to your department.”

“We don’t pay referral bonuses if someone else in the company also knows the person (but didn’t refer them) because it wouldn’t be fair.”

If your referral bonus programme has exclusions, I suggest you get rid of the exclusions immediately, and instruct HR to never, ever prevent an employee (or contractor) from receiving a well-earned referral bonus.

Why?

Because the moment you prevent someone from getting their referral bonus due to an exclusion you have shut down all future referrals from that person and their network.

And do you really want to cut off a a potential source of great new hires just to save a few thousand dollars?

The more you ship, the easier it gets.

Letting go the first few times is hard.

Will the public like what I produce?

Will they find fault?

Have I done enough?

Will it sell?

All those questions and worries hold us back.

But I tell you, ship a dozen different products a dozen times and the next time, the 14th time, the 20th, the 40th time, it just keeps getting easier.

Then you stop caring about whether people will care about your work.

You will start caring about your work instead.

Am I risque enough?

Is this different enough that I will alienate people?

Have I innovated enough that people will hate the new version?

There might not be any visible strings attached to being an EIR (Entrepreneur-in-residence) but there’s an awful lot of pressure.

You are expected to come up with a viable business idea in less than six months, and then need to get buy-in from some exceptionally skeptical parties that get to see you at your best, and at your worst.

If you thought your family and friends poo-pooing your ideas when you were a wet behind the ears entrepreneur was bad for your morale, try having a bunch of VCs be your family.

There is an ever present tension in a start-up between what we are doing and what we could be doing.

Marketers that sit on their hands waiting until the product is ready to ship before they start marketing it are not marketers you need on your team.

Non-technical entrepreneurs that fret about which programming language or development stack to use to launch their product are worrying about which brand of ketchup will be on the table at the steak restaurant they might go to next month.

Picture yourself standing in front of a studio audience on an incredibly popular TV show, and you have to explain to the audience why they should want your product, and you have to get them excited for your product.

They have to truly believe that you product solves all their problems.

Can you picture it?

No?

Then you need to iterate and tweak again.