27 February 2008
Naill Kennedy has an excellent post about sniffing browser history to improve the user experience on your site.
Naill demonstrates how to use CSS and javascript to detect if certain pages have been recently viewed by the user. Based on this, you can infer some preferences of the user and target them with personalised advertising/cross-selling.
For example, if your desired path for your prospects is:
teaser -> website -> benefits -> signup -> demo -> purchase
then when someone visited your website, you could apply rules such as:
- If the visitor is new, then promote the benefits
- If the visitor has seen our benefits, then promote the signup
- If the visitor has seen our signup, but not our demo, then promote the demo
- If the visitor has seen our demo, then promote …
If every web-page (and every email you send) contained a personalised call-to-action, then much higher would your conversion rates be?
Of course, you can block or delete your browser history, but google analytics and companies like Calcium Software will soon be providing this same information and I don’t think this is a bad thing.
When you look at content publishing, our attitudes used to be “I’ll read what the publisher publishes”. Today, with content being so widely available (and with nearly everyone being a publisher), our attitudes are “I’ll read what I want to read”.
We’re on the verge of complete information overload, so our attitudes will soon change to “the publisher knows best what I want to read”. This assumes that the publisher, using a combination of my preferences and their expert domain knowledge, can best decide what content I want to read .
This also means that the publisher, using a combination of my preferences and their expert domain knowledge, can best decide what the next call-to-action is for me to guide me toward a purchase.
Leave a Comment » | 
Marketing, Technology | 
Permalink
Posted by Andrew
26 February 2008
Grant Margison from Information Leadership spoke at a Microsoft Architect session this month in Wellington and made a really good point.
Building software is not about projects that end with deployment, but is about getting new features into orbit.
In other words, the goal is not to deploy, but to add value for users.
This is what ‘release early, release often’ is about. Its not until a feature is deployed and in use that the lifecycle of usage -> improved usability -> improved usefulness -> higher usage -> … begins.
Leave a Comment » | Software, Strategy | Permalink
Posted by Andrew
17 February 2008
I’m a big fan of fair valuation and pricing software development is a good example of why.
Its easy for small fixed price software projects to turn into lose-lose situations, usually because they are too cheap. The customer gets what they paid for and the developer starts to lose money fast as the project drags on. The customer expects a perfectly working system for the agreed price and the developer either carries on losing money (but doing a poorer job) or calls it scope creep and delivers an incomplete project.
Software projects are hard to estimate and therefore price, but often this makes no difference to the price of the project. The problem is often that a market valuation of the project is used, instead of a fair valuation.
The market price is what the customer is prepared to pay and what the developers are prepared to deliver for, but it can be well under (or above sometimes) the fair price and can have nothing to do with the project being under-spec’ed or under-estimated.
The fair price of a project means charging a fair and profitable amount for the work to be done/delivered. Estimating the development required for a project is easy compared to estimating the other work to be done, but for delivering a simple software project, a good rule of thumb is that the project will be 3 times the size of the development work.
The market price of a project can be significantly lower than the fair price for a few reasons:
- The fair price makes the project un-viable, so the customer’s cost/benefit dictates the price they are willing to pay
- The customer has limited cash or budget and the developer wants the work
- Competition are prepared to deliver the project for lower than the fair price
Unfortunately, you can’t just quote the fair price, because if this is significantly above the market price, then you’ll lose the project.
One way to bridge the difference between market and fair price is to find a pricing model that fits the project. Software is very rarely a single deliverable, so the pricing shouldn’t be either. Once you know the fair price, you need to communicate this to the customer, so they understand the full scope of the project before they enter it. Then, you need to understand what the market value is (from the customer’s perspective is best) and structure the project so that the cost/benefit stacks up for the customer after every deliverable.
Leave a Comment » | Business, Software | Permalink
Posted by Andrew
