Lifecycle of a feature

Last time we saw how the usage of technology in most organizations is very low. This leads to a ‘lose-lose’ situation. This week I will try to provide a solution.

Evolution of a feature

There is a feature explosion. In order to make things simpler let us take one feature at a time and see how it gets created. I am sure you all have developed lots of software and have created features. Still, let us revisit this evolution of a feature. Here are the typical steps.

1. The diagram is simple. Visualise a user with a problem. If (s)he thinks this problem could be solved, then he shares it with someone.

2. The someone then thinks about the problem and tries to analyse how to solve it.

3. Lot of thinking and trial/error goes into solving the problem.

4. Finally there will be some possible solutions found. These solutions are then evaluated and the best one is chosen.

5. This chosen one is then built into a feature.

6. We started with a need and ended with a feature.

Now, if you were the vendor creating the feature, is it feasible for you to go and install it on all your customers’ desktops? Not really. Further, this type of user and this type of need may not be there with all your existing customers (or future customers). So what happens to this feature which was just discovered after so much pain and effort?

Nothing! It just waits for more such features to get created and accumulated. As you can realise, there are lots of users with special needs. Many of these needs may not have an immediate solution. Some of these may have solutions which may end up as features.

Now there is a pool of discreet features waiting for something to happen to them. The vendor simply keeps quiet. Why? Because it is impossible to deploy features one by one. It does not make business sense.

Now what is the vendor waiting for? To accumulate a critical mass of features. Once that happens, the vendor comes out with a product or an upgrade. These diverse features are put together in some form of structure – menus, help files, keywords, functions, objects and packages. Some cohesive structure needs to be evolved even though the individual feature may have originated only with a particular type of user or need.

Unfortunately, all this effort that went on behind each feature is completely invisible for the final user. We install the product and then see what is available. On the face of it, there seem to be too many things, which appear to be an unrelated bunch of features. This confuses most of us. We end up knowing some bare minimum features which are required for survival for the job profile. May be someone gives us little bit of training on ‘commonly used’ features. Often the trainer himself has not explored fully. In any case, further exploration of available functionality stops soon after you achieve some amount of productivity. That ends the story.

At this stage all of us commit a grave mistake. This mistake is responsible for the gross underutilisation of features. The mistake is simple — we convince ourselves that:

1. I don’t need so many features

2. My role is <developer / CEO / clerk / manager/ whatever>. I already know what is needed to do my job.

3. I need to know only the basics, which I already know. I do not need to know advanced stuff.

What did we do? We just killed all the unexplored features. Why? Because we are complacent to learn further. (As long as your position — in business or your job — is not jeopardised, this argument works fine.

Now let us keep these negative and misleading thoughts aside and retrace the path of feature evolution. Only difference here is we will do it in the reverse manner.

Retracing the path

Now refer to the same diagram shown above. Start with the feature and go downwards. Where do you reach? With a user and a need. Now that you have thought about the feature so much, you must have been able to understand what need and what type of user. In most cases you can.

Now what is the big deal? Believe it or not, it is the biggest deal ever. You just learnt the base solution to exploiting technology fully. Now that you have found a feature – and the need it satisfies – just ask yourself: Is this need mine? Is this user having a profile similar to mine? If the answer is YES, you just found a feature which will help you. Got it?

Discovering the need behind every feature and mapping it to your needs is called effective technology utilisation.

Now, as a user it is so simple to master any technology.

Technology exploitation guide for every user

1. Take a product.

2. Look at each feature.

3. Find out the need and user profile it is designed to serve.

4. Think if it is useful to you.

5. If yes, use it.

6. If not, forget it.

Now, this is a nice thing for an end-user, who is not an IT professional. Every IT professional is also an end-user for some products. Therefore these guidelines apply to them as well.

However, for IT professionals, this list does not end here. It continues beyond personal benefit.

Guidelines for IT professionals

The task list is slightly different here.

1. Take a product.

2. Look at each feature.

3. Find out the need and user profile it is designed to serve.

4. Now, look at your existing or future customer base and think who would be benefited by this feature or functionality. At this stage, it is enough to note down the profile of the customer who would benefit.

5. Once you have the profile, you can then proceed to create a named list of customers (or departments or users within customers) who can benefit from this.

6. Now approach the customer / target audience with this benefit and demonstrate it.

7. If they find the benefit useful, they will want you to deploy, design, develop, and roll out this feature(s) for their team, department, and company.

What did we just do?

To summarise the above approach, we as IT Professionals, go behind every feature, unearth the benefit, search for beneficiaries and show it to them. Nobody will refuse a proven benefit.

I have a simple method of demystifying jargon. I first describe the concept in simple language, show its benefits and once the audience understands it, mention the jargon. This is the best way of teaching jargon – without giving it any importance.

So here is the jargon now.

What I just explained here is called: Value Based Selling.

Why am I talking about selling in a technical column? Again this brings us to a big problem with IT industry.

The gap between techies and salespersons

The approach that I described above sounds very simplistic and eminently usable. However, it is not that simple. The first question everyone will ask is, who should learn each feature? The obvious answer would be technical people. Now, that is a problem. Not that techies cannot learn features. Of course they can. The problem lies ahead. The problem is that techies often do not relate to anything non-technical. In that case, who will map technology to user context?

The answer is — the salespersons. But how will salespersons know the technology? They cannot learn it themselves. If they could, they would have been techies anyway! So the answer is that techies have to learn and explain technology to sales persons. And then sales persons have to map it to business needs.

Thus techies have to be an integral part of this process of value based selling.

Most companies will find it very difficult to change mindsets and egos. Moreover, in order to have this method implemented, the top management has to imbibe and agree to the methodology mentioned above. Otherwise, sustained implementation is not possible.

Examples

Here are some examples of what I mean by learning each feature and mapping it to the right target

audience. Nothing is clear without examples, is it not? Here are some features. Based upon these features I show you how to find the business benefit around it. The examples are explained in brief. If you need detailed explanation, you can refer to the relevant documentation of the products.

• Windows 2003 - Cross forest trust

Forest means a company in terms of Active Directory. Now, if employees from two different companies wanted to interact with each other, it required creation of explicit trust relationship between the two forests. If multiple employees were involved, multiple criss-cross trust relationships were involved.

This was the base need – ability to create trust between resources across two different forests which was not satisfied in Windows 2000. In Windows 2003 you can establish this type of trust within forests.

Now this is the technical feature. How do you translate it into a business scenario? Think of the type of customers who will require to trust other companies without prior planning. What comes to your mind?

1. Mergers and acquisitions.

2. Group companies who are consolidating IT.

3. BPO company who has tied up with a customer on a large scale.

Now, you can think of specific companies within your customer base where you can highlight this feature.

Was that not a good journey from technical understanding to segmenting target customers? The best part here is that the target customers probably still do not know the feature – till you go ahead and show it to them. Think of what you just did to your competitors!

• SQL Server - DBCC Pintable

This is a feature I have discussed before in one of the articles. Usually to improve performance of databases, data fetched from disk is kept in memory for some time. This is called caching. This is a good feature. However, it does not guarantee that the data will remain in memory. If some other data comes in cache, this data can be removed from cache.

If you want a particular set of tables (information) in memory, you can guarantee that this remains in memory till you explicitly remove it. This is possible using a command DBCC Pintable in SQL Server. This is the technical feature.

The benefit is improved performance without changing code. Now, all customers have face performance issue in applications which have large amount of data or large number of transaction load. This command, if used effectively can potentially increase the performance dramatically without the need tot change the code or application.

This is a nice value add which is never looked at by most developers. No salesperson obviously knows about this. So customers will never notice it anyway.

I can go on giving examples for years and still not finish.

New way of technology utilisation

The bottomline is simple. Learn every feature of every product. Convert it to business benefit. Show it to customers proactively and generate business for yourself. The sheer size of this potential is so much that you don’t need to worry about competition.

To make things simpler for you, vendors are going to continue creating more products and features. So you don’t need to worry about having no features to work on.

What you should worry about is how to have this new mindset inculcated into your organisation and all the teams which work there.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in