Identifying new Products in the SaaS Model

In the on-premise world, first came point products. This had success as a specific problem was solved very well. Lower price points. Tactical sale (eg. sell to engineer vs sell to CIO). Less noise in the GUI.

Then came integrated suites and bloatware :-)

In the On-Demand world, follow the same strategy. Do point products first. But do it on a platform that can bring all of it together in to one GUI, in future. Or follow the less is more strategy.

Partner engagement from a non-financial standpoint

Managing the partner channel is hard, especially if you are a technology company. The time needed and the slow pace to build lasting relationships need special focus and is normally not your strong point.

When signing up partners, first thing to realize is you are not signing up just the CEO of the company. You are expecting his sales to chime-in for you. So help her. That means, signing up a partner is just the first step. Make sure you help train her team and provide all support they need to keep them productive.
You got to even ensure high mind share within their sales team about your company.
That could of course mean anything from cheap tactics to well meaning and useful things like sending brochures about product, news updates, conduct regular trainings and provide outstanding support.

Outstanding support!

Based on the location of your partner, you need to be accessible to them, when ever or using whatever medium. That means, be accessible via phone, email, chat or in-person. A single point of contact is invaluable.
Markets are complex. Some things work well in some markets and some things don't. However make sure the best practices of one market gets shared to other markets seamlessly via your partner portal. That brings us to the topic of communication.

Your partner portal must rock!

The partner portal should share news about the product obviously, but more importantly about product sales triggers (eg. government legislation like Italian Privacy Regulation) in your other partner countries and be the single source of the truth for your partners.

BMC acquires Cordiant for End user Experience Management

BMC acquires Cordiant for ~ $125 million for their End user Experience Management capabilities.

http://www.bmc.com/news/press-releases/2011/BMC-Software-Acquires-Coradiant-Inc.html

What is Cloud Computing ?

Cloud computing is all about the maturity to allow your core data to leave the immediate boundaries of where the data is generated and consumed. Its about the data. Its about the processing environment. Cloud computing is not just SaaS or Amazon or about Azure etc. Those are the ways to implement it.

@NY and SFO for the ManageEngine User Conference

I have got the opportunity to present the ManageEngine Product Roadmap, at the ManageEngine User Conference.

NewYork
March 22-23, 2011
The Park Central Hotel,
870 Seventh Avenue at 57th Street,
New York, NY 10019,
www.parkcentralny.com


San Francisco:
March 29-30, 2011

The Marriott Courtyard – Downtown,
299 Second Street,
San Francisco, CA 94105,
415.947.0700,
www.courtyardsanfrancisco.com


Check out the user conference website for details.

How To Kill Innovation, SVPG Blog, Six Sigma?

A few years back, I had the opportunity to be in one of the workshops conducted by Marty. Here is a good write up about how Six Sigma could stifle innovation. Especially in IT Companies.

Last week I ran into two different software technology companies (neither in Silicon Valley) that had just recently brought in Six Sigma consultants. This caught me by surprise because it¹s been a very long time since I heard of a technology company even considering this. I'm hoping this was an anomaly, but in the spirit of "those who cannot remember the past are condemned to repeat it," I thought it's important to discuss quality-centric methodologies like Six Sigma.
In the manufacturing world especially, if your company is struggling with quality or cost issues, then Six Sigma can be very appropriate. It is based on a set of quality management techniques and practices that can significantly reduce costs and defect rates.
Unfortunately, many of those that advocate Six Sigma believe that the principles should be applied throughout the organization, for virtually any business process. But what can be good for removing defects in a manufacturing process can completely destroy the product discovery process and software development.
Please know that I am dead serious when I say this: for companies that depend on innovation, these well-intentioned but misguided people can destroy your company.
In our industry, we live and die by our ability to innovate. Yes, quality is important, but it's only interesting to even discuss quality if you've come up with a product people want.
Do you remember the old Motorola, the company that used to be "driven by a passion to invent?" How about 3M, the company that was based on encouraging initiative and innovation among its employees? And GE, the company that really did used to "bring big ideas to life." And Sun, at one point they were incredibly creative and relevant. Same with Intuit, a company that was founded on a commitment to delight customers.
What all these companies have in common is that they all used to be widely admired, consistent technology innovators. Until Six Sigma took over. Then their innovation virtually disappeared. It all became minor incremental refinements, and in our business, that'll only take you so far.
Now of course the intent of Six Sigma was never to kill or stifle innovation, but the unintended negative consequences to an organization of trying to apply Six Sigma dogma beyond the processes it is appropriate for are so profoundly damaging that they dwarf the benefits, especially over time. Yes, you can save some costs in the short-run, but you'll soon start to see the consequences in the top-line as significant new product introductions slow to a crawl, and customer reactions to your products disappoint.
Visit a technology product team in a Six Sigma company and you'll find people that have had the creativity and initiative drained right out of them. It's all about avoiding the bureaucracy and the pain associated with any deviation. And it's no surprise that they've had a hard time retaining the creative people ­ the ones they need to invent their future successful products.
For tech companies, it's just not about eliminating defects and inefficiencies. It's about discovering and delivering products and services that customers love. Don't fall into the trap of confusing building the product right, with building the right product.
If your goal is to win the Malcolm Baldrige National Quality Award, then maybe Six Sigma is for you, but if your goal is to create winning products, you need to optimize your organization instead around product discovery and encouraging just the sort of creativity and initiative that enables people to think and act differently.
It's not just Six Sigma consultants that can try to apply their techniques to areas that don't make any sense. I¹ve also seen some overzealous Scrum advocates try to apply the process to areas that it wasn't designed for and make a mess out of things as well. But honestly I¹ve never seen damage to a company's ability to innovate as deep and lasting as what has happened to companies that try to implement Six Sigma from the top down.
So if you find one of these Six Sigma guys wandering the halls of your tech company, grab them by their black belt and toss them back where they came from.

http://www.svpg.com/how-to-kill-innovation/

JSR for Java 7 and Java 8 approved ! :-(

Here is a good article covering the mood of the JCP process. Apache and Google voted NO. Others complained and voted YES. It looks gloomy thinking what Oracle is going to do to Java. Its time to learn the next programming language Python or Ruby guys and gals.

Oracle tinkering with the Java licensing could mean many companies will think twice before using Java going forward. Atleast ISVs, as the majority do not wants to pay Oracle for the application server JVM and the database. Oracle Database is just great.... Otherwise it is like getting charged an arm and a leg:-)

This along with the nature of today's programming being more of building Web Applications, brings other compelling reasons on why users need to learn other programming languages. Ruby (Ruby On Rails) or Python could be good options to shift to. The new generation programming languages bring in more cool features (that improve developer productivity) that are lacking in Java.

Richness Vs Simplicity in Products

Richness is a great feature for your product. If your product is rich in capabilities, then it will have all the options 90% of users will ever need. However you may end up building a product (say user interface) that is hard to use, because of the plethora of options you have added.

Simple products have lesser features. It will be just good enough for many, to derive a business case out of it. It can sell better on its own, without much training. This is great if your goal is to just enjoy the journey of building products.

While building products you can decide whether you want to tilt towards richness or simplicity of the product.

If your goal is to sell software with no fuss, no sales people, then, "Less is more" may be a good strategy.

Companies may choose to keep products simple so that they can reduce support and training cost and enjoy the fruits of higher productivity in their organizations.

Scala an alternative to Java for programming

Scala as an alternative programming language looks credible.

Being a Java programmer, my summary is going to be more from that perspective. Java developers could look at it as a replacement for "javac" or in simpler words, a new ".java File parser" for Java which supports a new Programming style. Of-course there are scala (Java) classes /APIs to support that. It finally generates Java code and byte code ! That's similar to what JRuby or groovy does. It runs on the JVM.

Hence it could look like a language created to solve the top X problems perceived in Java from a programmer productivity point of view, rather than a language built from the ground up from a performance / stability standpoint. That is fine as long as it is done well, overall. As a matter of fact, it could make sense, as the Java strength is the maturity of the JVM.

Another way to look at Scala is something that Java itself did not do till date. Making more intelligent use of the compile time knowledge. It would be great if Oracle could bring this to the table. Another main capability is Scala bringing in more previously framework features right in to the programming language.

Some cool stuff : Lots of stuff that could be done in Java itself in compile time has been done.

- Primitives treat very very large objects the same way as smaller types. [Java fuss] Why have BIGINTEGER class for it ? Make it as simple as handling int values.
- maps contain a - calling a method in operator notation : In Scala everything is a function. Including operators. At-least that's what they want us to believe.
- Lots of smart compiler time gimmicks like the "Conversion Method" eg. he talks about that avoids an extra public static method call to create a Wrapper Object just for compilation sakes. This can reduce calls to Integer.parseInt.... It works by picking up just one resolving identifier from scope. if more present, it gives error.
- Using three "=" sign is a new syntax introduced for assertions. Eg. assert (result === 17)
- Usage of triple quotes to insert CSS etc are good syntactical makeup.
- Everything is a method. so =, +, == etc are also treated as methods.
- Duck typing : is the ability to call methods of another class, with the same method structure of a class, even though they have no common super object. Same method structure eg. getLength method in MyOwnClass.java and Array.java can be called by a parent method easily.
- Scala's additional features will reduce the need for tools outside of the language (eg. Spring Framework) and this will help programs become more maintainable.
- You can use all the Java APIs inside Scala as its finally generating Java Code. Hence you still have the capability to use all Java APIs out there, inside Scala. No re-inventing the wheel.

Anecdote :
Of course there are arguments that, many of the design patterns spread by the gang of four were actually programming language constructs and not patterns.

Some of the things that make me feel a bit edgy are :

a) It still uses the JVM. Hence we still run the same risk from a licensing perspective (from Oracle).
b) Not sure if it is mature enough for projects that run for over five years with medium sized teams. I stress on this as I have seen that Java as a programming language is very useful in this case as it reduces the effort to make changes or introduce changes. This is something I feel a company like us should really worry about long term. Writing "Hello World" programs are not enough. For eg. imagine the flexibility of "threadlocal" as a simple concept that allows SAS magic on any mickey based products etc.. Programming platforms should support that level of "insight" built in.

c) Debugging will look odd : The runti me is as stable as the JVM, as its finally byte code. The fact that your code will be called by a wrapping Java class will make it feel odd. For peculiar errors, you may actually go to the Scala generated Java files. Look at it like, sometimes we go to the generated .java Servlet file when trying to debug a peculiar problem in the JSP.

d) Being a Wrapper around normal Java code means that it is not superior than Java performance, but could still strive to be better than other programming languages like Ruby or python from a performance standpoint.

Anecdote :
Nearly all languages first bootstrap the new language in some existing language, and then rewrite the compiler in the new language they create. So Scala is written in Scala and Javac in Java.

References : Video on Scala named "The Feel Of Scala" by Bill Venners. Bill Venners is a very credible Java guy (Artima fame), great presentation style.

Product Objective

We must categorize a product objective clearly. There is a diff between an Add On for a product, Add On Product and a Standalone Product.

Add Ons help complement your overall Product portfolio. "Add On Products" help complement the overall "Corporate Product Strategy". That is, they complement the standalone products.

Standalone Products need to have the depth that helps it sell on its own. These Standalone products are more strategic. These main stay products could be the platform on which the other categories of products revolve.

For Add On Products, Less is More works just fine. Some products are meant to be Add On  products. Identify and mark them early.

Add On Products help sell more of the Standalone Product. They are sometimes more of a checklist item, and does not need too much depth in capabilities. These checkbox services could also be capabilities that help market the core offerings and reduce the actual cost of brand building and market acquisition.