Wednesday 11 May 2011

The Burning platform

You don't know where inspiration would come and strike you.. today it did to me through this post that talks about a memo from the Nokia CEO Stephen Elop . I read through the post and I read through the memo... let me be very honest and tell you that though I would not wish any of your company CEO's to write that It wont be a bad thing to get to read that... With the memo written in the post I don't know what it did or will do to the employees but I am sure it changed one thing for me sure....

It makes me realise that You are always standing on a Burning platform and you need to make that quick decision & decide if you should make efforts to get the platform out of fire or jump in the freezing water and run-away. I was always a fighter and will be so I choose to Fight it back...

In the memo that is very much open and clear the last part puts more ignition to my burning desires...

How did we get to this point? Why did we fall behind when the world around us evolved?

This is what I have been trying to understand. I believe at least some of it has been due to our attitude inside Nokia. We poured gasoline on our own burning platform. I believe we have lacked accountability and leadership to align and direct the company through these disruptive times. We had a series of misses. We haven't been delivering innovation fast enough. We're not collaborating internally.

Nokia, our platform is burning.

We are working on a path forward -- a path to rebuild our market leadership. When we share the new strategy on February 11, it will be a huge effort to transform our company. But, I believe that together, we can face the challenges ahead of us. Together, we can choose to define our future.

The burning platform, upon which the man found himself, caused the man to shift his behaviour, and take a bold and brave step into an uncertain future. He was able to tell his story. Now, we have a great opportunity to do the same.

Stephen.

As employees and leaders each one of us needs to think about how we can do what to ensure growth of the company and not what we feel right... We all stand on burning platforms and if we don't react in individual and team perspective it wont be far if we will be Ashes....Nokia may rise and shine, they have the people , the money , the vision, the force and above all the commitment to their ONLY platform... Do you? Will you?

Thursday 5 May 2011

Product Roadmaps can be Dangerous


I had a long discussion today with a friend today over products and roadmaps, though I have to say I am not a big roadmap basher myself but I am not a big fan too of roadmaps in the state that they are usually presented. The discussion emerged when my friend explained how much trouble it is to meet the expectations of the customers who are been promised things, specially those visionary things that are put on paper and do not or might never be in the product yet they are promised to those customers by our vicious sales personnel who by now are gone leaving your company to develop something that may not be of any use to the product.

Roadmaps may be beneficial for products, but when it comes to roadmaps not many companies put their thinking hats effectively. I see a lot of issues occurring from roadmaps made public and with this post I would also like to share a few ways on how to cover the roadmaps so it becomes a win win situation.

First lets talk about the challenges a company faces when dealing with roadmaps :

1. Agility : Assuming you created a roadmap for more than a year, and in the middle of the 1st quarter you get a customers who demand a huge feature in your product [Even ready to fund] what would you do? If you have a roadmap promised to world, you are either going to have fund a full new development team or think about going back on what you promised to your customers. Long term roadmaps cause a loss of Agility if not managed well.

2. Your roadmaps work against you sometimes? I prudently remember a few sister companies having similar product lines using X product's roadmap to show how that product is not ready for a specific market and why they should sell Y product only. If internals can have this issue think what competition can do to this. Of course there should be no competition / race internally in an ideal world.

3. You promised X in 2009 but its 2011 and you have not delivered it yet, heard something like this? Well if you sold your customers your vision and how your product would look like 2 years later, you run a risk of facing this. You have potential to make your customers unhappy if you do not present them your plans in the right way.

4. Expectation burden : This is usually the problem. Most roadmaps are done with a specific view. If a roadmap gives you say a 1 year release of a product the expectation around it usually becomes so high that it results in a expectation crusher when the release is actually done.

5. Customer clashes : For small products this may not be the case, but when roadmap's are shared in councils and customer forums, there usually comes an argument that there is nothing in this roadmap that I will be benefited from. Misery?

Well so some of these challenges we have faced, more precisely we were victim to the roadmap concept in a whole. So how how does one really handle this? By saying this I want to say that I don't think you can work without a roadmap. But here are things that can be done to handle above challenges and win confidence of customers, internal staff and provide a better and effective vision plan that can be termed as a roadmap with some alterations.

1. High Level Only
Roadmaps have to be very high level. A view that looks like a eagle view. talks about where the product is moving. Does not detail features at all. Brings consolidated modules together to form complete end result and how customer would benefit from it. A long time ago I had seen a roadmap from a product that is now a revolution in the CRM arena and has become a global force and platform. The roadmap listed customers, expected features, modules the company stratified and how they liked up together.

2. Visionary not time bounded
No April-2011, No Jun-2012.. It should be purely visionary with very high level time lines in years... I know it is difficult to answer if a customer says why.. but isn't it your roadmap? If your customers are asked to push things in they will want every thing in quarter 1 and you will be left crying for the rest of 9 quarters for other customers?

3. Not to all
it should be presented to a very few. Why show it to the world and then apologies if you could not do it for any reasons. We were in situations where bulky roadmaps were released to customers and then when economy had down turns and no development teams to fulfill those roadmaps we had to face the customer anger.

4. Negotiations?
Never show and negotiate roadmaps, if you do so you will end up running behind development teams to change things and behind customers to deal with.

5. Phased
Roadmap should not release bulk modules. Phase them into multiple releases. So if something is not ready by X date you have a easy way to manage it in a year in a phased manner without affecting the customer satisfaction.

6. Compact
Make your roadmaps and presentations compact. Do not bullshit to sell. more than 2 quarters is a problem more than 4 quarters roadmap is a disaster.

7. No Sales
Do not involves sales in roadmap presentations. They buy everything from customers to sell it to them. VP, CTO or Product managers are the right people to demonstrate roadmaps in 4 chair conference rooms with customers. If you are really having a team of attention seeking individuals ask them to present things on Launch.

8. Creators
Be careful in choosing the creators of the roadmaps. The more inputs from the sales the more the disaster. Have a person in this creation process who fights for usability not users.

I am sure there are many more things to discuss to ensure that the roadmap is better and effective and doesn't cause credibility issue to you and your company.

Tuesday 3 May 2011

Want to learn Agile? Get to the source code

If you are confused with the title No I am not kidding here, and if you are making fun of my knowledge about Agile there are not many better ways of knowing what Agile is than watching this smart movie "Source code". My last weekend was busy, tied with flock, lot of work , shopping and busty busy release. Hence I picked time on Monday night (Yup a school night) and watched the Duncan Jones directed "The Source Code". If you are in India then the stars are not so known lead by Jake Gyllenhaal (Prince of Persia) and supported by Michelle Monaghan (Made of Honour) and Jeffery Wright (The CIA guy who funds James bond in Casino Royale when he is loosing the poker game).

To cut the story and theme you a bit about what kind of learning's on Agile you get with the movie.. the story revolves around a guy Col. Stevens who sees himself alive in a capsule lead by Dr. Rutledge (Jeffery Wright) and Col. Goodwin (Vera Farmiga). There is a system named source code that gets Stevens to life and is planted in a body of a teacher who is travelling with his girlfriend in a Chicago train ONLY for 8 minutes. Source code lets people go in past to find things out [not change them]. The objective of the mission is to get Stevens into the train and find out the person who bombed the train and what are his next targets.

The story moves on Stevens several attempts of 8 minutes on how each time he goes and finds a different clue to find out the next target and find his own identity. Watching the movie was pleasant as flavours of Inception took the movie to a supper height while there was no confusion left in the movie due to fantastic writing. Every 8 minutes spent by Stevens in the train improvises his actions and in turn the result. Just like Agile.. every iteration give you ability to learn from your mistakes, let you improve, help you improvise and of course definitely improve the quality of results...

Unlike in source code where you cannot change the past, Agility allows you to revisit your code and refactor it. Agile is the theme behind source code... though I would keep the climax and rest of the details of the movie hid to let you see it and experience it.. I have to say that Agility is all over... Its one thing that can help you do things better and better.

Design Agile...
Build Agile
Review Agile
Sell Agile

Earn Agile ;) ... I think you should watch Source code if you want to know better on what Agile is...

Monday 2 May 2011

When should I leave? When is the right time to quit?

There is never a right time, and nothing is ever too late.. You always are in a war of thoughts specially when it is about the thing that you are tied for most of your time.... yes Work, Your Job. Every bad day you have at work or every tiring day you spend once for a moment you have this thought triggering... "Am I doing the right thing being here?" sometimes "Is it time for me to leave?"

With reference to the IT industry and the trending attrition rates, I have to say that most people do not know on the exact reasons why they want to leave or most times do not know if it is time for them to leave or not.. a bunch of last few interviews I did, just refreshed my memory and affirm this thought... There are those passive job seekers who had a few months/years ago posted their resume on some job portal and now out of blue some consultants have started posting and patching them up for interviews, eventually they are forced to look for opportunities.

"I want to change the domain and learn new things"
"This technology is not great and I want to work on different technologies"
"Its too long for me here and the new company is offering exciting opportunities"

Is what you would hear from them when they quit. I don't say these are not valid reasons, I just say that it shows that people do not know if they really want to change or they don't know if the time to change is right... Most times they are not sure because they think they are earning good but not too good, the work is stable but sometimes flaky, the life is smoother but sometimes tiring and they are at the best role in the team but not the top. Many times they are having bad days at work every now and then and the few new entries on the job boards, those bunch of friends who are updating their linked in status as "XXXX is now Sr. Manager at YYY" makes these people convert themselves from passive to active job seekers.

So for those of who do not know if you should leave or not... here is how you can find what you should do and If you should stay or GO...

1. Are you satisfied?
Satisfaction should be the key :
a. Are you fulfilled.
b. Are you learning.
c. Are you challenged enough?

Most times people link their satisfaction to a comparative salary of others in the industry/friends circle etc. The prominent question you should ask yourself is... is what you are doing making you superior to what others at the same cadre elsewhere are?

If you are learning new things every other day, if you are exposed to challenging projects and situations, I think you are increasing your value to a better degree. If you are happy in what you are doing then its a NO GO. Because if you are happy and still changing you would be having the same syndrome affecting you in next few weeks...

2. How is your relationship with your manager?
Many times I have heard this jargon "People leave their Managers" I think it is true to a certain extent not entirely. If you and your manager are not getting along well, chances are that you will always be in a negative radar and thus dis-satisfied. If our manager gives you a peak of future, trusts in you, gives you opportunities... then its a NO GO.
3. Are you in a hurry?
Usually people tend to think that just because the job boards and full of opportunities the economy is booming and they should leave. As I grew I learnt that many times employers carry a different perspective... people who start looking for job changes right when the economy is booming are not necessarily the people who are laid of, they can be those opportunistic lot who care for growth or the hungry lot who will switch with time. Just because you think a lot of job postings means a economic boom and that you think you are missing it then its a NO GO. Wait, watch the season carefully and then step out.

4. Are there any internal good opportunities?
Have you check other opportunities available to you? I remember one of a very Sr. members in the past left us assuming that he would be constrained on opportunities and what he was doing was repetitive only after a few months to learn that he could have played a very very critical role in setting up a fundamental of a fast growing company. If you have not explored the internal opportunities enough... its a NO GO.

Well if the answer to any of the questions above is a NO... you definitely should GO. But if the answer to any or many of the above are Yes... then I guess, you need to take time, revolve around your thoughts and make a call after doing some better thinking.

Sunday 1 May 2011

Product Features are not research materials

Ani [Our Sr. Dev team member] and me had a conversation this weekend over our 129th release. The topic evolved on how we released a small but smart feature that can help our customers do something very easily. However Ani triggered something that I cannot stop myself from writing. "We have so many small and useful features, most of users don't know about" I agreed, I agreed because the type of questions I receive from our Customer Services team reveal that there are a huge bunch of features that our customers(both internal and external) don't even know, don't even see'em.

I think one of the key element to the success of any product is the ability of that product to reveal what a user can do to save time and which features he can use. Most of the times the development team is aware of all those twisty features that the end users are not aware of. If you get set yourself on your product you would realise tons of features un-used just because they are not easily accessible to users and they dont know how to use it.

Take an example of Facebook if your news feed is bombarded by those Daily Horoscope feed items from some of your crazy friends who think that the Horoscope really falls true or who access it as one of their friends clicked it over or they enabled it out of ignorance and do not know it is spamming others you don't have an easy way to know to stop it. You have to take your cursor to a particular position and then click on a X button to avail actions and then perform a block [Freaky isn't it?]

So what do you need to do to make your product feature and feature knowledge RICH?

Here are some thoughts....

1. Make functions available at easily accessible place
If they are not available where your eye or sight can reach, its going to be useless. People cannot use a 500 page help document to find out about a feature they don't know about. Bring it to their sight and let them search for the answer or ask you about it.

2. Product needs to have a glossary so curious users can go and find things by themselves.
I always found a glossary useful. For most of the articles / books I read I prefer running my eye over the glossary once when I am in the middle of reading and once when I am towards end to figure out if there are certain terms and items that I haven't missed out.

3. Conduct frequent webinars from development staff to make people aware of features.
Developers are the key source to knowledge of product. An answer that I can get from YN or YT or Rupali or Vijay are not the answers I can find in help file or product documentation. These can be small tips , tricks and usage stance. Frequent webinars on different features make it easy for users to join out of curiosity and learn about features. Of course this brings your development unit closer to the customer questions and understandings. I am highly impressed with the amount of webinars done by Oracle on their Autovue platform, 3 sessions I attended and I already know that there is a easy way of clustering servers that we are not using at the moment.

4. Wiki features - Make the wiki available at right places
A product wiki is the most cool thing to have. Believe me a lot of problems , questions , calls and significant resource wastage can be avoided if you a product bible that can be filled in the wiki.

5. Provide help tips at all possible places.
Those little bubbles out there, can help increase curiosity levels and in turn product usage.

6. Create a feature feedback module
Do you ask if you find our search better? You may know the answer but you may also know what critical elements are missing in your search that your customers want. When can this help? Well imagine you put all your efforts to build a full new user interface just to learn that your customers are OK with what you have, they just wanted a effective color on the UI.

7. Iteratively initiate surveys that are real time and reaches specific high usage users not administrators only
Most surveys on products are done with administrative users, sometimes end users. It is quite important to involve users who login the most and/or use the feature most to provide feedback . This will definitely help building a good product vision.

8. Maintain feature usage stats, so you know where to put efforts on.
Do you have it? No..... Go do it. if you know your product is a content dump, you may as well improve the storage / retrieval part of it ;)

So over and over I have to say and conclude that no matter what your product is and how hugely successful it is... there are tons of features that the end users are not aware of and it may be hurting your revenues. Go figure out a way to let them know what they have in the right way, and yes... First Train your internal people.