Books

Tuesday, April 21, 2009

Your Codes Shall Live After you...

Prior to now, I have never worked in an environment where I had to inherit a code base to work with (well except those times I have had to peek under the hood of some open source codes I needed to tweak) It is either I write the needed codes myself or I do.

But recently that I just got a job where I get paid to play around with computers, the internet and write codes, sooner or later I know I am going to be confronted with that situation; To build on codes whose original authors have long left the company and are nowhere to be found. It is not as if am that concerned about this happening, guess am more preoccupied with the thought of the quality of codes I will be giving up for inheritance when I finally take my leave from the company.

Am presently working on a project where I am building, more or less, from scratch and with every line of code I write, that thought keeps hounding me.

Guess the saying: the good evil deed men do shall live after them, is also true for you as a developer. Your codes too shall leave after you. And I don’t think I would want to leave behind an arcane legacy :) so to prevent this from happening I went ahead and got myself a book on how to write quality and manageable codes. A pretty nice book on software development I’ll say.

But then again when it comes to coding style, it’s worth stressing that its sorta like Religion where you can’t claim that a particular method is the way: the most efficient. But the trick is to come up with a style based on some fundamental guidelines and adhere to it. It’s about maintaining consistency. Whichever style you decide to adopt the key is to stick to it and maintain it across board.

So guess am doing my bit in ensuring the quality of codes out there, I can only ask of you the same. Do find the following online articles on the topic helpful, like I did. They are PHP centric ;)

An article from devshed, tim kadlec on the 5s, and Reinhold Weber's tips

Wednesday, April 01, 2009

Sell Benefits Not Features…

The aim of any marketing efforts is to elicit an action and in most cases it’s to make potential customers make a buying decision. If people don’t take that action of buying then we can conclude that all our marketing hasn’t achieve its objectives.

When dealing with high tech products or services, similar goal is expected: make someone pay for your software or get someone to subscribe to use your web app. As a marketer, this involves coming up with ways to ensure that the marketing decision made by your potential customers favor your product or services.

Its all about coaxing or convincing and in high tech marketing it is not uncommon to see marketers listing features their software comes loaded with in other to coax customers to make a buying decision that will favors their offerings.

But going in the direction of features listing might not be quite a productive strategy, especially for services like software. Ideally the logic behind feature touting goes somewhat like this: “List the features, let the customers know all the cool features they will be buying so that they will know the benefits they will enjoy and how our software will help solve their problems”.

Well it so happens that things don’t normally play out that way. Customers might not necessary see the benefits, straightway from your litany of features. And this is why playing it strong on the feature listing side might not be that effective. Instead of feature touting, I will advocate Benefit touting .

In stead of strictly feature listing, enumerate the benefits offered by your software in explicit language.

Not that listing features is wrong in itself, but we have to keep in mind that our aim is to elicit an action: persuade potential customers to make a decision to buy, and this is easier done when your customers can grasp the relevance of your solution to their peculiar challenges.

The problem with feature listing is that it is not an effective means in communicating the benefits of your offering to customers.

Truth is, if you have features, you should have benefits but you have to take into consideration that half of the time, majority of your customer might not be that techie savvy, so they might not, at once connect the dots of your features to get the benefits. This is why it pays to sell to them by explicitly stating your benefits. This will make buying much easier.

One need to take into cognizance that decision making is powered by emotions, so it will make more sense Listing benefits not features since it will be a faster way to make customers easily identify what they will gain from your software, how it will make their work (or life) easier, thereby generating the necessary emotions that will propel them to sign that cheque.

Doing this makes buying easier like I said earlier on. Have you ever wondered why most people resist selling but enjoy buying? Why is this so? Its simple, buying becomes enjoyable when backed with the knowledge that the Good or Services being purchased is really the solution to a problem. List the benefits and people will find it easy to connect your solution to their problems, list the features, well….

So what is the lesson being learnt here?

“It is a better marketing strategy to design your marketing campaign around benefits listing than feature listing.”

Republished from 60mwtgeeks