Posts tagged as:

methodology

Don’t sell features

by Andrew on July 29, 2008

Your product has a vision, a roadmap and you’re in control of it. You’ve worked hard to build a niche and now you’re faced with the dilema that faces too many small companies: Company X wants your product to do something else - but unlike the other tire kickers, they’re willing to pay for it.

Here there be dragons!

Bootstrapping is hard work, and sometimes you’ll have to do other work to pay the bills but resist the urge to allow customers to pay for features in your product. It makes a very subtle change in the relationship, suddenly the feature is now your customers and they’re paying for it, so they’re dictating how it should work; not just today, but tomorrow as well.

the devil is in the details

Even if you’re in the rare situation that the next big feature on your list to implement is the feature you’re being paid to build, beware. While you might agree on the feature in principle, you might not see eye to eye on the implementation details. They will more than likely want things to match their internal processes. Which isn’t likely to match that of your other customers, or your vision.

When a user sits down to plan out a feature they’re paying for they have specific goals in mind, those goals aren’t going to be keeping things simple and they’re not going to be looking at how to achieve most of the needs of all your customers. They’ll be looking to achieve all of their own and wont care a jot about anyone else’s. They may pay lip service to caring but in the end why should they? They’re paying to have the feature developed and if someone else wants it to do something else - let them pay.

no control

So in the end you’ve developed the feature, been paid for it but probably compromised your vision for the product in the process. You’ve also painted yourself into a corner, because now that someone has paid for this feature updates, changes and even taking it away at a later date isn’t really going to be at your discretion.

Compound this when the strategy works the first time and you try it out again. Now you’re totally loosing control of your product and your vision is a thing of the past. Your nice simple product is growing tentacles and doesn’t quite work the way an average user would want it to work. Your edge cases are taking over and your vision is becoming bloated with £10,000 buttons one person clicks once a week that confuse everyone else.

rules must have exceptions

I have seen selling features actually work in practice a few times. There have been some notable examples of open source software developers doing this.

The difference here is the features have already been requested by the community and a bounty is paid or the customer is paying to fork the code. Forking code is an option, even for a company developing closed source software or a service offering, but it’s not really an attractive one. You want to keep things as simple as possible and trying to maintain more than one product is orders of magnitude harder than just maintaining one.

it’s not worth it, just don’t do it

My very strong recommendation is to keep it simple, one code base, one product, one vision - keep it simple and don’t sell features.

{ Comments }

Release early - Release often

by Andrew on July 9, 2008

Agile methodologies have recently been getting something of a bad name, it’s not unwarranted but it is unfortunate. The problem isn’t actually the process, an agile process will work very well - if the infrastructure supporting it is capable of of being agile as well. By supporting infrastructure for a process here I don’t mean servers and software I mean the people and the organisational foundations. The organisation trying to use an agile process must it’s self be agile, quick to react to change. Agile processes that work have one thing in common, they encourage features to be released early and released often.

A pretty basic overview of our process goes something like this:

Big Bag of Features

Our projects and releases go through a number of stages, the first we call The Big Bag of Features. When a project is really just an idea, it’s something we might want to build and we basically rough out some ideas and start to grow them into all sorts of crazy future versions, we talk about all the features we’ll need to achieve them and how we’ll go about it.

Minimum Stable Feature-set

From the BBoF we usually end up with at least one, more often than not a number of possible outcomes and development paths. By talking through all of the options, all the features and all the future versions we’d like to be able to build leads us naturally to something we can build; a vision for a product.

Citrus is a good example of this practice, we’re at the stage where we’ve decided the vision for the project, have a big bag of features we’d like to implement and are now in the process of creating our MSF

From the vision we decide what we need to make a product work; less is definitely more at this stage. We normally take each feature we’ve decided would be nice to have and try to think about who would use it and why. If we can’t come up with a compelling argument for most of our users using it, we normally chuck it back into the bag to worry about later. We refer to the result as theMinimum Stable Feature-set (MSF) or Minimum Launch Feature Set.The bare minimum we need to launch a working product.

The MSF becomes the next iteration, and once it’s set we don’t alter it. Nothing is added or taken away. On the surface this might seem either silly or a bit high and mighty, but we can do it because we put the work in ahead of time. We’ve discussed how we envision the product being used and we make sure we’ve covered all the bases. New great ideas just aren’t important enough to include, no matter how good they are. We leave them for another iteration and another day.

These ideas can be politically disastrous in some organisations, it’s downright heresy to tell the boss, or the sales director or a colleague what amounts to: their newest great idea just isn’t good enough. It’s important for an organisation to have focus though, this is where the MSF and short iterations come into their own. Releasing early and often means that you’re quickly on to the next round of updates and those great ideas can be looked at objectively alongside anything else in the Big Bag of Features.

Getting started

Finally we start coding the interfaces first, then backend to meet our MSF. In the case of a new project partial interim releases are made for testing. We try to work out an entire area of the project first then release that to our testing audience for feedback. As the iterations contiune towards release we add all the features from our MSF.

Updates

When it comes to updating projects we throw away the Big Bag of Features and start all over again.You heard it right, throw them away, gone. A long time ago I learned that feature lists just cause trouble. You can’t help but schedule them, the schedules are very loose and they’re never met but still promises are made based on them. In the end they start to read more like a list of failures, things your application doesn’t do. More importantly, things your application will more than likely never do. So we throw them away and start again with a new Big Bag of Features, the most important features will bubble to the top of your memory anyway and will end up right back in this new BBoF.

For an update our MSF is usually a single feature, or small feature set if they work best that way. The aim is to keep the releases small and concise, targeting one area of functionality. This doesn’t mean that we don’t set milestones or visions for the future development of the product, we normally make a milestone accomplish some greater goal or vision for the product. But we try not to roll a list of disparate fixes to various parts of the application into a single release, we break them up into many smaller releases.

Rinse and Repeat

We continue in this way for the life of the project releasing features to users early and often so bugs are spotted quicker and we never go too far down a dead end, creating something users won’t use. It’s during this stage that we really work hard to measure how an application is being used, or not used so we can focus our energy only on the most important parts. We never try to be everything to everyone, we’re not afraid to disappoint some people or to just say no. We want our application to be great at what it does, not mediocre at everything.

{ Comments }