Leaner than agile: Better products more quickly and cheaply

This post advocates the use of a ‘lean’ software development process for web based products and services. I outline why those involved in product marketing and software development should consider using a lean approach in their organisation. Where I use the word ‘product’ you can happily substitute ‘service’ if it suits you better.

I caveat the above with “web based products and services” because the web offers fantastic opportunities to measure how the customer values products and features. Value can be measured in various ways, for example measuring usage and goal attainment, running split tests and getting feedback. One or more of these feedback mechanisms are essential to the lean approach.

So what do we mean by a ‘lean’ approach? The term ‘lean’ is borrowed from lean manufacturing processes (such as the Toyota Production System). Wikipedia defines Lean Manufacturing:

Lean manufacturing or lean production, often simply, “Lean,” is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination

For software development, my approach to lean is to:

Take the smallest possible step that can test an assumption or idea; move quickly in small increments and learn from each step we make, minimize work in progresses and quickly learn what our users value.

This enables us to quickly determine what adds value whilst wasting less development time on features which do not add value. This usually means minimize work in progress, releasing early and often, measure and test value to the user, then iterate – quickly. Here’s the Wikipedia entry for Lean Software Development for other’s take and perspective.

Values and processes

Before we go into this in depth, I’m not saying one software development process is universally better than another, every business is different and puts a different value on different things. The perfect process for a particular company can’t be found in a text book or blog post, to a certain extent it requires some trial and error to match the company’s values. A company’s values may change over time as a company grows. Use the right tool for the job at hand.

When I use the word ‘values’ I’m not talking about some airy fairy spiritual thing. Some business have customers that value stability and no change (or very slow change) in the product offering. Some services should be straightforward and just work – always, no exceptions, ever. Other businesses will make amazing gains from adapting their products quickly to delight their customers and gain business from their competitors. Startups usually fall into the later category (particularly early stage startups). For them there is immense value in their ability to quickly put new features and products out until they find the right markets and products/features for those markets.

For me one of the primary duties of the product development team is to maximise return on investment or put in less scary language their effectiveness. In the context of product development, I define effectiveness as:

Effectiveness = value added / cost of adding that value

Our aim is to increase the value of our product from our users’ perspective (hopefully also leading to more users) at a reasonable cost. You can think of cost as money or time or a combination of both – the gist is the same.

Adding value requires discovery of what adds value

To increase value, it is essential that we find which features users use and which features either help them or encourage them to complete goals. This is an investigative process, a search that involves lots of trial, measurement, refinement, retrial and so on. For a startup product development is a race, you want your product to be valued by users as quickly as possible. Learning from measurement, testing and feedback is *key* to the lean approach.

Discovering which features users really value or how features ought to work is rarely as simple as *just* asking them. Ask a sociologist, often people don’t do what they think and say they do. Over the years I’ve done a fair bit of split testing and testing by observing users complete test tasks. In both cases we’d frequently be surprised at which features users did and which they did not use. Do gather and encourage verbal/written feedback from your users but use this to inspire investigation, as a catalyst and not as sufficient evidence in itself.

The quick cycle of feedback then iterate again is essential here. With the non-lean approach you might get lucky, hit upon something and add a dramatic amount of value but then again you might not. The same can be said for the lean approach but the cost of discovering this is lower and you can learn and try again quickly. The non-lean approach will probably lead to increased value. However, the non-lean approach probably won’t maximise value or do so quickly and at minimal cost.

Minimize Work-in-progress and avoid queue bloat

Minimizing work-in-progress is important to improve effectiveness by reducing the amount of work which does not add value. For software, by work-in-progress I don’t mean just what the developers are working on at that particular moment, I also include anything they have recently finished which has not yet been released.

What happens when people have to wait for the software development team to get their new features developed and released? Let’s define ‘lag’ as the time from requesting some work to release of that work. Let’s consider how high lag leads to bloat and waste..

Often customers of software teams are like very hungry people waiting for their first meal for a day or two. Once they get served, they’re gonna eat. They’ll eat plenty more than they really need and become bloated. So, using the royal ‘I’… My development slot doesn’t come up another 6 weeks and even then it won’t get release for say another 6 weeks. Any new features or improvements I want won’t get released for another 12 weeks, so I’m going to stuff it with as much as I can. This probably means I’ll ask for a larger slot of development time than I really need, making others wait even longer, increasing the general hunger and leading to more bloat. The queue of work starts to grow with work that is not really necessary.

High lag puts people off trying alternatives. If you don’t try alternatives then you’re not searching for the best solution, not innovating. They’ll polish their new baby in the hope that it’ll succeed in what may be its one shot at success (at least for fairly long time).

Predictability vs Effectiveness

Organisations often put too much emphasis on predictability to the detriment of effectiveness (Value added / Cost of adding that value). They like the certainty that work will begin on features A, B, C, X, Y and Z in 6 weeks time and 6 weeks after that these features will be released. Hit those timescales with those features and nobody can have the finger of blame pointed at them. Except of course the people who are responsible for growing the business fast and before they run out of money, or get beat to it by a competitor.

It’s not just bloat, there’s another problem with 6 week plus release cycles. People become frustrated with the lack of progress and blame the busy development team. In their hunger, people start attempting to jump the queue. Jumping the queue leads to ill feeling and bad decisions. Some may argue that the solution is just to ban queue jumping, to staunchly refuse it. Resisting queue jumping is just treating a symptom rather than addressing a cause – a need. I think queue jumping is inevitable in a business that has customers and competitors and is measuring, testing, listening and responding to the world around them. Priorities change as we learn more about things, it’s a fact of life.

Organising Lean

So treating the cause rather than the symptom. If our approach is to learn from the customer by trialing features and ditching or iteratively improving them based on measurement, tests or feedback, then we’re learning. If we’re learning then our current priorities will change as we learn more. If our priorities change, then it’s important to be adaptive. The key to being adaptive is low lag, that is being responsive and minimising work in progress – a lean approach.

With lean we are searching for how to add value. It’s a search so by definition we don’t know everything up front before we begin. A common question about lean processes is what does a project look like and how is it organised. I like to define projects in terms of their goals rather than their steps. So for example, I might initially define a project as the goal, “Increase the percentage of forum users providing answers to other users’ questions”, then working with the team, we’d think about ways of doing this and how to measure and test them, all the time looking to keep the steps as small as possible.

You will likely have multiple projects going at the same time, depending upon the size of your team and how long it takes to collect sufficient data or other feedback. Switching between each project as things are learnt and next steps are determined. I’ve found the best way to organise this is as a list or work ‘pipeline’ with the following sections:

Backlog => (Pending => In progress => Ready) => Released

Some people call this a Kanban chart or board and use an actual board with post-its. Personally, I prefer a shared document or dedicated agile project tracking system such as Pivotal Tracker

New work requests are added to the backlog, which is kept in priority order. Like an agile process, before the next iteration begins, the decision makers should review the backlog and determine the highest priority items which will progress into the pending section at the start of the next iteration.

The sections enclosed in parentheses – Pending, In Progress and Ready are the work-in-progress. We minimize this by releasing early an often.


So in summary, the aim of lean software development is to improve effectiveness (return on investment), adding maximum value through measurement and feedback, and reducing or eliminating work on features which do not add value.

  • Always take the smallest possible step necessary to determine if we’re adding value

    Keep asking the question, is this really the minimum step in better understanding if this feature will be valued by users?

  • Learn. Measurement and feedback are king

    Get feedback, that is: usage data, split testing and/or testing with users.

  • Move quickly

    Minimise work in progress and release often.

  • Iterate and investigate. Innovation is a search, don’t be afraid

    The quicker you move the more you can try, the more you try the more likely you are to get a result. Remember you are measuring and getting feedback so you’ll know if you make things worse. As you’re moving quickly, you can quickly put things right quickly too.

  • Be responsive

    If you are not responsive, fear will take hold and bloat will gradually kill effectiveness (value/cost).

Website performance: Concurrency and its evil brother latency

There was a lot of buzz about Ruby On Rails a few years ago, many would say there still is. I find Rails focus on productivity very attractive, so a few years ago, for web work, I shifted over from Java to Rails. One significant difference between the two environments is how concurrent requests are handled; in particular the potential impact of high latency requests. This post isn’t about Java vs Ruby. However, the differences and similarities between their deployments did get me thinking about the impact of latency and concurrency on web performance and wondering about other approaches such as the event based approach of Node.js.

I use the term “high latency” to mean requests where the response doesn’t complete in under a couple of seconds, though arguably a couple of seconds is not particularly quick.

In our Java web systems we had lots of threads available. We didn’t tend to worry all that much about the odd high latency request as there were always plenty of other threads to serve other requests. In reality though, that was perhaps a little naive. In many applications there’s plenty of opportunity for a thread to consume and hold resources needed by threads e.g. db connections.

I shifted to using Ruby on Rails a few years ago now. Moving to Ruby on Rails was an eye opener for lots of positive reasons but (at the time) I was surprised to discover that Ruby servers are effectively single-threaded (there is threading in the de facto ruby 1.8 implementation (Matz MRI) but it’s cooperative rather than pre-emptive switching). The threading model effectively means that processes are used for concurrency – one request per process. On many systems (but by no means all) spawning processes can be slow, also processes consume memory – even if just the web stack when idle. As such there’s a relatively low limit to how many Ruby processes can co-exist vs the number of threads available to a similar Java web system running on the same hardware.

The one request per process model tends to make me much more paranoid about high latency requests than in my Java days. However, looking back I wonder if our old Java systems would have benefited from greater attention to eliminating high latency requests. Server crashes tend to creep up on you and often it’s not obvious what the one thing that’s causing the crashes is because it’s not one thing but a gradual degradation in responsiveness, that eventually gets to a point at which it tips into a server crash/stall. I rather grandly think of this as the “tipping point of crashes”.

You see a similar effect on busy motorways (highways, autobahns..). Think of the lanes as being like the processes available to service requests from browsers concurrently. If there is a slow car in one lane, the lane starts backing up and vehicles start switching to the other lanes. Capacity is reduced and the likelihood of a slow car entering one of the other lanes increases. The problem effectively cascades until suddenly everything stops. Once the congestion has passed and you’ve travelled a few miles more you may wonder what caused the problem in the first place, there’ll be no obvious cause.

So how to solve this.. Well continuing the motorway analogy, more lanes can obviously help. With more lanes you’re reducing the chance of a slow car affecting others. With additional lanes you may have moved the tipping point further out, a single slow car is less disruptive to others. However, the problem is still slow cars. Take the slow car off the road and the motorway copes with no problems. Here lies the danger, whilst lanes help, don’t let more lanes fool you into ignoring slow cars.

The Node.js web framework is interesting because it doesn’t follow the common model of process/thread per connection. Node.js provides an asynchronous framework, which put in very plain language means the thread doesn’t sit around waiting for databases, filesystems, messaging systems etc to reply to requests, instead it registers a callback to be called when the database/filesystem etc responds, the thread proceeds onto processing the next request.

Programming a system like this is a bit of a paradigm shift for most web developers, it is more like programming a GUI. However, decoupling concurrent processing of requests from the number of processes/threads should result in lower memory footprints and fewer problems with occasional high latency requests blocking out new requests and causing congestion problems.

I’m planning to have a go with Node.js pretty soon so it’ll probably form the basis of a future post here. In the meantime, here’s a good example explaining node.js.

So my tip: no matter what the system, always pay attention to high latency requests particularly if you are having occasional “mysterious” crashes.

Speed, Conversion & SEO: for Google speed is a factor

Google have officially announced that page speed is now a factor used to determine search ranking. You can read Google’s announcement on their Official Webmaster Central blog.

There’s some interesting details in Google’s post. As we’ve mentioned before on this blog, speed is a significant factor in conversion optimisation. Google want more money to be spent online. Money spent on online advertising would no doubt also increase.

So making your site faster is now very likely to improve conversion and a site’s position in Google’s organic search results too (page speed has been a factor in Adword’s Quality Score for some time now).


Page speed & conversion: Mozilla increase Firefox downloads 15%

I’ve previously written about the importance of page speed to optimizing conversion. Mozilla achieved a 15% increase in downloads of Firefox by speeding up their download page.

The guys at Mozilla noticed the page for downloading Firefox was slow. They worked out how to speed the page up. Split (A/B) tested the new fast page vs the old slow page and achieved a 15% conversion increase – in their case 15% increase in downloads of Firefox which could amount to an additional 60 million downloads per year.

Here’s their concise post on how they improved conversion through improved speed.

Tip for email Marketeers – don’t keep changing your email address

Ever noticed how email clients like gmail don’t (by default) load images in emails? Most email marketing systems use an embedded image to track who opens their emails. To protect your privacy and thwart spammers discovering which email addresses are valid and active, gmail (and many others) don’t load images unless you tell them to.

You may have noticed a link for loading images, and a link for always loading images in emails from sender Y. I get quite a few marketing emails, ones I’m interested in from companies I’ve previously made purchases with. I’m continually amazed at how often I have to click the ‘always allow images from Y’ link because someone has yet again changed the email address the marketing email comes from.

So nice email marketing people, please stop changing your send address. Do this for me, so I don’t have to keep clicking on a link to see your image laden messages. Do this for yourself so you can better track who reads your emails. You do use stats of your email marketing funnel to improve your emails’ effectiveness don’t you?! There’s an idea for a future post.

8 ideas for understanding product / market fit using the web

Here are 8 ideas for understanding product / market fit using the web. Please add thoughts and other ideas as comments.

1. Run a news aggregator

Run a site which aggregates interesting news and articles related to your product area, presenting a headline / brief summary and then linking out to the original content. Categorise the articles and tag them. Keep a tally of which tags are used most often and observe clickthroughs, keeping a tally of clicks by tag.

A good source of content is twitter and it is relatively easy to do. Create a twitter list of people that post news and articles relevant to your area. Bingo!

This is more likely a qualitative aid than a hard quantitive technique, it would take quite some time and effort to make such analysis statistically significant and it is important to understand how the content you are posting may bias clickthroughs. However, if you do succeed in building an audience or community, that in itself is valuable.

2. Run a forum or question/answer site

An interesting example of this is Oracle Overflow. Whilst the aim may be to attract and help a community of Oracle users, this is potentially a gold mine of information on problems Oracle users encounter which in turn could spawn many ideas for products and tools. 

3. Survey, send out short questionnaires – perhaps with a prize draw

Ask customers or potential customers to fill out a questionnaire asking about their requirements and/or experiences. My advice would be to use a mixture of multiple choice and free text questions. Multiple choice questions have the advantage of being relatively quick to answer – many people don’t like writing. As multiple choice questions have a closed set of answers they are easier to process and analyse. However, sometimes you want to get a feel for problems people are having or their feelings towards your product so it can be useful to mix in some free text questions.

Achieving a good level of participation in your survey is very important. To encourage participation, keep your questionnaire relatively short and tell the user upfront how many questions and/or how much time it will likely take to complete. Consider giving them an incentive to complete your questionnaire. This doesn’t necessarily have to be something very big and expensive. I’ve successfully run a questionnaire offering a £50 SatNav as a prize and got over 500 replies. Obviously, the size of your response will be affected by the size of your audience.

Here’s an excellent post on “What my Survey Taught Me” .

4. Encourage questions and enquiries – make sure you follow up though

If you have the resources to answer questions then why not encourage visitors to your website to ask questions about your product / service? Along with their question make sure you automatically capture what product/content they are looking at and any options they may have already selected i.e. a hotel room in Amsterdam, April 25th. The product data and options are important because it may help you to categorize your data when you analyze it.

When reading through peoples’ questions, make sure you tag them into categories for later analysis – for example, if you sell radios you may find 30% of questions are asking whether the radio has a USB port for MP3 upload, if you’ve tagged these questions with for example ‘usb’ and ‘mp3′ this should be easier to identify and quantify.

Once you’ve collected a large set of questions you may be able to improve the product. If you can’t improve the product, perhaps you can improve sales by changing your sales pitch, or including an FAQ.

5. Gather reviews, use post purchase or enquiry questionnaires

Gather data and content about people’s satisfaction and experiences with you product and purchasing / enquiry processes. As before, make the questionnaires relatively short, use multiple-choice questions possibly with a few free text questions mixed in.

Design your questionnaire so you can categorize replies and if necessary take further action, for example: happy, unhappy, needs follow up. One way of doing this is to explicitly ask them if they are (a) very happy, (b) happy, or (c) unhappy.

If would like to use content from these questionnaires on your website, encourage advocacy by asking a question such as, “What would you say to a friend to encourage them to buy?”. You probably want to avoid using their answer to this question if they have earlier selected option (c) unhappy!

6. Design your site to self segment

Enable the user to self-segment by providing section or filter links.

For example, if you are selling televisions, you probably already provide filters to limit the list of available products by type, size and other features. Capture this information and use it to inform the selection of products you offer such that it better matches the demand your marketing is creating.

If your site is about operating an email server, you no doubt have sections about different aspects of operating the service, for example: backup, setup, spam, performance etc.. By getting people to self segment you can get a idea for where the biggest problems and pain points lie.

The following may be  a little controversial. If you use it, I’d recommend you use it with care. Consider providing links to products or content you don’t currently have but are considering. Don’t over do this though, people hate following links then being disappointed. Don’t do this is you cannot or do not intend to fulfill the need very soon. As a consolation, offer similar alternative products or related articles.

7. Look at funnel drop outs

Using Google Analytics or a similar tool, set up goal tracking e.g. product purchase, sign up for newsletter, post question, make enquiry. How to setup goals and funnels in Google Analytics.

Once you have goals and funnels set up and have a few weeks of data (depending upon how much traffic your site gets). Take a look at Google Analytics’ Goals > Funnel Visualisation. You’ll see a vertical list of funnels showing progress through each step. Take a good look at the right hand column, it shows where people who abandon the funnel go to. Any patterns in funnel abandonment will likely be useful for web design and conversion optimisation activities but they may also point to product opportunities to or problems.

For example, if you have a site which sells flights, you may have a banner or link to pre-book car parking at the airport. I wouldn’t advise adding such distractions to your checkout process, but if you already have them they may give clues as to related items your customers are looking for, or concerns they have with your product or process. In this example, perhaps flight and car parking could be offered as a single package/purchase.

8. AB test

This requires more expertise and effort but can be a very effective way of evolving a website to better suit customers needs. For those not familiar with AB tests the idea is that users are split into 2 groups, each group is shown different content, features or user interfaces. The test measures how likely each group is to complete a goal. If you are selling something the goal is usually a sale.

Do you have any techniques or tips for understanding how users use your sites or products? If so please share them in the comments.


Dumb-ass Features and Really Agile Management

If you have been a professional developer for a while, at some point you’ll probably have thought to yourself, “why are we going to so much effort for this dumb-ass feature!?”. If you work with developers, there’s a very good chance that at some point they’ve thought this about your project – honestly. Thinking through this question and its causes can give some insight into why software development customers should embrace agile approaches as part of their product marketing toolkit.

IMO there are 3 answers to this question (not mutually-exclusive):

  1. The customer doesn’t realise how “expensive” the feature is;
  2. The developer/s don’t know/understand how much of a benefit this feature will bring;
  3. Nobody knows how much of a benefit this feature will bring.

Answer 3 is where the real power of agile development lies – much more on that in a moment. First let’s briefly address answers 1 and 2.

Answer 1, “the customer doesn’t realise how expensive the feature is”, is bad because the business really ought to know what it is spending – how much a decision is going to cost before they commit to it. In the short term this is most likely an opportunity cost. However, if systematically repeated, this can have a huge impact on both effectiveness and efficiency. Both developers and customers have a duty to each other to expose likely costs of alternative solutions as early as possible. 

Answer 2, “The developer/s don’t know/understand how much of a benefit this feature will bring“, some people think this isn’t very important but personally I believe it is very important. From the developer’s perspective this is demotivating. If the developer isn’t demotivated by this sort of thing, do you really want to employee them?! It really isn’t a question of just an individuals’ motivation though. The business is missing an opportunity too. With a better understanding of how a feature benefits the business, the developer may also be able to point out low cost improvements or cheaper/better/faster alternatives.

Answer 3, “Nobody knows how much of a benefit this feature will bring.”. This is where the big money is made. The best managers and leaders will strive for ways to answer this question as quickly and as cost-effectively as possible. They’ll look to test their opinions and assumptions about the product/service and the end-customer as quickly as possible. This is where the real power of agile approaches to software lies.

Moving from a Waterfall approach to software development to a basic iteration based agile approach will likely result in fewer defects and a better product – at least in terms of meeting the internal customer requirements. It is also more likely to be released when it is expected. I won’t go into this in detail, but broadly speaking the iteration approach leads to these improvements due to: more and more frequent internal customer involvement; better understanding of what needs to be built; and more frequent integration and testing.

Broadly speaking (though there are many nuances in practice) these improvements can be achieved by taking, for example a 16 week development project and organising it into 8x 2 week iterations/sprints each followed by customer acceptance (iteration meetings / sprint reviews).

Unfortunately, none of this addresses answer 3, “Nobody knows how much of a benefit this feature will bring.” End-customers still haven’t used the new features, new product or service. Even if the customer is internal and is involved in the agile process they probably still haven’t used the new features in earnest or for real work.

To understand the customer better and what features or changes will benefit them and our company we need to break these projects up into much smaller feature increments and move towards an even more agile approach.

Many projects are conceived from a piece of data and/or an assumption about the end-customer. What if our first iteration of development work is the smallest thing we can do to try and move the data point, or test the assumption we’ve made about the end-customer? The development team work for an iteration then release. Now the end-customer can see and use the new feature and we can assess its benefit before deciding whether to take it further and making another smallest step.

Lots of small quick steps enable us to evolve our product based on end-customer data and feedback. That’s really agile development and evolutionary product marketing.

Thanks for reading.


Site Conversion and Lipstick on a Pig

“You put lipstick on a pig, it’s still a pig” – Barak Obama

If I’m looking for a 40 inch LCD HD TV and your site only sells 28 inch Plasma you’re not going to make a sale. If you’ve spent money advertising your “wide choice of LCD HD TVs” then too bad :-p

When it comes to ecommerce website conversion the strongest lever probably isn’t how the site looks. If you don’t have the product people are looking for at an acceptable price then endlessly tinkering with how the site looks won’t make a jot of difference to conversion.

If you’re an ecommerce site then spend some time and effort determining what visitors to your site are currently looking for. They’re probably giving signals left right and center. What do they search for? What filters do they apply? What product sections do they click through to?

Thanks for reading,


P.S. my earlier, longer and slightly more serious post about 3 ways to improve conversion