Norway - the land of opportunity?

When travelling this weekend I did some catchup in the pile of unread magazines and found this graph in The Economist:



It shows the relative income differences from one generation to the next (US=1). And it turns out Norway scores very well on this metric, so maybe state funding of educational loans and a pretty egalitarian society pays off in the end. The income mobility is almost 3 times that in the US and the UK.

Interestingly enough, the UK scores just as well as the US. I guess it is just prejudice, but I have always thought of the US as the classical meritocracy - if you are good, you can succeed no matter your background - while my oversimplification of the UK society is as more of a gentlemen's club where the right school, connections and parents are all a necessity to do well.

So the American Dream might just as well happen in Norway, today? I guess still lawyers breed lawyers more often than others, but on a macro level it does not look too bad. Anyway, I think it is a graph to be proud of (still a pity to be beaten by the Danes again, of course).

Vintage Code on a New Canvas

I wanted to do a small experiment with the HTML5 Canvas. To do it, I found some Java code I wrote in 2001[1] and ported it to gwt-canvas (thus compiling a Java subset to JavaScript). It uses a naive redrawing technique[2], but the point of this test was not to optimize performance or create production quality code[3].

Anyway, you can see the result here: CanvasPairs (external link). Try it and see how fast you can find all the pairs!

I did this and a few other, more graphically intensive, experiments to test canvas performance on a few devices (iPad, iPhone and Android-based phones mostly) and feasibilty for doing casual games or minigames inside edutainment titles using technology such as PhoneGap with the HTML5 canvas. The results were somewhat mixed, but for the iPad I have high hopes that IOS4 will improve performance in the Safari browser and on even the not-so-new 1.5 version of Android on a medium spec'ed phone, it was relatively impressive.

My feelings about the technology is ambivalent. On one hand I am excited about what will soon be possible to achieve in all browsers without plugins, but on the other hand the maturity feels a bit like Java applets in 1998 or Flash in 2003. At least I am sure progress will be much faster this time around.

[1] - This summer I visited Moet&Chandon and IIRC, 2001 and 2003 where the last years of vintage produced. I won't go as far as saying no good code has been written since 2003 :-), but the reunion with the code from 2001 was not that bad.

Rewriting it in GWT proved to be a little more work than I thought at first, but I am always (too) optimistic... The rewrite included just skipping a few parts (highscore lists, double buffering, keyboard input for pausing etc.) for now and reimplementing others (for instance a basic preloader to replace the ImageObserver and a string drawer based on drawing segments of an image of symbols, since text on canvas seems to be a bit shaky at the time of writing).

[2] - Basically it redraws the whole canvas for each and every frame. While this (minus some background caching, maybe) might be needed for more advanced games, this particular one might have gotten away with a bit of Image or DIV flipping, I guess - but that was not an option for the platform which it was originally developed in 2001.

[3] - One might also argue that the simplicity of the sample would have made it possible to do it without any canvas (HTML, Flash or Applet based) at all. Again, that might be true - but the main point here was not to implement the specific functionality of the game itself.

Getting beyond the first sale for a micro ISV

...or: putting a long time failed goal public.

In 1999, about the time I was ending my first year in college, I had created a few very simple Java-based games and established my first company. I discussed with my girlfriend (now wife) who was skeptical about paying for a domain/web site, but we (?) decided to do it. Then, with a strike of luck, the largest telecommunications company in Norway - Telenor - found and liked the games and wanted them and similar games for their ISDN-touch screen platform. In total I created 7 games. The payment wouldn't impress anyone (certainly not me) too much today, but as a student it was definitely significant and I also managed to do the deal on a yearly subscription basis rather than as a single payment.

Getting that big customer will probably be classified as luck. The problem is that a micro ISV[1] cannot rely only on pure luck in the long term. Thus the key question becomes: How can you increase the chances of being lucky? And more specifically, how can you get beyond that first project sale?

In my experience recurring revenues are often calculated when pricing a complex software projects (ever heard the "but the next similar project will be much more profitable", only to find that the next project was not that similar in the end?). To talk about “productization” is easy, to successfully do it is not.

I will argue that you can increase the chances of being lucky by (1) securing your rights to the product, (2) thinking about it like a product, (3) building it as a real product and finally by (4) doing the marketing for the product - often only with the guerilla methods available to small firms.

I will go through each of these four points in order and I will use a system I made the first version of in 2003 as a working example. This system is a web-based recruitment system currently used by a single recruitment agency. I will try to see where I did wrong, comments regarding the specific project is inline in italic, and hopefully get some of it right in the aftermath of this blog post. Since I have NOT been successful in trying to sell this to customers beyond the first one, you are now watching live the first structured attempt at changing this (and could argue who am I to write this blog post[2]…).

By putting the failure public, will I finally manage to do it? Anyway, on to the four components I will go through, starting with the intellectual property rights (IPR).

Secure your rights

This might be basic, but if you plan to reuse the software from a project either in other projects or even in a product you must get the IPR correct from day 1. In my experience this is usually possible, but may vary according to type of customer.

On this point I was not too bad, I was sure to get full IPR (giving a partner pricing scheme to also get full IPR to changes developed over the years), but I had to give my customer exclusivity in Norway. In retrospect, a few enquiries have come over the years from Norwegian firms wanting to license the system - so negotiating away that clause at the outset might have paid off. My customer, although always constructive, did not want to give up local exclusivity the one time a customer that was ready to buy actually emerged.

Think about it like a product

Next, I strongly believe you have to think about your product as exactly that – a well defined product. It is easy enough to say that the core of some project is a “product”. But what is the product exactly? Be specific - thinking about exactly which user interfaces and functionalities are part of the product forces the thought process around the product.

Likewise, be specific about who is going to buy the product and what is their willingness to pay? What is important to the customer might be different from what you assume. One way of finding out is getting partly founding for new features from early adopters. This forces your pilot customers to put their money where their mouth is.

Think about the most likely competitors. If there are none you can either hope to be a true genius, but it might also indicate lack of market. Don't let a number of competitors scare you away, a micro ISV can be nimble and develop in new directions quicker than they can! Often it is great to be small and not have a lot of legacy code and customers that use it to think about.

On this point, I just have to say Mea Culpa. It was more a vague hope than a clear strategy behind the product thinking. A few years later it seems to clear to me this is not a volume product (also given what we can support) and it will be priced between the simplest competitors and the offerings from huge ERP/HR vendors.

I have tried to think more about it like a product lately, will return to that when I cover marketing, but first on to building the product.

Build it as a real product

It is not enough to think and talk about it like a product, if you are going to support it without too much grey hair and get the scale effects, you also have to build it like a product. This has practical consequences all the way down to the details of the technical architecture and the underlying data models.

Regarding user interfaces there is also a need to be clear on what is part of the product and what is customer specific – and find a clear cut way to manage that. If you throw hard coded texts or data fields specific to the first customer around the user interface, it is not a product. Also, if you have to fix the same error for all customers, it can be an indicator of a flawed architecture or structure.

In most cases you won't have partners selling your product from day 1, thus you need to think about supporting (and possibly hosting) the product professionally. Then it matters a lot that it is built in a way that grows maintenance work in a sub-linear way with the number of customers[3].

Again, on this point I did not do to well at the first attempt. When trying to generalize this now in 2010 for the new version, some rework had to be done to make possible installation for the next customer smoother. I also made what I think was a smart move by trying to provide easy hosting, or letting the customer forget about hosting all together, through possible single sign-on with their existing solutions. I also made connecting to enterprise systems easier by exploring a module that will run PHP (in which the original system was built) inside the Java application server Resin, called Quercus.

Marketing for the product

Many entrepreneurs seem to almost lose interest in a product once it is approaching something that looks (remotely!) like production quality. Then it is on to the next project, although they might claim they are both "products". Well, it might be fun (I think so!), but if doing so one should be honest enough to simply call them projects, not fool oneself by calling them products. That being said, it is nothing wrong with trying out several product ideas – if you can make even one of them fly, to me that is just plain fantastic – but remember that not all projects need to become products.

A product should have a name. Try to find a good one. Create some, if very simple, marketing material and try to get it spread. These days many channels are available, but it is still much easier said than done to create the amount of buzz needed to reach just those potential customers.

If you really believe in the product and it has a great potential, here is the area you are most likely to need professional outside help. It can be from partners or external investors (VCs). Marketing and internationalization can be frightening expensive and for a software company founder to be excellent at it is probably the exception rather than the rule.

If your product is consumer oriented, the Freemium model has gotten quite a bit of attention lately (some would say too much, it is certainly not a one-size-fits-all silver bullet). Andreas Göldi covered some properties on when the Freemium model can be successful in a blog post in 2009, it comes highly recommended. If the free version is great, maybe the word of mouth can help your marketing? In addition to pure guerilla tactics including wise use of social media[4], some forms of targeted advertising might be feasible. Very targeted search word advertising and doing talks and/or stands at conferences or conventions might be worth exploring. I am not the best example of this (again, look at the 7 years of a great system still with that single customer!), so I am sure you can come up with more creative ways of doing this than I can!

How did I do on this point? I simply didn't. But I have settled for a name in the process of upgrading the solution this year. RightCruit.com is going to be the proud new name of the product. And I have now written this blog post (and not least done the analytical work both leading up to it and starting doing the operational work coming out of it). I have to admit that my blog with very limited traffic is not ideal, but it is a starting point.

In addition, and more important, I have good ambassadors in my customers that have used the system since 2003. I still think the most likely way of doing a sale is through them and their international contacts.

So by posting this I have made public the goal of making the first international sale for RightCruit. If it happens, have no doubt there will be a follow up post or comment on this page. In the short term, I will use the comments field here to give a quick update as I progress in trying to make it right using my own medicine. The next month or so, I intended to record a small presentation video and maybe buy some Adwords ads for those to see if that can generate any qualified leads.

I welcome comments, both on the theoretical argument and on what I am still doing terribly wrong with my practical attempt at selling RightCruit to new customers. At least can't be the name? ;-) I thought it was utterly clever with a word play on “recruit” and good meaning to it as well...

[1] - ISV = Independent Software Vendor. When using the term "micro ISV" I generally mean companies with only a handful of employees, for most of the time in the specific example it was actually less than one FTE. But some of the argument above is valid also for somewhat larger companies struggling with the tension between customer projects and product development.

[2] - If I were to argue back I could mention that I have been involved in some successes as well :-)

[3] - This might sound easy. It is not. I have seen examples of the time spent being almost exponential and when having the first small handful of customers, the coordination and attempt to do projects for customers along with product development almost stalled progress completely for a while.

[4] – I don’t claim to be the biggest expert on social media usage. I do have opinions, however. Without attempting to lay out rules and certainly not a social media strategy here, I would say that adding some value to a discussion or offering something of value (I hope this blog over time shows some of how I think) is always a good idea. And always, always, always be honest about who you are and who you represent.

Also, thinking about real life parallels can be useful (in a party, would you go “hey, this guy that none of you know just said that something I wrote was great and I will repeat that without any other comment to all of you”?), even if it is not always straightforward to find a relevant analogy.

Internet as an application platform - even for HD movie editing?

I have read a lot and also written a bit about web based applications of different sorts and how business models in the software industry are changing. The move to Internet-based applications has been promised for maybe too long, but from my point of view it seems to be going more mainstream lately - which for instance a front page of the Economist in October 2009 indicated.

In addition to moving more mainstream in terms of users, I think web based applications are wideing the scope also in terms of types of applications that move online. The last weeks and months I have been lucky enough to be involved in a project taking this somewhat to the extreme - trying to do HD video editing online in the browser.

With the launch of Flash Player 10.1, Adobe brings hardware accelerated mp4 support to browsers on several operating systems - and based on technology from the Creaza movie editor a preview of a upcoming version of online video editing with HD video support has been made in record time by a dedicated team of developers in Norway and Romania. You can do a test drive yourself, by getting the new flash plugin and following this link to the online video editing application preview. Make sure to use the commenting function to tell us what you think.

The technology preview version does not have a save or export functionality, but you can render the movies live and watch them to test the quality. In the screenshot below I am changing a text about 10 seconds into the example movie. You can also add transitions and effects, and to be honest I was amazed how the results look. You can have multiple layers of effects, sound and video (including multiple videos playing in different parts at the same time) and it all renders on-the-fly.

Full disclosure: I am a member of the board at Inspera, who owns a majority stake in Creaza AS and has the IPR to much of the technology used in the preview application.

Fast mobile and fun TV...

...some even quicker observations on keynote of Google IO day 2.

In short, the new and faster version of Google´s OS for mobile devices, Android version 2.2 codenamed Froyo, was launched as expected. There was some picking at Apple with references to their famous "1984" superbowl commercial calling their approach Draconian, push APIs were launched "not to address basic shortcomings in the operating system of the device, such as lack of multitasking", demonstrating tethering in Android with the words "now let´s turn to a device that doesn´t have connectivity, how about that iPad?", etc.

The Android momentum is high, with 100 000 activations per day. The Flash plugin (10.1 public beta) was announced as expected. I am looking forward to see how it performs, as pointed out yesterday Flash on the mobile has yet to deliver (when I supervised a MSc-student in 2005 doing context-based mobile app that it was supposed to be half year away from being great, which I think it has been since...). Hopefully this will be it!

Google TV was also launched, not quite as pre-announced as the Android Froyo, but not unexpected either. Personally I am more interested in "Chrome OS for TV" - to have a lightweight connected OS with browser (for public screens etc.) in TVs than the PVRish and EPG aspects that it was focused on in the announcement, but I guess it can be used for both.

It will be interesting to see if Google will be the ones to get voice control right. It has been tried (several times) before, including getting similar wow-demo-effects to the ones we saw in the keynote working. With all the data to improve their algorithms, they might just be.

Oh and to leave you with a maybe non-exciting note that I forgot yesterday: App Engine are getting SLAs and standard SQL databases, which might in fact be of the more important announcements for CIOs considering running apps in Google´s cloud.

Quick reflections on today's Google IO keynote announcements

In today's keynote at the Google IO conference, a pretty impressive list of announcements was made official. [And tomorrow everyone is keen to see news about Android, I guess?] I want to quickly comment on two or three that I find particularly interesting.

Web video: Opensourcing the VP8 video codec

This was expected to happen at some point, after Google acquired On2. The list of companies supporting the new format is interesting and Microsoft has seemed to confirm that IE9 will support it.

This might put H264 on death row as a candidate for the video format for web and if adoption goes as Google hopes, it will pose Apple with an interesting dilemma. This will indeed be the case if the flash player will be among the first environments to deliver a good user experience for WebM. [Another sidenote: Again, it will be interesting to see tomorrow if Flash on Android is finally approaching what Macromedia and later Adobe has been preaching about Flash Mobile for more than five years... If it is, Apple might get push from their user base, me included, to get access to cool apps on their iPhones and iPads.]

Web applications part 1: VMware teams up with Google trying to deliver "the cloud OS"

Tim O'Reilly wrote a great post on the development and State of the Internet Operating System a few weeks ago. VMware secured a deal with Salesforce recently to allow developers use their Spring platform there. Today it was announced that it will also be readily available on Google App Engine and also integrates more easily with the Google web toolkit.

VMware's Paul Maritz was even quite explicit about the goal, saying something along the lines of: "If the cloud is the new hardware, you can see this as the operating system." That could mean easier cloud-to-cloud (private or public) interoperability for both ISVs and companies, which can only be good. Of course, there are other main players in this space. One should not underestimate good old Microsoft - they certainly have some experience building successful platforms that third party developers deliver applications for...

Web applications part 2: Browser capabilities and a new webapp store

There was also a few cool demos of what can be done in plain browser based applications without plugins today (so called HTML5). The rapid development in this area of course also accelerates the movement of applications to the cloud. As far as I noticed, there weren't any specifics on Chrome OS [Tomorrow morning?], but it makes more and more sense to have a OS totally focused on web for every day that passes.

It remains to be seen if the Chrome application store will be a success, but it must probably be viewed in the scope of the Chrome OS to be judged fairly. It might give an option for independent developers and small companies to monetize on their products, much like Apple has championed for mobile apps.

It is very interesting times. In my company, I am doing product development in the mobile/augmented reality space and I am amazed with all the libraries, frameworks and options available to a startup these days - it is a huge difference from only a decade ago. Google is in my opinion one of the companies that seems to get the balance between open and proprietary innovation quite right, so kudos to them for helping to drive this exciting progress.

Startup idea generator

I stumbled across the startup idea generator today. It tweets a brilliant (?) new business idea every five seconds or so. Very much buzzword compliant. Content asymptotic towards zero, but that is not always a problem, is it? Idea 1 025 431 (yep, over a million and counting) was for instance "Enable Twitter-connected technologies to solve the problem of crowdsourced communities".

Come to think of it, some of my e-business students will probably argue that the lingo of business is just like this... I'll share one piece of anonymous feedback from their survey:

• Worst thing about the subject: That we have to have it!
• Best thing about the subject: That we are done with it!

Oh, I like the joy of teaching! :-) Seriously, I think I do - and for the record: There were some encouraging pieces of feedback in there as well.

Old, grumpy and agile – the ideal combination?

This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?

Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?

I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version[1]. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.

It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.

My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days"[2] (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").

[1] - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.

But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.

[2] - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.

Portfolio planning: Create storms, not forms

I said some time ago that strategic portfolio management goes beyond what is typically achieved in a project management office (in my 8th "brief tip" for project management). My best attempt at formulating this in a rememberable way comes here: Create storms, rather than forms.

I think better value from a project portfolio can come from creating storms - honest discussions between people that typically own the day-to-day business operations that the projects are about to change - than using very detailed sign off procedures and authorizations. Rather than requiring many people to sign off projects of a certain size, have them take part in the regular meeting that is the only place such projects can be authorized for initiation.

An important outcome of such meetings is which projects not to run and also to create visibility of the most important projects for senior management. Ask top management: "What are your current major running projects and which are the top priority ones?" Getting any kind of stuttering as a response is a big red warning light.

If you just take the form-based "PMO coordination" approach, there is a danger that all projects will just be administred - not prioritized. One useful way of visualizing projects can be as a radar, with distance showing the expected end date and the size of the dots showing the size of the project, possibly with sectors for business units. Over time, some rules of thumbs might evolve about how many major project the organization is able to digest, which types of projects require the most coordination across business units, etc.

A weak point of the method of de-facto giving the line management power to decide which projects to run, is that often only the needs of current customers will be heard. This is similar to Christensen's Innovators Dilemma. You may make your self obsolete through many incremental innovations of the status quo, that by them self make sense - but fail to capture big shifts. This is really a separate discussion, but one solution might be to separate early stage R&D projects both organizationally and from the project prioritization process.

A final word, maybe to avoid any unintended storms (!): Forms can also be useful. The most obvious example I can think of is that a suitable template, or form if you will, can contribute to getting the project owner to think in business case terms when arguing why it is a good idea to run just their project... And PMOs can of course be useful facilitators for the decision process. Also, I am not suggesting to get rid of documentation or preparation for the meetings, but I still think that the main point is valid: Prefer storms over forms, decisions over documentation, and prioritization over administration.