Laws of Motion (in Product Management)

Mass is a measure of inertia. The principle applies for innovations, especially around software products, too. Will-solve-world-hunger-idea that is too grandiose, complicated and resource consuming will take off far sluggishly than the one that is simple, easy to understand (preferably can be drawn without having to wipe the white board even once) and needs less resources (at least initially). Therein lies an important ingredient of turbo-charging the innovator’s probability of success.

An idea that has taken off will steadily gather momentum (yet another law of motion here) and will accelerate as sponsors see (and perhaps even feel) the initial outcome. The idea implementation will react with an equal (but not opposite) enthusiasm to the sponsor’s optimism.

SaaS: The Systems Democratizer

As more people start producing a class of goods or services, the supply side deluge ensures that the price keeps coming down. Lower price creates higher demand but since the supply still outstrips it, the price keeps falling. At the state of equilibrium, the marginal cost of production equals the marginal revenue from a sale. This is economic democratization wherein the supply side ensures greater affordability of a certain good.

In the past decade or so, the same economic principles have held good in the case of software too. At college, we had to go to the lab, program the computer to run linear programing optimizations and go next day to collect the results. All this while there was a queue. Today it is available on the desktop. During an internship with a broking firm when in Business School, I had to book a slot for using the only machine that had Microsoft Office installed in it!

The plummeting price of complicated systems have created the democratization of information systems. This phenomena has ensured that even small and medium businesses benefit from system driven productivity, which was earlier reserved only for the elite giant corporations.

Have we reached the balanced state yet? I guess not. If one looked at the TCO (total cost of ownership) of software systems today, a bulk of the costs are made of hardware, networking, data centers and general software and environment maintenance. These are the items that shall fall prey (in terms of costs) in the next wave of what I choose to call systems democratization.

The catalyst that will lead this phenomena will the Software as a Service (Saas). Its time has come and the precariously posed world facing a recession will accept it with open arms.

Nothing is more powerful than an idea whose time has come…

Technorati Tags: , , , , ,

Outsourcing Product Development

The pressure to reduce costs and the availability of engineering talent in low-cost locations is pushing several organizations to outsource their product development. The modus-operandi and interaction patterns in an outsourcing situation is a little different from that resulting from off-shoring. The primary difference stems from the latter being a geographic extension of the same organization while the former results in dealing with a different legal entity. This inherent difference in interaction standings require a different focus in creating and writing requirements and the development process.

Creation of better release plans: Organizations offshoring must realize upfront that the cost against the potential savings is the sacrifice of flexibility. Changing of requirements and even tweaking of a feature will result in a change request generated that will have cost (for outsourcer) and revenue (for vendor) ramification. It is therefore imparitive that a very well defined release plan be created and adhered to.

Devlish Details: Organizations that have product management and engineering very well integrated as a team need not spend hours producing pristine requirements. However, in a situation where the requirements will be thrown over a wall to land a few thousand miles away it is a necessity to create detailed requirements. Interestingly, several organizations take this as an opportunity to inculcate a discipline of writing good Use Cases from their product managers and business analysts.

Work out the translator math: Most vendor companies employ business analysts (or those who are euphemistically called “functional experts”) in development projects. These resources come at a higher cost than the engineers. Primary function of this team is to translate the requirements from the outsourcing firm to the vendor. While at first glance this may look redundant, it is not – mainly because of the asynchronous nature of communication that the engagement creates. This layer may take some burden off from the firm outsouricng in the area of creating detailed requirements. It is important to work out the marginal cost between adding a business analyst from the vendor vis-a-vis having a product manager from the outsourcer doing the same task.

Provide Wireframes: Creation of wireframes – either low fidelity ones or high fidelity prototypes – fall in the gray area between product management and engineering. In an outsourcing situation bring this back into the fold of the outsourcer. It is important – even if in-house engineers are required – that the vendor be provided with at least a low fidelity prototype of what is desired. This becomes a part of the requirement.

Cleanup the house: Many products have internal dependecies that must contribute towards fruition of a release. These must be handled and resolved by the firm that is outsourcing. It is not sufficient to merely identify these dependencies. Vendor organizations will never completely own up to these ones.

Two processes cannot work: Outsourcing vendors are mostly all certified for processes like CMM, ISO etc. While this is a good marketing qualification for the vendor, it may not necessarily translate into value for the organization outsourcing product development. It is always prudent to ask the vendor that they adopt any existing process that the outsourcer may already have. Processes clashing with each other is a much more avoidable situation than personalities clashing.

It is important to keep in mind that outsourcing (or even offshoring) is not a free lunch. And that the benefits are not equal to the cost arbitrage. The benefits are significant but they should be adjusted against the implicit costs of sending work that would have been done across the hallway rather than somewhere a few thousand miles away.

Technorati Tags: , , , ,

Community Engagement and Gathering Requirements

The progress of using Web 2.0 as a mechanism of gathering and prioritizing requirements has gathered momentum. Here is another example of a neat tool that facilitates.

In the context crowd-sourced requirements, the challenge for the crowd-master (the Web 2.0 avatar of the Product Manager) is to move the blue quadrant population to the pink. Any ideas?


Technorati Tags: , , ,

First Day First Show: Google Chrome

I installed Google Chrome just a while back and here are some quick first reaction

  1. There is nothing in the browser that wows me. It looks Google-ish, as it was expected to and I am not sure if Google will welcome skinning its browser enthusiastically. I like my browsers colorful and this light blue themed browser is not much of a spirit lifter.
  2. The fact that Google poached Firefox engineers to build this is visible in certain implementations. The bar that pops up and offers to remember your password for a given site is just a copy-paste of Firefox
  3. Chrome very quickly imported all my bookmarks from Firefox. However there is a shortcoming (vis-a-vis Firefox) in the way it searches in the address bar. For example, to get to this blog you will have to type “subrataalpha…” for that to show up. You may remember this blog by its title but typing “Confessions of a…” will not take you to this blog’s url.
  4. The lack of extensions (yet) is killing. There are many sites (including some of our own web products) that I run using the “IE Tab” extension in Firefox, which I cannot in Chrome. However I think quite soon a lot of the Firefox extensions will get ported into Chrome, so day may not be far.
  5. Integration of Google search within the address bar is a nice touch. And thanks to Google for allowing to choose other search engines (not that I will but the magnanimity of the gesture is nice).
  6. The ability to open multiple pages is a good thing. I tend to read several websites for news first thing in the morning and having them all open up on startup is very welcome. Not so cool is the setting of reopening pages. Each time a Firefox session with multiple tabs is closed, the question pops up about how would the user want it to reopen next. In Chrome that setting is done once and cannot be changed as a workflow completion item.
  7. Naughtly google always snooped on my mails to throw up relevant ads on a page. From the terms and conditions of the browser usage it is apparent that it now owns everything I choose to send through it. Are you listening George Orwell, wherever you are?
  8. I have opened several tabs simultaneously and pounded away at the keyboard for a while now. Chrome has held up elegantly to that nuisance.

Question: Did the world actually need two competing (and perhaps equi-capable) open source browsers?

Content and Delivery in Software Product Demos

Part of a Product Manager’s trade is to perfrom demos. Quite often requestors of the demo and the Product Manager mistakes a demo to mean training. It is extremely important to differentiate between the two because the content and delivery are different for each. I will focus on the demo and leave the training for later.

There is a reason why a product is built. The most important being to satisfy a customer need – a pain-point if you will. And a collection of such pain-points become the fulcrum of a product manager’s demo. Every show and every tell must relate back to them. Contrast this with a training, which is essentially addressing the “how” problem. That is, how a product works. On the contrary, the product manager’s demo is the “why” story. That is, why does this product exist. Resonance of any or many of the pain-points with the audience guarantees rapt attention and exponentially increases the probability of acceptance. Creating the content for a demo is not trivial and this unswerving attention on the “why” is a nice way to focus.

Delivery is another important aspect of a demo. Anyone who has watched Steve Jobs at MacWorld would exactly appreciate why delivery is important. The happy marriage of content and delivery is called a script and I strongly recommend that all major demos have one. If showing the “why” is more important than showing the “how”, more important is weaving the “why” story into a – well, story. All throughout the ages people have huddled in street corners, in coffee shops, around fires, around grandpa to hear stories. We are genetically wired to respond to stories better than anything else. So script your demo into stories and it is okay to be animated and a little theatrical while speaking. Introduce a bit of drama by pretending you are mentioning cool features (mostly what are called bells-and-whistles) almost as an afterthought (“Oh, I almost forgot. The portfolio search box remebers those portfolios you have pulled up most often so it prompts you with them just as you activate the drop-down. If these are not what you are looking for, don’t worry, you can do the normal search without breaking anything”). And for heaven’s sake have humor in the demo (I have seen self deprecating humor too, where the demo-er goofs up on purpose to show that the system can elegantly handle such situations).

Product Managers demo-ing a product must bring a different perspective to the audience. Otherwise we might as well send in the trainers.