Analyst firms are quite popular among enterprises to help them decide what is best for thier companies. Large ISVs who want to influence the CIO or CEO too get involved with analyst firms to show thought leadership and be seen in front of these busy C Segment folks.
Analyst firms help in
1) They help enterprises purchase the right software. Well I am sure if your budget is small, you are not going to go to these analyst firms for advice. To get started the "Big 4" analyst firms start at $30K per year.
2) Save time
3) For an ISV, they help validate the message or conclusion you made.
4) They are like a paid "market analyst" for your company. If you think you find it worthwhile to hire someone and pay 100K per year to do this job, then it could be worth the time in investing in one firm.
5) BTW they do not give actionable data. They give you stats and you have to make the decision, hence in addition to the docs they give, you must have someone still to work and make decisions on that data.
Some analyst firms price their products (base products) based on the number of persons who can access their web site and documentation. Additionally they will have some docs that are readable only on paying more. For eg: the dataquest documents from Gartner.
This is a simple (shallow) comparison on how a few leading analyst firms (Gartner and Forrester) compare against each other. I was not able to find any good content in this space and hence wanted to express as neutral an opinion as possible. Hope this will be useful to "Analyst Relations" personnel in enterprises and ISVs to make a decision. This is based on my experience with them for over 3 years.
Document Content for similarly priced services Rating out of 10.
Gartner : 7/10
Forrester: 7.5 /10 (extra because some of their docs give numbers and that is extra payment for Gartner)
Comments :Forrester seems to be better for ISVs / Vendors, while Gartner is better for Enterprises trying to purchase. So I found Forrester a bit better as my usage was more from an ISV point of view
Advanced Docs
Gartner: can't rate as I did not have access to too many docs. But they are of great quality.
Forrester: good. and they do not seem to have segregation of document access itself.
Usefulness of Analyst Inquiry
Gartner:Will say what they hear from customers. Not much messaging / consulting works, I guess that must be available at extra cost.
Forrester:Will say what they hear from customers. They will push you to go for messaging / consulting works by extra dollars.
Comments:In this aspect, Forrester is not that good. They expect us to use the "Service Units" $$ and tell the analyst about our product. However for Gartner we can use our existing "Unlimited Inquiry" option itself.
Flexibility of Analyst Inquiry meaning can a non member do the call
Gartner:Yes (they have an option ask another person for this call only option)
Forrester:No. They also say they are strict about this. But on a case to case basis the account manager may allow others to talk so that when its time to renew, they can entice you to upgrade your licenses.
Comments:Normally for Gartner the Licensed user will have to email them but a non member can do the talking on the call.
So I find Gartner very useful in this case. However if you are having too many calls, you may want to go for the additional user license.
Analyst Friendliness
Gartner:8/10
Forrester:7.5/10
Comments:i think this is based on the analyst you talk to. If you consistently talk to them and keep them updated, you get better mileage.
Amount of Content Written
Gartner:Low. Both have high amount of new content written.
Comments:However since Gartner is probably in the market longer, the established markets have very less new content being written and hence you get less coverage in new documents, since there are fewer written for established markets.
For example, APM, Network monitoring are established markets and they do not write anything - no Magic Quadrant.
However for a market like Network Change Management, which is an upcoming one, there are chances newer vendors could get mentioned.
Forrester:Medium. They write lot of content even for established market segments and hence probability of getting mentioned is higher.
Comments: Unless they write we can't be mentioned in any good doc :-)
Any USPs
Gartner:They are more focused on End User / Customers not on ISVs. Their reports are more useful for our customers than for us to understand the competitive space.
Forrester:They seem to have lots of content which looks specifically done to help ISVs or Vendors to understand the competitive space. Comments:They have both ISVs or Vendors and Enterprises as clients. So hence I thought of highlighting this.
Account Manager:
Gartner: mixed. However calls were still scheduled via their call center easily.
Forrester:mixed initially. but we definitely had a better experience with Forrester. Excellent and enticed us to spend more than we would have otherwise.
Cost
Gartner:Starting prices in both range at approx the same limit. 30K
Forrester:Starting prices in both range at approx the same limit. 30K
Comments:this is the case when you have doc access and inquiry with unlimited analyst option.
Free Vendor Briefings Possible
Gartner:Yes - 1 hour -
Forrester:Yes - 1 hour -
Comments:This is something present in all analyst firms. this is normally one way and you cannot ask anything, you answer them. Normally this is for any new product releases, major product upgrades etc. So can do more often too and you DONOT have to be a client to do it.
Will they try their best to make your usage successful ?
Gartner:I guess this depends on how good your account manager is. I have had mixed results.
Forrester:They are excellent and even point to other analysts whose full time job is educating "Analyst Relations" persons.
Will they cover you and are they independent ?
Gartner:They are surely very independent. They have strict standards on how they cover vendors. So if you are a small vendor, you may simply not be able to meet their standards. Which is ok as they set the expectations clearly.
Forrester:No comments. May not be so strict in approach of covering.
Comments:For some analyst firms you have to use Service Units (costs money) to make sure that analysts know about you well.
Is it easy to do briefings ?
Gartner:Very Easy and Really professional internal IT. You can do it over the phone in less than 20 minutes. I like their email option the best.
Forrester:Can't match Gartner. They are sometimes too slow to respond unless you copy the account manager always, which is sometimes an overhead. EMail is very bad, however I have not tried their phone option.
Tidbits
Gartner:
Forrester:Even people in Forrester look up at Gartner as a great analyst firm. Gartner has many analysts covering specific areas where Forrester may only have one and some of them covering more than one area.
Comments:All analyst firms have excellent analysts as they are all very experienced. If you have tons of money, go for both.
To make your analyst relations program more effective, make sure you have one dedicated person in the first year to work with the analysts. This gives maximum mileage for what you are spending. If you cannot dedicate 70% of one person's time on this, you may not be utilizing to the max potential. Note, you are spending a lot, so unless you can back yourself, do not spend.
Also make it a point to do a self review how you perform and how much of their services you use every quarter. Try to improvise on the previous quarter. If you do well with one, then go for the second one in the second or third year.
Please note the disclaimer of my blog.
Sunday, September 13, 2009
Thursday, August 13, 2009
Keeping Secrets
How many times have you ended up publishing a price sheet you did not intend, to be available to your channel ? We have seen this all too often that unintentional leaks do happen. This is especially true when you are releasing a new product. The bad is you may change pricing models at the last minute too and all that explaining may be a bit hard.
Here is one suggestion on how to keep it a secret. Do not create one.
Unless you really created a Price Sheet or a document it does not have to be hidden. That is one public goof up avoided :-)
Since it is much easier to create a price sheet than releasing a product on time, .. keep it a secret.
Here is one suggestion on how to keep it a secret. Do not create one.
Unless you really created a Price Sheet or a document it does not have to be hidden. That is one public goof up avoided :-)
Since it is much easier to create a price sheet than releasing a product on time, .. keep it a secret.
Monday, June 29, 2009
My Son, My Appraising Manager and Project Management
I am very fond of my son. Who is not :-) Well, being too fond of them may lead you to irritate them too. When my wife and I sit together for a chat along with my son (just 3 years now), I observed one interesting thing. He always goes and sits next to my wife more than me. I am not jealous btw, honest. He comes to me but moves away faster than probably he wants to. This made me think. I later realized that I was probably irritating him by cuddling him and not letting him set the agenda :-) Later I stopped doing that and did not even look at what he was doing. Hey, now I found that he increased the average time spent "near" me.
Now 7 to 9 year back I had a comment from my first appraising manager. I asked what is your feedback about my performance and his reply was, I do not have much feedback, you are doing just fine. I do not want to give feedback and disturb your rhythm. Well I am happy for that.
Got the relationship with Project Management ? If a team is doing well, do not change the working equations. Its very hard to get a set of people to work together on the long run. If the team is doing well, and there are big plans for the long term, then do not tinker with the team. Just let the Project Manager function with independence.
Now 7 to 9 year back I had a comment from my first appraising manager. I asked what is your feedback about my performance and his reply was, I do not have much feedback, you are doing just fine. I do not want to give feedback and disturb your rhythm. Well I am happy for that.
Got the relationship with Project Management ? If a team is doing well, do not change the working equations. Its very hard to get a set of people to work together on the long run. If the team is doing well, and there are big plans for the long term, then do not tinker with the team. Just let the Project Manager function with independence.
Monday, June 22, 2009
updates for business critical functions vs twitter updates
I have observed many times people are able to make twitter updates with amazing regularity. Stress here is on "regularity" not quantity. But I have seen others who always have an excuse of not having "time" to keep the CRM updated.
Or to put it in another way, it has been hard to make the team do a "business critical" function like keeping the "sales CRM updated" when compared with a "socializing" function like writing personal comments on twitter !
What makes this possible ? I am sure employees mean well. So ...
Well twitter has twitterfox that makes tweeting a breeze. I guess the main reason for this lack of enthusiasm among employees to update a "business critical" function is lack of usable interfaces or in other words the drudgery of existing mechanisms.
So reduce this drudgery and make them more productive by giving them cool widgets and interfaces to your million dollar CRM investments.
Or to put it in another way, it has been hard to make the team do a "business critical" function like keeping the "sales CRM updated" when compared with a "socializing" function like writing personal comments on twitter !
What makes this possible ? I am sure employees mean well. So ...
Well twitter has twitterfox that makes tweeting a breeze. I guess the main reason for this lack of enthusiasm among employees to update a "business critical" function is lack of usable interfaces or in other words the drudgery of existing mechanisms.
So reduce this drudgery and make them more productive by giving them cool widgets and interfaces to your million dollar CRM investments.
Saturday, May 02, 2009
Jopr platform for building management applications and RHQ Project
I just stumbled upon Jopr recently and realized it is the opensource version of the JBoss Operations Network - Platform. That could mean any one trying to build a management platform (monitoring applications / servers) say for JBoss itself or other applications could use Jopr to start with. Definition of Jopr from their website : Jopr (pronounced "jopper") is the open source enterprise management solution for the JBoss Middleware projects. This management project delivers an open source and unsupported form of the JBoss Operations Network product. It provides enterprise administration and monitoring with fine-grained security and an extensible platform base upon which extensions and new administration support can be built. This system is based on and plugin-compatible with the multi-vendor RHQ management project Interesting multi vendor project - RHQ, though collaboratively developed by RedHat and Hyperic. Looks like opensouce community feeds in to RHQ while RedHat and Hyperic sells it commercially in another name. Or did i miss something ?
Friday, February 06, 2009
Software targeted at the SMB Market ?
IT Management software products that are generic have lesser people accepting it than products that are targeting a niche space.
Explaing more about above stmt ...
Then answer why - because of maturity of IT org. Ask your sales force why their people do not keep their sf updated ? laziness / lack of process ? Same way complex software will not be used in an organization, even if they are free
Explaing more about above stmt ...
Then answer why - because of maturity of IT org. Ask your sales force why their people do not keep their sf updated ? laziness / lack of process ? Same way complex software will not be used in an organization, even if they are free
Thursday, January 29, 2009
What is SaaS for the Big 4 of IT Operations ?
For all of the last 20 years, the Big 4 have dominated the Enterprise IT Management market. They have contributed a lot to the innovation with the level of engagement they had with customers and end users. However a lot of these learnings have become best practices and common knowledge and the barrier to entry of new players have reduced.
However these organisations itself have not evolved with the times and stick to the high cost business model where consultants and marketing teams still play a major role in winning and maintaing customers.
Now with the slow but sure evolution of Software to move as a Service (SaaS), these IT Management vendors are finding it hard to adopt and move towards a SaaS model for delivering IT Management. The biggest challenge for these vendors seem to be :
1) Technology
2) Business Model
Technology Challenge:
The biggest challenge from the technology point of view is their agent based approach to monitoring and the product Client (GUI). Most of the software they use is an agentbased model, which had its benefits in the early days when packaged applications did not have a management instrumentation of its own. Another technology challenge is their outdated Client Interface. They also have to work on a web client to make it work for a SaaS model.
The technology part is probably something they can overcome over a period of time, but ofcourse they have the risks associated with rewriting software code.
The biggest challenge for them is changing the Business Model.
Having being addicated to getting 6 and 7 digit software license revenue , they will find it hard to move to the norm that is come to be seen in the SaaS model - Subscription based pricing. Subscription based pricing involves getting license cost per year and more predominantly on a monthly basis.
The bigger problem is for those who are Public Companies. They can't afford to show a lower revenue for a quarter, let alone for a whole year due to shareholder pressure. This is the case even though it is clear that Subscription model prices even out on the long run.
The movement of applications to the cloud is sure. The dominance of the Big 4 in the past is an established fact. However the emergence of a Smart Fifth is also a possibility;
..... unless the Big 4 and other vendors are willing to be more agile.
However these organisations itself have not evolved with the times and stick to the high cost business model where consultants and marketing teams still play a major role in winning and maintaing customers.
Now with the slow but sure evolution of Software to move as a Service (SaaS), these IT Management vendors are finding it hard to adopt and move towards a SaaS model for delivering IT Management. The biggest challenge for these vendors seem to be :
1) Technology
2) Business Model
Technology Challenge:
The biggest challenge from the technology point of view is their agent based approach to monitoring and the product Client (GUI). Most of the software they use is an agentbased model, which had its benefits in the early days when packaged applications did not have a management instrumentation of its own. Another technology challenge is their outdated Client Interface. They also have to work on a web client to make it work for a SaaS model.
The technology part is probably something they can overcome over a period of time, but ofcourse they have the risks associated with rewriting software code.
The biggest challenge for them is changing the Business Model.
Having being addicated to getting 6 and 7 digit software license revenue , they will find it hard to move to the norm that is come to be seen in the SaaS model - Subscription based pricing. Subscription based pricing involves getting license cost per year and more predominantly on a monthly basis.
The bigger problem is for those who are Public Companies. They can't afford to show a lower revenue for a quarter, let alone for a whole year due to shareholder pressure. This is the case even though it is clear that Subscription model prices even out on the long run.
The movement of applications to the cloud is sure. The dominance of the Big 4 in the past is an established fact. However the emergence of a Smart Fifth is also a possibility;
..... unless the Big 4 and other vendors are willing to be more agile.
Reasons why Subscription Model Pricing is Better than Perpetual Model
Is Subscription Model Pricing is Better than Perpetual Model ? Well I am sure we can argue it either way, but let me give probably some non-obvious reasons why Subscription is better.
Well before that let me define what each is. Subscription Model Pricing is where you charge the customer a specific amount for using your services or product every year or month. In SaaS Services monthly billing ius very common.
Perpetual License Model or "License Model" usually default Licnesing Type and more popular one in traditional software, is where you pay one time for using the software and never have to pay again. This normally does not entitle you for upgrades and support. That comes as an additional.
It is common to have a formula like
Perpetual Model Price = 2.5 Times Subscription Prices + 20% Annual Maintenance & Support
Now what are the not so obvious benefits of Subscription Model ?
1)If you are a product company, by embracing a Subscription Model, you are making yourself ready for the movement to Software as a Service. Normally in a SaaS model, Services are offered in the Subscription Model as seen in Zoho and other services.
2) Since customers pay you monthly, renewals or "subscription money" will bring in a more steady revenue stream in the long term.
3) Since you are paid only monthly or yearly, you do not get access to the whole loot in one go :-) You tighten your spending in the begining itself and hence will eventually have a better run business. This is because lesser money comes upfront and it gives you that discipline in keeping expenses in check.
4) You make a more useful service. You earn the renewal money by making your customer happy. This is really critical as when you see users dropping off, you know your service is lacking. You can take immediate action. This added advantage helps you creating a better product in the end.
Well before that let me define what each is. Subscription Model Pricing is where you charge the customer a specific amount for using your services or product every year or month. In SaaS Services monthly billing ius very common.
Perpetual License Model or "License Model" usually default Licnesing Type and more popular one in traditional software, is where you pay one time for using the software and never have to pay again. This normally does not entitle you for upgrades and support. That comes as an additional.
It is common to have a formula like
Perpetual Model Price = 2.5 Times Subscription Prices + 20% Annual Maintenance & Support
Now what are the not so obvious benefits of Subscription Model ?
1)If you are a product company, by embracing a Subscription Model, you are making yourself ready for the movement to Software as a Service. Normally in a SaaS model, Services are offered in the Subscription Model as seen in Zoho and other services.
2) Since customers pay you monthly, renewals or "subscription money" will bring in a more steady revenue stream in the long term.
3) Since you are paid only monthly or yearly, you do not get access to the whole loot in one go :-) You tighten your spending in the begining itself and hence will eventually have a better run business. This is because lesser money comes upfront and it gives you that discipline in keeping expenses in check.
4) You make a more useful service. You earn the renewal money by making your customer happy. This is really critical as when you see users dropping off, you know your service is lacking. You can take immediate action. This added advantage helps you creating a better product in the end.
Code Rewrite : why it is bad ?
Well what is code rewrite ? It is a strategic decision to scrap all code you have ever written for a software product and rewrite it from scratch, thinking that will give you better quality code & will be easy to maintain.
Stay away from rewriting a whole code base thinking the old one is terrible.
I have personally seen that being a bad decision many times. Joel on software has very interesting real stories to tell here.
Why it is bad ? Here are some reasons I have felt -
1) Lots of developer effort going down the drain.
The old code base say it was 3 to 5 years old has had lots of development effort already go in. Notwithstanding while writing the new code base do you have better developers and designers than what you had previously ? Otherwise you could end up with a code that may no seem readable and hence maintainable but not really superior.
2) Quality Assurance person's time. Your QAs would have already done lots of testing. Now, to get back a fresh piece of code to that quality is not a simple task. Have you documented all test cases / use cases ?
Fresh Code to reach the quality of Old code with all Use Cases handled will take time.
3) What about the hundreds of invaluable testing already done by customers ! Think about it. There are lots of customer environment specific issues. How did you fix it or what was the fix ? Can you reproduce that in your labs and support it ? BTW those 100s of small enhancements took that extra week each to support.
4) If you are going to maintain the old one too, then its going to be a bigger nightmare because you are going to distribute your work on 2 code bases. That is going to slow you down.
5) Remember Customers do not buy your software after reading your code. But they want the software to work, otherwise they are going to complain. Complain real loud.
6) When you rewrite code, cultutrally people expect a better featured product from what was previously present. Most people comment on the GUI as that's all they really see. Now these expectations futhur increase the time taken to go to market.
Ofcourse code rewrite for a small piece of software is absolutely fine. The above post is more from a perspective where there is a major rewrite from scratch of a full software product maybe which had over 500 man years of development effort.
So what should I do when I have feel there is a need to rewrite code ? Well Follow the 80 - 20 rule. Most probably 80% of the problems are caused by 20% of the code. Even here first identify the problematic code and be very straight to the point on how you fix. Do only Design fixing where it is absolutely needed. Fix only the flow problems or the design problems - meaning creating interfaces, and deciding on the right approach etc and donot take up anything that does not need to be touched. Do not evaluate new frameworks especially for DB persistence etc. Also look at the revision history. If the code has not been touched for years, then you may not have to even change it as it is actually working.
To summarize I guess code rewrite is bad especially for large projects. The main reason being the difficulty to get the new code to reach the quality and richness as the old.
Stay away from rewriting a whole code base thinking the old one is terrible.
I have personally seen that being a bad decision many times. Joel on software has very interesting real stories to tell here.
Why it is bad ? Here are some reasons I have felt -
1) Lots of developer effort going down the drain.
The old code base say it was 3 to 5 years old has had lots of development effort already go in. Notwithstanding while writing the new code base do you have better developers and designers than what you had previously ? Otherwise you could end up with a code that may no seem readable and hence maintainable but not really superior.
2) Quality Assurance person's time. Your QAs would have already done lots of testing. Now, to get back a fresh piece of code to that quality is not a simple task. Have you documented all test cases / use cases ?
Fresh Code to reach the quality of Old code with all Use Cases handled will take time.
3) What about the hundreds of invaluable testing already done by customers ! Think about it. There are lots of customer environment specific issues. How did you fix it or what was the fix ? Can you reproduce that in your labs and support it ? BTW those 100s of small enhancements took that extra week each to support.
4) If you are going to maintain the old one too, then its going to be a bigger nightmare because you are going to distribute your work on 2 code bases. That is going to slow you down.
5) Remember Customers do not buy your software after reading your code. But they want the software to work, otherwise they are going to complain. Complain real loud.
6) When you rewrite code, cultutrally people expect a better featured product from what was previously present. Most people comment on the GUI as that's all they really see. Now these expectations futhur increase the time taken to go to market.
Ofcourse code rewrite for a small piece of software is absolutely fine. The above post is more from a perspective where there is a major rewrite from scratch of a full software product maybe which had over 500 man years of development effort.
So what should I do when I have feel there is a need to rewrite code ? Well Follow the 80 - 20 rule. Most probably 80% of the problems are caused by 20% of the code. Even here first identify the problematic code and be very straight to the point on how you fix. Do only Design fixing where it is absolutely needed. Fix only the flow problems or the design problems - meaning creating interfaces, and deciding on the right approach etc and donot take up anything that does not need to be touched. Do not evaluate new frameworks especially for DB persistence etc. Also look at the revision history. If the code has not been touched for years, then you may not have to even change it as it is actually working.
To summarize I guess code rewrite is bad especially for large projects. The main reason being the difficulty to get the new code to reach the quality and richness as the old.
About this blog
This blog is going to talk mainly about Performance Management, Product Management, SaaS, Application Performance Management, Business Service Management and other interesting things that I come across.
Please note this is a personal blog and the content I write in this blog does not represent the company I work for.
Please note this is a personal blog and the content I write in this blog does not represent the company I work for.
Subscribe to:
Posts (Atom)