Posts tagged as:

features

Don’t listen to your customers

by Andrew on July 30, 2008

Too many times I’ve seen businesses slam the wheel hard to the left and change course chasing money. You know the drill, if only our product could do something else we’d sell so much more. Or worse a customer or potential customer suggests a feature that would clinch the deal.

Let’s face it just because one person wants it doesn’t mean you’re on to a winner, success just isn’t that easy - someone won’t just walk in the door and give you all the answers. The hard reality is that talk is cheap and it’s easy for someone to say they would certainly buy something if only it did something else as well, it’s quite another for them to actually drop their current system to replace it with yours when the feature happens.

Focus

Focus on what is important, delivering a product that long term meets your vision and accomplishes the goals of your users.

You know your market, focus and stick to that

You should be, as 37 signals put it, hiring the right customers, figure out your core target market and target them. A common fault I see with businesses that end up in a position where they’re chasing cash is generally that they’ve refused to figure out a core market, and refused to focus on it.

They argue that by adopting too narrow a focus they’re cutting themselves out of a potentially lucrative market. It may sound like a compelling argument, unfortunately most of the time, it leads to spreading yourself too thin, or not being agile or focused enough to truly serve any of your “target” markets.

Find a core market, where you can make a difference and focus exclusively on that market.

Branch your product from a strong trunk of core users, just like a tree if you branch too early the trunk won’t be able to support the weight.

You have a vision for your product, focus and stick to that

It’s very tempting to listen to every feature request from every passionate user and fall in love with it. That’s why a vision is important, knowing what it is your product is meant to accomplish helps immensely as a filter for “good ideas”.

An example of a product vision is goroam’s citrus. Our vision is simple “estate agent tools that don’t suck” and the filter for new features is a simple set of questions

  • will it help sell more properties?
  • does it give users valuable information?
  • does it save users time?

If a feature doesn’t have a compelling answer to any of these questions, it’s a non starter. Most importantly though the answer has to affect most of our customers. We’re not in the business of worring about edge cases or selling features.

Adopt a pragmatic approach to feature requests

And by pragmatic, I mean ruthless. Make absolutely sure it focuses on your market, your vision and affects most of your customers. Don’t keep feature lists, the good ideas will come back again and again the bad will just languish there anyway. Have a roadmap, but execute it quickly and only look as far as the next release. Don’t be rude, be positive about good ideas but make no promises.

{ Comments }

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 }