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.

Read More

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.

Read More

Minimum Viable Product, Need for today, Necessity for tomorrow

Every one wants to launch it big, hugely big. A hype, A marketing base, plans and communications , blah blah blah.... in an attempt to make this big.. there is always a lot of bigger effort spent.. the bigger the effort the bigger the issues. Thus bigger your first version, bigger the problem. A while ago working with my current organization, I saw that the Team decided to build something new.. a shorter / mini version of a content management system, more robust , more architecturally strong, more envisioned. Perhaps the first version was a very very primary version.. a version that would just do the needful. There is no doubt that it was hugely successful. Bought by a major giant , having some real cool features, and scope to add new things in near future. All of this went by because of the simple and pragmatic approach was taken "Build what is atmost necessary".

We learnt, a bit late but we learnt it hard and well. We now start to work on a new feature addon to the system, A feature that would change life of the system and usage and sales and future. So I decided to ask this question to those selected few who are key and critical developers.... My question was

" What should we build? A Elephant or the sledge runner?"

The Team threw up all their ideas, brains and pros and cons.. in the end they concluded that the smaller they start and make it available the better they can make it for future. Experience backs it well. Define the minimum needs, instead of acting greedy and building everything in once. Avail the real-term feedback and then improvise. Define what is minimum instead of going with "Customers want this" because in the end customers dont know what they want.

Thats what Agile says, isnt it? Build in small phases , deploy regularly , get feedback and improvise?

Then came another question...

"How to define that Minimum of the Minimum Viable Product?"

A tricky question. I am sure this needs a better thought process than just a definition of X, Y and Z items. Its a iterative process that needs to be defined, Ask the question "Am I there yet? after every few days when you are defining the requirements."

I remember we did a documentary a couple of years ago... We started with a script that was conceptualised to be a city tour, it turned that we needed a proper theme to get attention of the audiences. We changed it. Then came the phase where decided cast of the documentary, we thought its too much, we changed. In iterations we went on and on to make a minimum script that would help us make a small piece that we could show others. As we progressed, we changed a lot of things based on the feedback that came out of the process. In the end it turned out that we were closer to make a commercial drama to make what it needed "Gather Audiences, and Get Applause". I know thats what they do with those Hollywood shows and movies.

A lot of times we make decisions driven by demands and not needs. MVP techniques you to help build a basic expectation first.

So when you plan for a feature, product ask your Product Owner on what is the MVP of the whole thing....

More on Minimum Viable Product here

Read More