danieltenner.com

Startups, company culture, technology, music, writing and life

Category: Articles (page 1 of 5)

Full-length articles written by me.

What sort of entrepreneur are you anyway?

This article was originally published on swombat.com in May 2011.

From my father’s blog about wisdom:

The trouble with values is that they are all good.

Most people will swiftly agree with most of the high values of humankind: freedom, happiness, truth, respect, justice, equality, prudence, compassion, courage, modesty, patience, moderation, harmony, industry and so on; but ask them which is the most important and prevailing. You will suddenly find in the pattern the striking differences that tell fascists apart from communists and religious fanatics from tolerant free thinkers.

Bad people have no problem with good values. Irreconcilable opposites are made from the same handful of values representing goodness. It is the weight of each that differs.

The same is true for entrepreneurial values. Everyone but the most psychopathic entrepreneur will agree that a business should treat its employees well, shouldn’t waste money, should create value, should generate returns for its shareholders, shouldn’t kill people or make them ill, and so on.

And, more specifically in the tech startup world, a great many entrepreneurs will agree that startups should hire the best people they can, should iterate, should keep an eye on relevant metrics, should have automated test suites, should have automated deployments, should have backups of valuable user data, should be running on secure, well-administered servers, and so on. For B2B startups, everyone agrees that making sales, creating a good brand and building strong customer relationships are good things.

At the very least in public, very few entrepreneur will disagree with those values. But, as with the more generic human values, there is a world of difference in how each entrepreneur orders those values. Are backups more important than automated tests? Is saving money more important than implementing good metrics measurements? Is it ok to treat your employees harshly in the name of shareholder returns?

If you’re going to work in someone else’s business, it is wise to try and determine how they have ordered their values before doing so – this is why interviewing with people who work there already can be so important for the job seeker.

And, similarly, for yourself! What sort of entrepreneur are you (or will you be when you start your own business)?

To be aware of your values and to examine their worth with your own mind is yet another subtle source of freedom. Keep Nietzsche’s hammer at hand to gently tap on each value and to judge the sound. Depending on the place where they are hung, some of those bells may give an empty ding of hypocrisy. We tend to forget that values are man-made axioms agreed as beneficial. There is nothing God-given about them. You do have a right to examine them freely – in your head – to chose your own choices. This is not theory: your own chime, your arrangement of personal values chants who you are.

Thoughts from 2017

As time has passed, I’ve been able to see first-hand how important knowing yourself is, if you’re trying to build a successful company. Reading this article again, I see that it lacks a method by which you can know yourself – Nietzche’s hammer is a bit too abstract for most people. Ultimately, to know yourself takes the same thing as to know someone else: you have to witness the person’s actions, particularly when they need to make difficult decisions.

So my advice today would be that knowing your values is important and yet at the same time the only way to really get to know yourself is to go out in the world, do things, make decisions. Then, be sure to reflect on your choices regularly, and gain the self-knowledge available to you.

Don’t be yourself

A lot of advice given to people (and, to some extent, to companies) amounts to “just be yourself”, or “just be comfortable with who you are instead of trying to change”.

This advice is well intentioned, fundamentally, and yet I think it’s not all that helpful.

How can I be something that I have only a superficial understanding of? How can I be myself when I don’t know what “myself” is?

As a person, much of my life has been spent discovering who I am. I still don’t really fully know who I am, though I certainly have a better idea than I did ten years ago. Equally certainly, I have a less good idea than I will in ten years. It’s not just that the ten years will change me (though they will), but also that I’ll have a more useful map of “me”, both the “me” that I am now and the “me” that I will be then.

Similarly for companies, I have argued before that the right thing for companies to do, rather than trying to “be teal”, is to be true to themselves. But no organisation ever gets to total self-awareness. It’s an ongoing process, discovering what the organisation stands for, in ever more depth. Organisations are made of people and, like people, they have bottomless complexity.

Onto that I’ll add that I believe that when we know ourselves, we are naturally less inclined to try be something we know ourselves not to be. So knowing yourself more leads to being yourself more.

On the other hand, striving to be yourself without knowing yourself can lead to stagnation. If I believe I’m being myself, I might be less inclined to accept that my self could use a little improvement. Why are you putting all this pressure on me? I’m just being myself, and I’m the kind of person who doesn’t like doing this challenging, uncomfortable thing you’re suggesting I might do.

So I would like to suggest a revision of the standard advice to people and to organisations. Don’t strive to “be yourself”. Strive to “know yourself”. Being yourself is a consequence of better self-knowledge.

What will kill Facebook?

This article was originally posted on swombat.com in December 2010.

This question pops up regularly on Hacker News. What will kill Facebook? Before that, it was “What will kill Google?” There was no Hacker News before that, but if there had been, it would have been “What will kill Microsoft?”

Often, the question is asked with a combination of rage and envy. The questioner doesn’t like Facebook, they want it dead, and they wouldn’t mind if they were the one who came up with something that killed it. Aren’t entrepreneurs charming?

However, the question is fundamentally flawed. It’s the wrong question. It leads nowhere. The only company that can kill Facebook is Facebook. Here’s why.

Undead Facebook

First of all, let’s assume that right this minute there is a startup which is just like Facebook 5 years ago. Let’s call it Smashbook. Let’s further assume that Smashbook is going to do to Facebook what Facebook did to MySpace. We don’t know how it might do that, and we don’t care. We just care that this is the Facebook Killer.

What then?

Take a look at the top 100 sites. What do you find at position 51? MySpace. Wait a minute, didn’t MySpace get “killed” by Facebook? They sure did, and Smashbook will have exactly the same effect on Facebook. It will drop from position 2 to position 10. Maybe. After a few years.

In other words, even if a Facebook killer was out today and ripped Facebook a new one, it would still take many years for this to be noticed by Facebook, and it would take decades before it finally did kill Facebook.

Ok, but how to kill it?

Is it even possible for Smashbook to exist? The evidence of Facebook killing MySpace would point to ‘yes’, but this is not so clear. When Facebook came on the scene, MySpace already had many issues. Due to MySpace’s design and its demographic, large groups of people were simply not interested in joining MySpace, and so MySpace already carried the baggage that would eventually cause it to get trampled by Facebook.

Facebook, on the other hand, doesn’t have any such flaws. You might say that privacy is Facebook’s flaw – Diaspora and others are certainly betting on that – but, unlike design and demographics, privacy is not something that most people care about. The odd geek will get angry and leave Facebook, but for most, privacy is of no interest.

In this, Facebook is similar to Google: it has utterly dominated its market and has such a lead over its potential competitors that no one can catch it. Facebook is as unkillable as Google.

So how unkillable is Google?

To see whether Google can be killed, let’s look at the previous “unsinkable” title-holder: Microsoft.

Microsoft is far from dead (and probably will never die), but it has made a very good attempt on its own life in the last decade. With Windows Vista, Microsoft did what it could do commit suicide on its flagship product. Six years of delays, bugs, driver support issues, usability issues, and so on – Vista had them all. And yet even that didn’t work. Microsoft’s revenues barely took a hit. Like any company of this size, it will take decades for it to kill itself, and it will have countless chances to avoid death along the way (and probably will successfully take one of them).

No company is really “killing” Microsoft. What may be killing Microsoft is its own failure to adapt and evolve with the times. What will eventually kill Microsoft’s current cash cow is the slow but inescapable disappearance of the Windows/Office monopoly, to be replaced by “the cloud”, whatever form it eventually takes.

Google, similarly, will be killed not by a competitor rising out of nowhere, but by falling into irrelevance. This will take many, many years, and Google will have many chances to jump onto whatever the next wave of relevance is.

So, back to the beginning.

What will kill Facebook?

As I said at the beginning, this question is flawed. Facebook, like Google and Microsoft before it, has risen on a giant wave, that of social networks. As an entrepreneur, thinking about “killing Facebook” is unproductive. You won’t kill Facebook. No one will.

The right question to ask, instead, is:

What will be the next giant wave?

If you can figure that out, and execute the right business to catch that wave, and beat every other business who sees it too, and end up king of the hill at the top of the next wave, then you will have beaten Facebook in the only way which is meaningfully possible. Chances are, when you get there, you won’t care much about how to kill Facebook, or any other mega-company.

Thoughts from 2017

The points of this article are still true. The latest darling to kill is Apple, and many are predicting its demise. I joined in that, with a caveat1. The caveat is partly informed from the views in this article. You can’t “kill” giants like Facebook, Apple, Microsoft, etc – you can only wait for them to fail to catch every single important wave of change. Eventually all things die, but category dominators like these companies take a ridiculously long time to die.


  1. “Like Microsoft, I think Apple will continue to make mind-boggling amounts of money for those 5, 10, 15 years. It just won’t be from my wallet, I guess.”

Being Teal vs Being Cool

“Teal” is a hot topic these days. I wouldn’t go as far as to say that everyone wants to be Teal, but it’s definitely something on a lot of people’s minds. Frédéric Laloux’s excellent book, Reinventing Organisations, has inspired many to meet the challenge of our times, and to create new kinds of organisations. The tech scene, as usual quite willing to experiment with new things, is intrigued, particularly given recent high-profile cultural car crashes like Uber.

No one wants to build the next Uber, culture-wise.

This leads to something that I’m very familiar with, having spent about 3 years in that phase, which is the desire to “be Teal”. Given that society tends to be organised in a top-down, traditional, closed “Orange” way, the natural first step was rebelling against the current order. We saw being Teal as being not-Orange, and so shunned anything that looked like a traditional management structure, because clearly it “wasn’t Teal”. Being more Teal mostly meant avoiding the trap of being Orange (i.e. top-down, traditional, closed) by shunning anything that looked like a traditional management structure, because it clearly wasn’t Teal. We even had a Hipchat & Slack (we transitioned during that period) emoji, “:orange_creep:”, which we used to flag to each other in a light-hearted way when an Orange concept was creeping in.

At the beginning of this phase, in late 2013, inspired by Ricardo Semler’s books, we first dissolved the link between Directors and specific areas of the business, eventually doing away with the concept of Director completely. People at GrantTree had no bosses. For a long period they had no job descriptions either. Everyone participated in decision-making (via a sort of consensus process). Yet things kept moving along, growing, developing.

Frustrated by the slowness of consensus decision-making, I looked for more information on how to build the kind of company culture we wanted. I found Laloux’s book, and upon reading it realised “aha, we’re actually Green right now, we need to be more Teal”. Fascinated by Laloux’s descriptions of Buurtzorg, FAVI, Morning Star, and other miraculous companies he called Teal, and in particular by how everything just seemed to work by itself if you removed the structures that were in the way, we continued our structureless journey, waiting for Tealness to emerge1. Some minimalist processes did come into place because we really couldn’t live without them, like a dismissals process and a pay process, but each of those stood kind of alone and was developed independently. Each process also seemed aimed at one thing in particular: protecting individuals from Orange-like authority.

This “we’re trying to be Teal” phase ended only in late 2016, when we decided that the structures of the business weren’t serving its needs and started putting the right kinds of structures in to serve the business as a whole. We stopped being terminally afraid of hierarchical structures and instead looked to get their benefit without their drawbacks.

People who have been on this journey may recognise that throughout this “let’s be more Teal” phase we were actually simply going through our Green (unstructured, consensus-based, egalitarian) journey, digging further in that direction. From today’s perspective I feel somewhat frustrated at this, and I choose to think that perhaps this was a necessary part of the learning journey, though at the same time I imagine it could have been shorter somehow.

Another consequence of this recent phase is that I’ve started to look at “Teal” as a somewhat suspicious term, one that doesn’t really serve our purposes very well. Ironically, I think this is a sign us being more like the companies in Laloux’s book than we were before. They don’t call themselves Teal: they are just structured in a way that makes sense for them.

Being Cool

There’s an interesting parallel between Tealness and Coolness.

Every teenager goes through a phase of wanting to be cool2. At first, wanting to be cool happens because they see someone else who is cool and they want to be like them. But of course, the way for them to be “cool” is just to be themselves – authenticity is what may lead to “coolness”. That’s pretty hard to do when they don’t know who they are (a common case for younger humans and organisations). If they don’t know themselves, the way to coolness is to work on finding themselves, and removing from their life things that stop them from doing this, rather than specifically on trying to be cool3.

Which is not to say that the desire to be cool or teal doesn’t serve any purpose: it does, in both cases. Similarly to a Zen Koan, each quest serves to highlight its own futility.

We can only “be cool” when we’ve stopped pretending to be someone who we think is cool, and are actually being ourselves, without all the bullshit and pretense, including the superficial desire to “be cool”.

We can only “be Teal” when we’ve stopped trying to adopt practices that we think are Teal, and are actually just being true to the purpose and context and work of the organisation without all the bullshit and pretense, including the superficial desire to “be Teal”.

Who cares about “being Teal”? Do you wanto to build a successful business with a clear purpose and motivated, happy people? Then work towards that rather than towards conceptual Tealness. If you wouldn’t define your mission as “being a cool business”, don’t define it as “being a Teal business”.

Thanks to Andrew Ormerod for the many discussions about the ideas in this article!


  1. Sadly, this is an easy thing to take away from Laloux’s book that is false: self-management does not emerge naturally from the removal of management any more than agile development emerges naturally from the removal of waterfall planning. Both take discipline and great structures.

  2. Sometimes in a very circuitous way, by denying they want to be cool at all, and hoping that’s the path to coolness.

  3. And of course this is not a quest with an end point: you don’t suddenly “become yourself” and then stop changing).

Principes of Pitching

This was originally posted on swombat.com in April 2011.

Learning how to pitch an idea effectively is an enormously useful skill that they never really teach you at university or at school. It’s the kind of thing you learn from personal experience. There are many articles providing formulae for pitching or presenting your startup, but few about the principles behind those formulae.

Back when I was still at university, I spent a whole Easter holiday building a prototype for a chemical spot auction site. In this I made many mistakes (among others, I started by building an elaborate user management system rather than focusing on the key dynamics of the auction process), but the real killer came when we pitched it.

I was working with a guy who was just as inexperienced on the business side as I was on the programming side. His father happened to be a top-level executive at a big chemical company, and so through this huge foot in the door we got an entire hour booked to pitch this product to a panel of senior people at this blue-chip company. I remember sitting on my bed and naively thinking of how we would spend the billions of dollars a year we were undoubtedly going to make from this surefire deal.

Golden opportunity

Was this meeting a golden opportunity, or just a formality to please the boss? I don’t know. But what I do know is how much we screwed up on whatever this was.

On the technical side, everything fell apart. This was the day the ILOVEYOU virus hit, and all the corporate networks were down. Our site was unreachable. I had not thought to have it running locally on the laptop so that I could demo it without internet access (über-rookie mistake). When the server finally became reachable again, the meeting was over, with only one sympathetic soul staying behind to have a look at it. I felt mortified. My entire purpose had been to build this prototype for the demo, and that had completely and utterly failed. Two months of work for nothing.

The real killer, though, was our pitch. To my partner’s credit, I must say that he handled the whole thing himself, and certainly did it better than I would have – but it was still a disaster, and unlike me, he had no technical difficulties to blame. As I watched the pitch unfold and observed the audience, I felt my heart sink further.

We had an hour booked. Here’s how my partner structured the pitch: for the first third of the presentation, about 10 minutes, he talked about how startups were changing the world (which was interesting timing, considering we were two months into the dot-bust); the second third focused on how B2B was a growth area and predicted to make many billions of dollars over the next few years; finally, the last third talked about the customer, and repeated things they knew about themselves, and finally maybe one or two slides were about the product we were pitching and what problem it would solve for them.

So, in short, out of about 30 minutes of presentation time, only 2 minutes answered questions that the audience actually cared about.

I can’t remember exactly what sort of questions there were, but if I recall correctly, the “panel” took the excuse that the prototype wasn’t working to leave before the hour was out. At the time, it seemed that they left because the prototype didn’t work, but, in hindsight, I’m pretty sure they left because they hoped to still be able to do something productive with the little bit of time left in that wasted hour slot.

Hindsight 20/20

Fast forward 11 years later, and I still remember this story, I can still bring back to mind the feeling of sitting through that disastrous meeting, and the insights I got from it. I’ve now pitched hundreds of times, various different ideas. I’ve watched our Woobius interns fumble together a pitch with no preparation (they did better than I did back in 2000). I’ve pitched at competitions, during sales meetings, sales calls, networking meetups, and so on. I even spent two weeks cold-calling 20 people a day to pitch them my “voice on the web” startup (I hate cold-calling).

But the most important lesson about pitching, I learned in this very first pitch:

1. You have to tell people what they want to hear.

With this, I don’t mean that you have to make up stuff. What I mean is, out of the vast infinity of facts at your disposal, you need to ruthlessly zoom into the small handful of key points that the people in front of you care about. Back in 2000, our audience didn’t care for startups, B2B, or well-known factoids about their company. In the context of this meeting, they cared about two, maybe three things:

  1. Are these guys pitching something I should care about?
  2. Are they credible?
  3. (probably) Can I get out of here sooner without pissing off the boss?

The whole pitch should have been focused on answering these questions quickly, smoothly, effectively. This could probably have been done in 5 to 15 minutes, with most of the hour left for answering questions and building up our credibility further.

Since then, when pitching anything, I always first try to figure out what the “audience” cares about, what they want to hear. For example, your pitch to a customer and your pitch to a VC must be vastly different. The VC cares about whether you’re building a startup worth investing in. The customer cares about whether you can solve their problems. Your friends care that you’re doing what you like and not heading for disaster. Your parents care that you’re not wasting your life chasing unicorns and rainbows. This brings us to the second most important lesson of pitching:

2. You have to know who your audience is and understand them before you can pitch them effectively.

Any pitch where you don’t know who you’re talking to is a shot in the dark. It might hit something, but who knows what that might be? So, before answering that oft-asked question, “So what do you do?”, make sure you first try and figure out what the other person does.

Finally, there’s a third critical aspect of pitching that we failed at, back in 2000, that I’ve become more aware of as the amount of sales work I do has increased.

A long time ago, Aristotle wrote about rhetoric that it was “the faculty of observing in any given case the available means of persuasion”. Pitches are a minor application of rhetoric. They do not exist in a vacuum. You don’t pitch just for the pleasure of it. To be described as “good” in any way, a pitch must have a purpose, something you’re trying to achieve, and a “good pitch” is one which achieves its purpose.

Let’s say that, against all odds, the chemical company’s executives had liked us and liked our product. What then? They would naturally have asked, “So what are you looking for?” And the reality is that, naive as we were, we hadn’t even thought of that before going into the meeting.

So this is the third most important lesson of pitching:

3. In order to deliver a successful pitch, you have to know what you want to get out of it.

There are many things you can honestly want out of pitching: customers, funding, esteem, friendship, rapport, advice, insight, introductions, and so on. Depending on what you want, your pitch will need to change. You don’t pitch for business in the same way that you pitch for advice or to build a relationship. Thinking about what you want ahead of pitching is not just helpful, it is essential in order to get anything out of it.

In conclusion

Ultimately, there is one great teacher of the art of pitching: practice. This is why entrepreneurs get very good at pitching: they do it all the time. But hopefully, these three principles can help make your practice more deliberate:

  1. Tell people what they want to hear.
  2. Know who you’re pitching so you know what they want to hear.
  3. Know what you want out of your pitch.

Thoughts from 2017

This article has aged perfectly. The principles within it are evergreen – I would argue they were as true a hundred or a thousand years ago as they were today, and so they’re likely to have some lasting power. I now have even more experience of pitching, and of being pitched (as a seed investor) and all of it supports those straightforward points which so many pitches fail at.

Fit your product to the right market

This was originally posted on swombat.com in March 2011.

On my first startup, I made the mistake of not talking to customers at all until launch day. As a result, the product sucked – it was not fit for any market. And because it was unfocused, it was impossible to define any sort of effective marketing strategy, either. This is the kind of expensive mistake you don’t make twice, and I extracted it as a one of my “N tips” posts later (see tip number 4).

So imagine how surprised I was when I managed to make a variation on this mistake again with the next startup – albeit in a different flavour. We launched within 2 months, had active users from the right industry right away, saw the product spread… and yet when it came to charging people, the process of getting those happy users to pay was harder than pulling teeth from a cat! Moreover, when trying to sell to other potential customers, who had been unwilling to use the product for free but seemed more inclined to pay for it, there was always a feeling that the product was exciting and had potential, but it didn’t quite do what they needed in order to justify paying for it.

In startup lingo, that’s known as a product/market fit issue.

Fit the right market

It turns out that getting a prototype out there is not enough. You have to get the prototype into the hands of the right market. If you’re planning to sell a paid SaaS product, this means finding early users, from day one if possible, who will pay. Otherwise, you’re getting product-market fit – with the wrong market.

In that context, it was good to see, recently, the following story about SyncPad, who did launch to paying customers right away – which enabled them to discover that their paying market was not who they thought initially:

After Davide launched his app he hit the streets and began talking with his actual customers. What he discovered surprised him. Instead of taking the art world by storm, Davide discovered that his true customers for SyncPad were in the business market. He found that companies were using SyncPad to help manage meetings (both remote and locally), real time visual communication, and for presentations.

SyncPad made some wrong assumptions about who their customers would be, but by charging early, they found those assumptions out very quickly, and were able to pivot their product into the right market.

The price selector

Price is a very strong selector when it comes to users. The people who pay are often not the same as the people who want a free product. This is especially obvious in the B2B market, where “how much the customer wants to pay” allows you to select between enterprises, small businesses, freelancers, etc.

If you build a product with the feedback from free users, you’ll build a product that’s great for free users. If you want to build a product which users will pay for, you need to be charging them as early as possible so your product feedback comes from paying users.

Charging early

One approach for charging early is to ask users to pay from day one, even while your product is in early beta. Even though they’re helping you out a lot by being some of your first users, you need to validate that they are the right kind of user, and the only reliable way to do that is to ask them to pay you.

Of course, you can’t charge them the full price. They’ll laugh you out the door and you’ll lose a potentially very valuable relationship. So, what do you do?

You give them a steep discount. “We’re still early in the development, so you will get a 90% discount for the first three months, and we’ll review the price upwards as more features are developed.” This can also lead very nicely into a discussion of what feature they would most like to see in order to accept the price increase in three months. This can turn into your product road map, if you manage it well.

Of course, perhaps no one will want your product even at a 90% discount – but if that’s the case, you should revise your assumption that they’ll be willing to pay for it at full price, ever, and perhaps pivot into a different product, one that people are actually willing to pay for.

Thoughts from 2017

This article is still very relevant. I frequently bump into new founders for whom this is a useful idea, and who haven’t heard it from somewhere else. In particular, the idea that price is a selector seems sadly rare, given how many founders would benefit from it.

Are patents any good for entrepreneurs?

This article was originally published on swombat.com in February 2011.

Yesterday, I attended an IP Review Event organised by the Intellectual Property Office in the UK. The focus was a review of “Intellectual Property” and how it impacted entrepreneurs. About 30 startup founders were represented in the audience.

Intellectual Hot Pot

Intellectual Property, of course, covers a great many different types of things.

Some (like Trademarks) are hard to argue against. If you start a company called “Daniel Tenner’s Widgets”, and register that name as a trademark, it is reasonable that your neighbour shouldn’t be allowed to start another company by the same name and compete with you.

Others (like copyrights and patents) are more nuanced. Entrepreneurs know, from everyday experience, that ideas aren’t worth a whole lot. Execution is everything. Some “ideas”, such as innovative mechanical inventions which require a lot of experimentation to get right, are clearly worthy of protection, but most ideas that earn patents are far too generic. And no one, not even the big boys, is immune to being sued by the owner of a spurious patent.

The first thing to do with this, then, is to split out the debate into its reasonable parts. Patents are not copyrights are not trademarks are not trade secrets are not design rights. Let’s take just one strand out of this hot pot and examine that: patents.

Patents and startups

A number of feelings were echoed by pretty much everyone at the event yesterday:

  • patents are effectively useless at protecting young companies; they are too expensive to acquire and too expensive to enforce;
  • on the other hand, patents can much more readily be used by larger competitors to squash smaller innovators; larger companies can afford the costs of enforcement and can register a lot of patents;
  • therefore, patents, as they exist, are a risk which startups must simply live with, and hope that it won’t turn into a full-fledged catastrophe, as that can easily kill their company if it comes at the wrong time.

All this is true whether you are in the US or the UK.

The feeling about patents was best captured by one attendant who stated, during the event “The more I learn about Intellectual Property issues, the less I want to do a startup”.

Another attendant, woefully optimistic, suggested that “we don’t want patents now (while we’re small), but we’ll want them in a couple of years (when we’re large)”. Actually, even large companies who have used patents to their advantage often don’t think they work as they are. Jeff Bezos, who applied the ridiculous One-Click patent against Barnes and Nobles, later (back in 2000) wrote a letter arguing for patent reform. Since then, things have only gotten worse, with countless ridiculous patents being awarded, and some companies even setting up shop as high-volume, highly structured patent trolls to exploit this gaping hole in the legal framework.

It’s pretty clear that companies large and small either dislike or just about get along with the patent system as it is, at least within the IT industry. It protects no one who needs protection, creates a constant threat for those who can’t afford the protection, and generally its main effect is to provide data for nice infographics about who is suing who in an industry (answer: everyone is suing everyone they can).

In short, patents are an overhead to innovation, one that smaller companies avoid paying by taking on an existential risk that could kill them, and an overhead that simply increases the cost of doing business for larger companies.

And what about everyone else?

The original purpose of patents and copyrights, according to the US constitution, was:

To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

The purpose was to promote progress, which would make things better for everyone. In order to achieve this, the founders of the United States of America were willing to make an exception to their otherwise staunchly anti-monopolistic views. This seems like a valid purpose for any law: to make things better for everyone.

So, excluding for a moment the people who file patents and get sued by patent holders, do patents, as they are now, make things better for everyone else?

I believe the answer is clearly “no”. Patents, being an overhead, drive up the prices of goods and services, and reduces the amount of innovation happening. Everyone loses out, most of all consumers who don’t get new products and services or who pay more for them. The only ones who win out of the current system are the patent lawyers.

Conclusion

My conclusion is simple.

The patent system, as it exists today, both in the US and the UK, is a nuisance, an overhead, a problem that everyone could do without. I would cautiously advance that the system that we have in place for patents is worse than no system at all. That said, there is a place for a patent system, but it needs to go back to the fundamental principle of making things better for society.

Patents (or other forms of intellectual property law) should not be predicated upon moral considerations of who owns an idea. From a moral standpoint, ideas, unlike physical things, are owned by everyone and no one, and to impose a false economy of scarcity on ideas is a significant burden for society. However, this burden is reasonable so long as sufficient benefits come with it.

So, a review of Intellectual Property Law, whether focusing on patents or other areas of interest, should primarily concern itself with this fundamental question:

Is the system designed in a way that benefits society sufficiently to outweigh the costs to society?

As far as patents are concerned, the answer is a resounding no.

Thoughts from 2017

Six years on I don’t find that my opinion on patents has shifted much. There has been a little bit less high profile patent trolling (at least as far as I’m aware), but plenty of large companies flinging their patent portfolios at each other on various spurious grounds. I think patents are still a nuisance to startups and older tech companies alike.

How to use metrics in a startup

This article was originally posted on swombat.com in February 2011.

Over the past few months there have quite a few articles about metrics, which are, of course, a very important topic for startups. Metrics like these can and should drive your startup’s development, once you get past the initial part of the hypothesis testing phase.

Yet there seems to be a surprising lack of clarity in many people’s minds about what kind of metrics are useful, how to make them actionable rather than vanity metrics, how to use them, and when to use them. Here’s my attempt to clear things up.

1. Why you should care

Metrics have an aura of scientific validity about them, and they take effort to measure. This means that if you do measure metrics, you’re likely to care about them and act on them. If you measure the wrong metrics, or you measure them wrongly, or you draw incorrect conclusions from what you measure, you are quite likely to make incorrect decisions based on them.

So, if you’re going to look at metrics and act on them, do it correctly. If you spend time and energy calculating metrics and end up making the wrong decision because of those metrics, that is much worse than not measuring metrics and going by gut feeling.

2. When not to use metrics

The first misconception, which I fell prey to as well in the past, is when to use metrics. If your traffic is too low for metrics to be meaningful, then measuring metrics is largely a waste of time, and making decisions based on statistical noise is potentially harmful.

If your traffic is very low, you may still be able to measure things like conversion rates and run A/B tests over a long period of time, but it will be a very slow process, and you are likely to get much better and quicker results by observing user activity directly and letting your subconscious do the work of spotting potential patterns. Don’t forget to double-check those patterns before acting on them, though. The brain is a wonderful pattern-matching machine that will see patterns in the most unlikely places.

3. Actionable metrics

An actionable metric is one which directly leads to some kind of action. As Eric Ries put it, “if you cannot fail, you cannot learn“. If your measurement does not lead you directly to some kind of decision, it’s not actionable. And, if the measurement cannot lead to both outcomes for the decision (e.g. “build out the new feature” or “pull the feature”), it is also not a real actionable metric.

For example, measuring your monthly traffic is a classic vanity metric. Are you going to do something differently if the traffic is higher? Lower? The same? Why?

Another, less obvious example: if you put in a new feature, and you measure its usage, based on the idea that it is “testing your hypothesis that the feature is useful”, this measurement is not an actionable metric unless you’re willing to pull the feature if not enough people are using it. Many people will measure the new feature usage after they’ve already made the decision to keep the feature anyway, under the illusion that it’s a meaningful metric.

Measuring metrics without linking them up to a hypothesis that you’re testing is largely a waste of time, and may lead you to make incorrect decisions.

There are reasons to measure non-actionable metrics, but those are to do with managing the business).

4. Management metrics

There is a good reason to measure non-actionable metrics: managing the business. In order to manage the business effectively, you need to know how much money came in. You need to know how much tax you owe to the government.

A related point: you need management metrics when pitching your business. User count is largely pointless to measure, but if you’re pitching to investors, or even customers, it’s a metric that, if it looks good, will make them feel good (that’s what a vanity metric is…), so it is useful to measure it even though it is probably not actionable.

But, management metrics are not actionable. They are subject to external influences, and internal biases (you tend to see what you want to see in them). Don’t make the mistake of driving your product design on the basis of vanity, management metrics.

5. How to use metrics posts

How then, to use a post like this one or this one, which gives a set of metrics without actions. It looks useful, but is it?

Yes, it is. What these metrics posts do is tell you what are the fundamental metrics that your tests should boil down to. Measuring “how many people used a feature”, for example, is not a fundamental metric. What metrics posts really point out are KPIs for your type of business.

Measuring the KPIs by themselves can often be a useful management metric, but it is not actionable. However, any actionable metric should boil down to a KPI. So, when you put in a new feature, don’t measure “how many people used the new feature”, measure “whether people who had access to the new feature were more likely to pay” or “whether people who had access to the new feature stayed on the site longer”.

6. External influences

One more key point to make about metrics is that there are many external factors that can affect your measurements. Don’t be caught out like this guy. Any test should be run with both options presented in parallel to compensate for seasonable changes. If you measure conversion with one landing page on Friday and another on Sunday, what you’re measuring is a combination of your landing page changes with the weekly cycle of traffic. So, all tests must be run in parallel.

In addition to that, if your users are interconnected, you need to be careful about how you group users together. Don’t show one user one set of features, and a different set of feature to their colleague, or you will lose both and falsify your metrics. Remember that you don’t need to have the same number of people on the A and B sides of the A/B test – you just need enough people on either side.

Management metrics are particularly susceptible to external influences, so do not use them to drive product design decisions.

7. Unmeasurable things

Finally, no metrics overview would be complete without mentioning that there are many things in the running of a business which cannot be turned into statistics. You should measure everything you can, but don’t fall into the trap of thinking you can measure things like design, product vision or even the fitness of your first few key hires.

Trying to A/B test things which are not measurable is foolish and leads to bad decisions. Even worse, ignoring key things just because they’re not measurable is selective blindness. Be very aware that there are many things in the running of a business which cannot be measured but are worth doing.

In conclusion

I’ve made a number of points that I hope will be useful to you. The key takeaway is that using metrics incorrectly is worse than using no metrics at all. Metrics are a knife. Sharp, accurate, strong, useful – but make sure you don’t hold it by the blade:

  • Care about correct metrics usage; using them incorrectly will lead you to bad decisions.
  • Don’t use metrics when you don’t have the traffic; use user activity streams instead.
  • Actionable metrics are metrics which drive a decision directly; don’t act on vanity metrics.
  • It’s ok to measure management metrics, but be aware that they’re not actionable.
  • Metrics posts provide KPIs; make sure your measurements boil down to KPIs, but don’t measure the KPIs by themselves, except as a management metric.
  • Beware of external influences, they can falsify your tests.
  • Don’t discard unmeasurable things, and don’t force unmeasurable things into an A/B test mold.

This is by no means a complete list – there are many more articles even on this site, let alone in other places. It takes more than one article to learn how to use metrics correctly, but hopefully this is a good starting point.

Thoughts from 2017

I find myself much further from this topic than I was then, but I believe it’s still correct. In a way, I am neither more nor less skeptical of metrics: they have their use, and if you know how to use them they will make a big difference to your business.

I would add a note of caution from a few years of experience though: be careful when linking metrics to performance or even job security. This tends to lead to serious distortions in people’s behaviour – they will optimise for the metrics that they are being rewarded for, at the expense of everything else, including the long-term success of the organisation. When it comes to motivation, intrinsic motivators are far more powerful, lasting, and less distorting. They’re also a lot harder. Maybe check this page out for many thoughts on the topic.

How to write good startup advice articles

This article was originally published on swombat.com in early 2011.

Startup articles, much like some other content niches, have a tendency to be addictive but content-free. Everyone is guilty of doing it. I’ve done it too. I don’t think there are any regular authors of startup-related article who don’t sometimes produce articles which are perhaps entertaining, perhaps even enticing, but which add nothing to the reader’s life.

Those articles are, by definition, a waste of time.

Since I spend a lot of time both reading and writing startup articles, here are some key points to bear in mind if you prefer to write articles of substance, which others can learn from and apply in their own startups.

1. Avoid over-generalisation

The most common flaw of pointless startup articles is over-generalisation. Entrepreneur brains are by necessity obsessed with finding patterns in chaos. That’s what we do every day. So it’s natural that we see many patterns that look like they could be general rules.

A wise man once said, “the plural of anecdotes is not data”. When writing a startup article, be very careful not to extrapolate from one experience that happened to you to a general rule for startup. “X startup mistakes” or “Y startup tips” are basically collections of generalisations based on personal experiences. Some of your points may even be correct by sheer luck, but the short-form nature of a list of tips means that even those don’t have the necessary context to be really useful.

2. When talking about personal experience, include context

Some parts of running a startup can be analysed scientifically, but a great many cannot. You cannot a/b test your ability to close a sale in person. You cannot a/b test your pitch to Paul Graham on YC interview day. Each sale, each pitch, anything involving person-to-person contact is unique. Some general principles may apply, but unless you repeat the process a lot (e.g. you’re a sales person who has pitched 500 enterprise customers), it is very hard to come up with any kind of reliable “law”.

Even things that don’t directly involve people are often contextual. “The best technology to build your statup” depends on the kind of business you’re building, the sorts of products you’re considering, available talent nearby, your long-term objectives, your budget, and so on. And it will change year by year, if not month by month.

That’s fine. Not every post needs to be declaring a new law of nature. But when you post something which is a personal experience or opinion offered up to others, be sure to include as much context as possible. Otherwise, people will not be able to properly make use of it, because they won’t know if it might apply to their specific context.

“This is what you must do so that your startup can be successful” is useless. “This is what I did and it helped my startup succeed” is marginally less useless. “In this context, I did that and I believe it helped my startup be successful” is potentially useful.

You don’t need to preface every sentence with “I believe” or “in my experience” – doing that will make your writing weak. But make sure you give the right amount of context, and qualify those of your statements which are really just wild guesses rather than tried and tested theories.

3. Avoid posts with no actionable points

Posts like this or this, listing attributes of successful entrepreneurs, or programmers, or businesses, or whatevers, are not actionable. They’re just entertainment – possibly even a damaging form of entertainment, since they contribute to the myth that successful entrepreneurs are heroes and goddesses that are out of the reach of the common man.

Whenever writing up advice for startups, ask yourself “what do I want readers to change about what they do after reading this?” If the answer is “nothing”, your article is entertainment, not advice. If the answer is not “nothing”, then make sure the advice is clear to the reader by the time they reach the end of your article (even if they skim!).

4. Be brief, but not too brief

Entrepreneurs are busy people. The ones who most need your advice are often juggling a full time job along with their startup. They don’t have the time to read a 3,000 word rant in order to extract a couple of meaningful points. Be respectful of your readers and their limited time.

After you’ve written your article, but before you post it, ask yourself “is any part of this outside the scope of this article? is any part long and rambling? is there any section that I added just because I wanted to talk about it, rather than because it’s useful?” Cut mercilessly.

At the same time, don’t cut too much. Seth Godin’s blog is a good example of advice that’s been cut down so much that it becomes useless. Startup advice is only useful with context. If you cut the context out, you might as well not post the article. (of course, Seth’s goal is probably not to post startup advice, but merely to maintain readership so he can sell his books)

If you just have too much content and all of it is relevant to your points, you’re trying to make too many points. Break the article up into several articles in a series. As a bonus, this is said to be good for getting RSS subscribers…

5. Present your article properly

Presentation matters. If you wrap your life-changing, mind-expanding point in a badly formatted post on a generic wordpress (or posterous, or tumblr) blog, you are hurting your chances of making a positive difference. Make sure your article comes in a credible package.

Consider also the visual appearance of your article before you post it. It should be clear, at a glance, what the article is about. It should not look daunting, with huge paragraphs and no subtitles. It should be possible to skim it and still get the gist of it.

In conclusion

If you have advice that you’d like to share with the community (and many entrepreneurs do), try to follow these points when doing so:

  • Avoid over-generalisation so you don’t give thoroughly incorrect advice by wild extrapolation
  • Include enough context for the reader to be able to decide whether this applies to their context
  • Avoid posts with no actionable points: they are just entertainment, not advice.
  • Be brief, but not too brief. Respect your readers’ time, but include enough context to be useful.
  • Get the presentation right, so that people take your article seriously and can read it efficiently.

Thoughts from 2017

This article has aged very well. If you’re writing or thinking of writing startup advice article, I would really encourage you to take these points to heart, for all our sakes (and your own too – you may end up reading your own blog posts some day, as I am doing now!). Sadly, content-free and context-free articles for entrepreneurs abound more than ever, even from sources who should know better. So the world goes.

How to evaluate and implement startup ideas using Hypothesis Driven Development

This article was originally published on swombat.com in January 2011.

So you’ve come up with an interesting idea. You think it might work. You’ve sketched it out using various tools like the Business model generation  canvas, a business plan, an Excel financial model, etc. You’re still positive on the idea and think it’s probably worth giving it a shot.

What next?

One common approach is to visualise launch day and work back from there. Figure out what you need to launch some kind of initial product, and then start casting the spells and incantations required to get there (mostly in the form of code or application specifications).

A slightly better approach, which those who have tried the above method usually end up using next, after they built something that took them 6 months but was utterly useless to anyone, is to build the bare minimum that you need in order to get some users, any users, to use the system on a regular basis. This is better, and gets you feedback much more quickly than the previous method.

Even better is to aim not for something you can get people to use, but instead try to build something you can charge for immediately, even if the price is lower. This is often favoured by [Lean Startup](http://en.wikipedia.org/wiki/Lean_Startup) afficionados who haven’t quite taken the lean methodology the whole way yet.

What do all these methods have in common? They present the unfolding startup as a series of tasks to be completed to get somewhere.

Here’s a better approach.

Hypothesis-Driven Development

A startup idea is not a plan of action. A startup idea is a series of unchecked hypotheses. In essence, it is a series of questions that you haven’t completely answered yet. The process of progressing a startup from idea to functioning business is the process of answering these questions, of validating these hypotheses.

Let’s consider a theoretical startup to illustrate this. Let’s say we’re looking at building “Heroku for Django”. The initial three questions for most web startups will be in the form:

  • Can I actually build it?
  • Can I get people to know about it?
  • Can I make money from it?

Often, this is the order in which they will arise, if you have some experience of web startups but are fundamentally a builder type. Making money is the last concern. “If I can get lots of passionate users who are willing to pay something, then it will probably be alright.”

To apply Hypothesis-driven development properly, you will want to order your questions by priority before proceeding. This is especially essential once you break down the questions into sub-questions and end up with dozens upon dozens of questions.

The best way to prioritise the questions is by uncertainty. An initial order for these three questions might then be:

  1. Can I make money from it?
  2. Can I get people to know about it?
  3. Can I build it?

Your own prioritisation may vary, but if you’re technical, “Can I build it?” will probably be last on the list. Of course you can build it. If you couldn’t, you would probably have discarded the idea before even getting to this stage.

Before trying to answer the questions, you first break them down into sub-questions (please note this breakdown is nowhere near exhaustive enough, it’s just an example):

  1. Can I make money from it?
    1. How much will it cost me to serve the smallest users?
      1. Which cloud platform is best for this?
      2. How many instances will I need at a minimum to run the platform?
    2. How many users will I need just to break even?
      1. How much will I be able to charge per user?
      2. What proportion of paid vs free users will I have?
      3. How well will users convert from free to paid?
  2. Can I get people to know about it?
    1. What channels are there to get the message out?
    2. How much will each of these channels cost me?
      1. How competitive are the Ad-words for this?
    3. Do I have enough contacts to get the initial, core users so the service will be useful to real users?
  3. Can I build it?
    1. What are the hardest bits of technology I’ll need to put together?
    2. Can the scope be cut down so that I have a chance of building a version 1 with extremely limited resources?
    3. Which features can be put off until later?

You should keep expanding this list until you can start to see what the burning uncertainties are. These will be unique to your startup idea and to your skills and available resources. Two people evaluating the same idea will probably come up with different key questions. Once you’ve got those key questions (the ones which make you think “Hmm, I really don’t know this and it’s really important.”), shift those to the top.

Then, start working through the questions, one by one or even in parallel. Most of the time, the answer will not be found in code, but in good old-fashioned research, planning, and the dreaded Excel spreadsheets. You don’t need to answer all these questions with 100% certainty, but you should be clearly aware of the limits of your answers, and when the answer is really critical, you should make an effort to answer it as fully as possible. You can’t know everything, but you gotta know what you don’t know and how much it can hurt you.

At some point, if the idea has answered enough questions, the next most important question will require you to build something – be it a paper prototype, a landing page, or something else. When it’s the most important question, do it, and do just enough to answer the question. Later, if your idea is really good, you will probably, at some point, start to do the really expensive stuff: building a real application.

At that point, with so many critical questions having been answered, the likelihood that you build something that nobody uses or pays for should be low.

Of course, you may succeed by shooting from the hip and just going for it without a second thought, but more experienced entrepreneurs will usually look before they leap.

Thoughts from 2017

When I wrote this article, Eric Ries had been blogging about his Lean Startup ideas for a little while, but the book was still 9 months away from publication. It is obvious that this approach is one of the core components of the Lean Startup Methodology. That said, it extracts one of the key points and condenses it in a more readable format, which I think is valuable to be able to point people to.

All of the ideas in this article are still very much current – even more so, perhaps. Lean Startup, or Hypothesis Driven Development, is still the best way to devise a plan for building a new company: find the most risky assumptions, test them and update them until they are no longer risks, then find the next most risky assumptions and repeat until you have built a functioning company.

Older posts

© 2017 danieltenner.com

Theme by Anders NorenUp ↑