Everyone loves a wish list?

Sometimes the only ones enthusiastic about methodology sit on the vendor side. What do you do if you get that 1000-yards-stare back when you mention "agile" or even try selling the idea of using "Scrum"? For sure you don't start talking in detail about building product backlogs and items making it into a future sprint backlog!

What I have found may work in such settings, though, is introducing the concept of a wish list and some very simple rules to govern it. YMMV, of course, but something along the lines of:

- Every suggestion or idea, no matter how great, goes into the wish list right away
- At certain points the wish list is reviewed and the highest value items are scoped for delivery

Of course there is the risk of being perceived as a stubborn bastard, but maintaining such a wish list can help you structure a "backlogish" approach even where no-one wants to hear about it and it can be good for business (on both sides, actually -- as it makes priorities clear) and often separates what is included from what is paid for. Give it a try.

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.

Alignment of project dimensions: A balancing act

When writing the promised piece on agile methods and management information, I found that I wanted to present some thoughts about alignment of different dimensions of projects to avoid having to make the other article longer than necessary. Thus this post first.

I have found it useful to think about the alignment of some project dimensions before signing the contract and kicking off the project. The dimensions I will consider here are contractual terms (pricing), collaboration and strength of relationship, and the software development method to be used. Your selection of variables may vary, but I insist that trying to take such a bird’s eye view is useful when assessing the risk of project failure.

Below (click to see it in full size) is four actual projects placed in these dimensions. They are all software development projects, but differ somewhat in terms of complexity of integrations, amount of front end vs. back end programming, etc. as well as size. So they are by no means a perfect academic sample set, but they are projects that I know because I have worked and lived them.

As you might guess from the topic header, my hypothesis is that some combinations of the dimensions fit better together than others. Which of the projects above would you be afraid of taking on as project manager or team member? Which did you think get into trouble?

In retrospect, one of the possible “doomed to fail” projects actually didn’t (number 4). I try to cover the reason why in my next post. The other prime suspect, number 3, did actually fail spectacularly in terms of profitability. In fact, I took over this project midway (that is when just about 110% of the budget was used…) and even without drawing out the diagrams, the missing alignment was striking. However, the end product developed was to the customer’s satisfaction and new projects will be conducted that hopefully will be better business as well.

Another way of viewing the above dimensions could be in a 2x2 matrix (I am currently a consultant, after all!). Below I have tried to do that, with development method on the vertical axis and contract/pricing horizontally. The color (blue=”colder” customer/supplier relationship, red=strong partnership) of the dot indicates the form of collaboration, to avoid fiddling with three dimensions.

In danger of over-simplifying, I’d like to make the following remarks about these quadrants:

• The bottom left quadrant is just fine, although maybe a little bit old-fashioned. You could consider discussing with the client if a more flexible approach could be more suitable (moving up and right in the chart) and delivering more value.
• You should be extremely careful if you are in the upper left quadrant. You must then be absolutely sure that you and your client have found a good way to manage scope adjustments. I would also never conduct a project in this space if it is not a strong relationship with the client, i.e. a "red dot" above. Without these two in place, this is the “doomed to fail”-quadrant.
• The upper right quadrant if the place you probably want to be operating most of the time with agile methods. Especially with a strong relationship with your client (red dot). Be sure to manage expectations both upfront and at every increment, though. Often it doesn’t help to have the legal contract on your side if your most important client is not close to satisfied after all funds are burnt doing iterative improvements.
• The lower right quadrant is probably just fine, but it indicates that although there is client/supplier trust, indicated by the choice of time&material pricing, there is actually no belief in the gains promised by agile development methods. Thus, one gets the formal overhead without really needing it to handle pricing and legal issues. But formal specifications can absolutely be a way to handle the expectations management mentioned in the previous bullet point. Some target price regimes might fall into this quadrant, but not all (for example, project 4 was a target price regime).

Another related way of looking at this, is through the classical project management pyramid – TRQ, time, resources and quality/scope. The basic idea is that you cannot change one without adjusting the other accordingly. So if you fixate time and cost, certainly the details of scope can be a variable throughout the project. This view fits quite nicely with what DSDM preaches and on the development level this is the way I find working with Scrum-like approaches most fruitful.

Of course, my comments about the sample projects at this point are with the power of perfect hindsight. But let’s look again at project number 3, where we obviously tried to do flexible development with slim specifications with a completely new customer (collaboration form is not always a function of length of the relationship, but the two are usually strongly correlated and in this case it was a new customer) at a fixed price as if it was a classical waterfall approach we were using. Was it very likely to succeed if judged upfront? I think not.

Please do not read my comments only as a way for vendors to maximize their profits and minimize their risks. The assessments of the project dimensions should rather be discussed openly with the client before kicking off the project. It is after really understanding your customer’s need you will be able to make the best trade-offs for that particular case. Project management methods, and legal contracts for that matter, has large elements of tailoring after all.

There is a lot of fuzz about the specifics of each agile method proposed. Maybe too much. To me, agile software development is actually just as much about mindset and approach as it is about specific methods. And I do think that one should make sure that the mindset and the more formal frameworks (contract, form of collaboration and actual development methods being the three sampled here) match and discuss this upfront between customer and supplier.

In an earlier draft, I considered using project size as one of the variables. This could easily have been included for example through the size of the dots in the diagram notation. I considered about 10 projects I had managed myself and a few others that I know fairly well and I did not really see size (ranging from a few hundred to many thousand hours) being as important as the variables I have proposed above when considering if agile methods will be suited. But you might beg to differ? Let me know what you think by leaving any comments you have below. I hope to learn a lot from them.