Recently, I wrote a post about the perils of customisation and feature requests. Just saw this cool article on @Invisionapp that points out that many times, customisation requests are really caused by poor UX. The customer simply can’t figure out how to do what he needs to do easily, even if your software actually could allow it.
Its worth taking the time to understand the underlying motivation behind these feature requests to see if its not just a problem with the way your service makes some features available.
See the original article: Integrating feature requests without destroying your product
How many times has a customer told you they would love to buy your product if only it did this tiny little thing that you don’t have on your roadmap? The natural instinct is to make a deal with the customer for a long-term comittment if you deliver the missing functionality. The client gets what he wants, you get a new customer and everyone is happy, right?
The problem with this is that customisation is one of the most disruptive things that can happen to a lean startup with a small team trying to achive great things in record time. Engineers have to stop what they are doing, get their heads around a totally new request and see how they can pull it off.
Even pricing custom work can be tricky as the pricing has to include development and testing time as well as all the complexity of validating the specification and the opportunity cost of having your scarce engineering resources working on something non-strategic. Things can get worse if there are interdependencies between the customer’s infrastrucutre and your system as any changes on the customer’s side leads to more work for your team. Most startups I have worked for dramatically underestimate the cost of these customisations and usually end up loosing money on them.
To my mind, the best approach is to set up a separate team that focusses soley on customisation if this can enable substantial sales. This way you can more easily understand the impacts and costs of customisation while leaving your core technology teams focussed on making your product even more awesome.
A new startup often gets their first real break when a *Big Customer* finaly realises how awesome the product is. Benefits for the startup are immediate; cash, credibility, better understanding of how the product meets a real customers need and a great boost to the team’s motivation.
But its not all good news. Large customers know how much leverage they have on a small company and often use it to exctract special conditions as part of the deal, often promising even more business when the solution is adoped more broadly. Also, these larger customers have very specific requirements and internal policies that don’t give the the latitude to be flexible. This means that if they are not careful, the startup can slide into a situation where everything they do revolves around a single customer who asks them to modify their product, spend lots of time with in-house and generally do stuff the management team had never planned to do. It can be very defocussing if internal operations are not structured to handle it.
Don’t get me wrong, big customers are great if you can get them, you just have to make sure they don’t end up running your company.