Tag Archives: startups

Web Applications

Better than Freemium

The new Kickstarted blogging platform Ghost has an interesting payment model. At the free tier you have full access to the platform but you are allowed zero views of the content you create.

Normally with blogging software you want to encourage as many page views as you can get to help promote your platform. The Ghost approach is an interesting way of dealing with the issue of trying to explain your product and have people try it without resorting to free tiers or advertising-supported freemium.

However it also means that you are making an open-ended commitment to the platform, if you ever stop paying then all your content disappears off the internet.

Posthaven is more appealing because it makes explicit promises about the persistence of your content. On the other hand as a replacement for Posterous it has less need to explain its proposition.

Having encountered the issue of offering free trials at Wazoku I wondered whether what we were really learning was that our product wasn’t simple enough to pitch a minimum subscription.

Making people pay something, no matter how notional is a more effective way of gathering feedback than the analytics and subjective feedback of free trials.

This pretty cool blog post on removing free plans at Trak.io makes a load of really good points about what kinds of thing goes wrong with free plans and the freemium model.

I’m not sure what the answer is to people not understanding your product but free trials are not the answer. The ultimate feedback on your product is whether someone will pay for it or not.

Standard
Work

Success looks like success

One useful thing I have learnt by working in an early stage startup is that success looks and feels like success. If you are doing something and it does not seem like it is being successful then it isn’t. This might seem like something that is completely obvious but it is really not.

There are many kinds of “not success” (or failure to give it it’s true but cruel name). The worst is the “almost success” where something works and delivers on its promise, but not very well. Almost success creates this dilemma where perhaps with a little iterating and more effort you could turn it into a real success.

When this kind of success creates ongoing liabilities in terms of customer expectations then the situation is even worse. If you try and cancel things or do a lean startup pivot then you are guaranteed to alienate your current customers with only the hope of gaining more of the true customer base you originally envisaged.

Weak success is a little better, weak success is not outright failure but is so unsuccessful that people completely understand if you want to knock it on the head.

In a large organisation though things are far more difficult. Both almost success and weak success are ironically more dangerous in a big and profitable organisation due to two factors: personal reward and hidden cross-subsidy.

If someone achieves any degree of success in an organisation they expect to be rewarded for it. Perhaps justifiably, perhaps not. Either way there are serious morale implications if at the end of period of exertion by any group or individual you kill off the object of all their efforts, no matter how rational and correct that decision may be.

In general people are conflict averse so they prefer to reward almost success and move on to other activities that might be more successful.

However a set of almost successful activities all have real costs and the minute any of them fail to generate revenue sufficient to carry their costs then you are in the world of the hidden cross-subsidy where all your almost successful projects and products start to drag down any aspect of the business that is profitable.

It is a tar pit that can be difficult to escape unless you have really good accounting to see where money is coming and going. It is only easy in a startup because generally you only have one product and therefore all profit and loss is easy to tally and attribute.

So everything in your business that is not a success is a potentially business-killing failure. And for that reason, even though it is hard, you need to end almost success just as much as you need end failure.

The question to ask is not “Is this successful?”; if you are asking that question then the answer is simply no. If you are successful then the question you ask is “How are we going to deal with all this success?”.

Standard
Work

Is this really the manifesto we want?

Silicon Milkroundabout tried to produce a manifesto for why people should consider working at a startup. This is the outcome.

The first time I saw it I was very disappointed. While I cannot knock its authenticity it is a profoundly depressing document. While there are the standard statements about passion and having the freedom to make what you should rather than what you are told to; there is much more about poverty, tiredness and scarcity.

If I read this I would say that working for startups is a mugs game. You’re far better coming in during the expansion phase when salaries are higher and the business case better proven.

The many references to tiredness and lack of sleep is also revealing. What I have discovered is that tremendous pressure is put on you to deliver product in a technology startup and this should be resisted at all costs. Sustainable pace is more important in small organisations than in large ones. In a large organisation you can actually burn out a team to achieve a goal because you probably have access to the resources to replace them. In a small one, once you’ve wrecked a team (probably including yourself) you have no way of replacing them and a death spiral will inevitably set in as decision making becomes progressively worse. Remember that a startup should aim to deliver progress not product. Don’t work with people who don’t understand this.

Money, frankly seems to be the missing ingredient from this list of reasons. Maybe adding “because late-stage equity options are worthless” would ruin the overall tone. Many people, especially investors, are involved in startups because they offer potential massive returns in a low growth environment. Americans are much more open and brash (you might even say vulgar) about this with talk of flipping and sale valuations of millions of dollars (often farcical as in the case of Groupon who merely had the bad luck to be caught before their IPO).

Even then this reason is foolish because if what you want is money then you should go to the City. The money is guaranteed, guaranteed in fact by the government which not only underwrites it, bails it out but then charges off into Europe to protect it from legislation that might affect its lucrative tax haven and money “recycling” business. In contrast being involved in “entrepreneurship” is a rather romantic and significantly more challenging way to achieve wealth.

I do work at a startup though and I was at Silicon Milkroundabout trying to encourage people to join me in doing this.

My personal motivation is that for me a startup is a business that is complete but small enough that you can actually see and understand all parts of it. The interesting thing is that organisational dysfunction is actually just a likely in a startup as a larger firm. Often the problems are actually exactly the same, simply orders of magnitude less significant.

Being able to pull the curtain aside is fascinating. Working in the small also removes the mystique that gathers around things and people that generate large revenues. Once a certain number of livelihood’s become involved in a particular process or product you lose the ability to tinker with things or even to question why things are the way they are. In an environment with no money and no customers any change is either positive or at least neutral.

Working in a startup for non-cynical reasons means creating something that is of profound personal interest. I really am interested in trying to remove friction from the process of turning ideas into reality. Wazoku is a product that I do believe in and what I was saying to a lot of people at Silicon Milkroundabout was try the product. If you are interested in solving the problem and the solution in turn solves some of your problems your work is satisfying at all levels. If there is not a satisfactory solution already in progress for your problem then a startup is the only way that you can initiate that process of moving to a more perfect world.

Working for a startup is a last resort; need should be part of your motivation; ignore idiots and their advice; make sure you get enough sleep.

Standard
Work

Silicon Milkroundabout Roundup

Interesting time at Silicon Milkroundabout this Sunday. There were kind of three levels of activity going on, first of all there was the element of developer goofing off with arcade machines and free stuff. Then there was the opportunity to network, first of all between the startups and secondly between the developers (although I am not sure how much mixing between different dev teams was actually going on).

Finally there was the recruitment activity. Unlike the first event this really was more of a milkround with a younger, less experienced audience. The format did seem to be pitching for talent which is interesting as I am not convinced that people are going to find the best role by going with the best sales pitch. There has to be a better way of understanding the culture of the firm you are potentially joining.

The different streams of activity make the event quite weird in its nature and purposes. It feels like there is a need for a kind of startup expo to allow startups to see and meet one another without the pretext of seeking to employ people. There is also a need for a kind of elite coder event on a quarterly basis that is maybe a little select, a bit like a mini-conference, that allows for networking and swapping of intelligence and gossip on what is really going on at various firms.

Standard
Java, Web Applications, Work

Better, Faster, Weaker

I went to the Developers and Startups Meetup last week (look it up on Meetup if you’re interested it was a good event). One thing that struck me was that all the entrepreneurs were mostly interested in PHP and Ruby on Rails (there was a significant rump of ASP and .Net which I can only put down to C#’s language hotness at the moment). Java in particular was poorly regarded.

I was intrigued by what was causing the negative vibe as while I can understand that Ruby on Rails is the new tech hotness I couldn’t really see the appeal of PHP over something like Java that has a decent stack that is practically free. Talking to a few people I got the sense that PHP was seen as a “getting things done” language. Something that got you to a tangible real product very quickly. Rails seemed to have much the same quality but I think a lot of people felt that Rails skills were more expensive and in a lot of cases they wanted a thin web layer over an existing service backend that already existed.

Of course both PHP, Rails and the Java Web Stack all make various compromises to do what they do. Where Rails is opinionated, Java probably isn’t opinionated enough. If you put all your code into page (Model 1 stylee) then I’m pretty certain that writing JSPs in J2EE 5 is probably as quick to put something together.

Of course one thing that hugely hampers Java as a productive web stack is the compile and deploy loop. There is none of the immediacy of something like RoR that allows you to make changes very quickly in response to feedback. The tradeoff is of course that the code needs to be interpreted and you have to add some kind of caching to avoid the performance hit of always having to evaluate code.

But given that there are a group of people who need to have code quickly so they can sell something to their customers or investors and that they are willing to make all kinds of compromises about scale and maintainance costs is the Java platform really out of the question? I ask this because I think I have been involved in quite responsive Java web teams where feature changes have been matters of days not weeks or months.

I think that perhaps the issue is partially just mental. Enterprise software development tends to take place in a risk-adverse environment where certainty or process is valued over rapid delivery. “Best practice” in this environment tends to sacrifice timeliness. In the smaller business space this might well be a practice turned into dogma.

That said though some Java Frameworks introduce major barriers to just getting stuff done. Any framework that forces you to produce XML based interaction flow is probably distracting you from generating functionality that people want and will pay for. Routing isn’t a trivial part of an application but that’s all the more reason to box clever with it. Any framework that doesn’t make it simple to inject services into classes is making life too hard. Ditto any framework that forces you to work with a particular Expression Language or Templating product.

I am wondering if what I am looking for is actually the weakest Java framework. Rather than having functionality for all circumstances (and having to configure and setup it all up) I want a very basic REST framework which I can then add templating and persistence according to my need. It still wouldn’t have the nice scaffolding of RoR but it would mean that each element of the web app would be absolutely vital to its function. Weakness would generate the power of vitality and reduce the obfuscation of bloat.

Standard