Friday, September 28, 2012

Leadership Skills for Innovation

Innovation at the organization levels starts requires a strong leadership. People at all levels are creative & have ideas - many of them are afraid of expressing their creativity and express their ideas for various reasons (see Unleashing Creativity: Common mind blocks ), but the bottom line is that employees are innovative.

If an organization is not innovative, then the problem lies squarely on the top leadership: CEO, COO, etc

Having laid the blame on the top management, the question arises - what should be done to infuse innovation. The answer to that question is not easy, but there are some obvious starting points.

1. Start with a vision for Innovation & Change

You cannot expect your team to be innovative if they do not know the direction in which they are heading. Innovation has to have a purpose. It is up to the leader to set the course and give a bearing for the future.
You need one overarching statement that defines the direction for the business and that people will readily understand and remember.

Great leaders spend time illustrating the vision, goals and challenges. They explain to people how their role is crucial in fulfilling the vision and meeting the challenges. They inspire men and women to become passionate entrepreneurs, finding innovative routes to success.

2. Fight the fear of change

Innovative leaders constantly evangelize the need for change. They replace the comfort of complacency with the hunger of ambition. They'll say, "we are doing well but we cannot rest on our laurels, we need to do even better." They explain that while trying new ventures is risky, standing still is even riskier. They must paint a picture that shows an appealing future that is worth taking risks to achieve. The prospect involves perils and opportunities. The only way to get there is by embracing change.

3. Think like a venture capitalist

VCs use a portfolio approach and balance the risk of losing with the upside of winning. They like to consider lots of proposals. They are comfortable with the knowledge that many of the ideas they back will fail. These are all important lessons for corporate executives who typically consider only a handful of proposals and who abhor failure.

4. Have a dynamic suggestion scheme

Great suggestion schemes are focused, easy to use, well resourced, responsive and open to all. They do not need to offer huge rewards. Recognition and response are generally more important. Above all, they have to have the wholehearted commitment of the senior team to keep them fresh, properly managed and successful.

5. Break the rules

To achieve radical innovation you have to challenge the assumptions that govern how things should look in your environment. Business is not like sport, with its well defined rules and referees. It is more like art and is rife with opportunity for the lateral thinker who can create new ways to provide the goods and services customers want.

6. Give everyone two jobs

Give all your people two key objectives. Ask them to run their current jobs in the most effective way possible and at the same time to find completely new ways to do the job. Encourage your employees to ask themselves: 'What is the essential purpose of my role? What is the outcome that I deliver that is of real value to my clients (internal and external)? Is there a better way to deliver that value or purpose?' But most people never ask the question.

7. Collaborate

Many CEOs see collaboration as key to their success with innovation. They know they cannot do it all using internal resources. So they look outside for other organizations to partner with. A good example is VBLOCK. EMC, VMWare & Cisco collaborated to crate VBLOCK

8. Welcome failure

The innovative leader encourages a culture of experimentation. You must teach people that each failure is a step along the road to success. To be truly agile, you must give people the freedom to innovate, experiment and to succeed. That means you must give them the freedom to fail, too.

9. Build prototypes

Develop an appetite to test new ideas. "Don't debate it, test it," Should be the motto. Try the new idea at low cost in a section of the market and see what the customers' reactions are. You will learn far more in the real world than you will in the test laboratory or with focus groups.

10. Be passionate

Focus on the things that you want to change, the most important challenges you face and be passionate about overcoming them. Your energy and drive will translate itself into direction and inspiration for your people. It is no good filling your bus with contented, complacent passengers. You want evangelists, passionate supporters. You want people who believe that reaching the destination is really worthwhile. If you want to inspire people to innovate, to change the way they do things and to achieve extraordinary results, then you have to be passionate about what you believe in and you have to communicate that passion every time you speak.

Marketing Functions of Product Management

In the world on enterprise software, Product Managers have to wear several hats - one of them is a "Marketing Hat", and perform marketing functions. Product managers support marketing in following areas:

1. Retain existing Customers. 

  • Add new features/functionality: Listen to customers and enhance current products
  • Product Sustenance  Direct customer support teams when needed
  • Provide upgrades: Encourage customers to upgrade to newer & better products
  • Develop product integration solutions: Integrate current product with other adjoining products for deeper customer penetration

2. Selling more to all Customers

  • Add new products into the solution mix.
  • Increase the wallet share

3. Establishing the Brand Value

  • Deliver on the promise: Ensure products perform as promised
  • Run Beta programs. 
  • Match the price the product with customer affordability
4. Acquire New Customers

  • Do product demo
  • Support product road shows
  • Support customer POC
  • Develop Marketing Collateral: Help develop Product Videos & white papers

Not all product managers do all the above marketing activities, but these are the most common marketing activities.

Thursday, September 27, 2012

The Value of Design: Key to product success

What's the first thing a customer sees in a product? What creates the first impression in the customer mind? What influences the final buying decision?

The answer to these questions is Product Design.

To illustrate this point, consider two cell phones in 2008: Blackberry and Google Nexus. Both the phones had same functionality. Users can do all the functions on both the phones, but the customers just flocked to Nexus. Even today, Blackberry phones can do pretty much everything an iPhone can do, but customers still prefer the "touch" phones over the full keyboard phones. There are innumerable examples of how companies used product design & user experience to win in the market place.

As a product manager, let me explain what are the aspects of product design, which when done right leads to a winning product.

A new product must create a positive response at the first interaction with the product. This can be achieved with product design. In the world of physical products this is called as "Industrial Design" and "User Interactions", in the world of software, it is called as "User Experience (UX)"

Product design plays a major part on customers' buying decision, therefore it important to know various aspects of design that must be considered during the product development stage.

As a product manager, let me explain what are the aspects of product design, which when done right leads to a winning product. During the design stage, there are two major aspects of design: Features of Design & Value of Design.

Features of Design:

Features of a Design essentially creates the necessary conditions of the product and product development. There are five aspects to this:

1. Feasibility.
2. Utility
3. Desirability
4. Usability
5. Affordability

Feasibility is essentially the limiting factors - i.e, defining the boundary within which the product must be designed. It is important to identify the boundary or the limiting conditions  which the design teams have to operate. The five common areas of feasibility are:

1. Technical Feasibility: Establishes the technical limitations.
2. Economic Feasibility: Establishes the cost limitations
3. Legal Feasibility: Establishes the legal limitations, including Intellectual property rights
4. Operational Feasibility: Establishes how well the product works or solves the problem.
5. Schedule Feasibility: Establishes the timelines within which the product must be developed

Utility is usually a product requirement and it sets the base line for the product in terms how well the product should perform, and what activities/jobs/uses the product must do. For example, A Swiss Knife as mulit-utility device - because it performs many functions.

Desirability is a psychological factor which drives human behavior. In product design, desirability is the ability to make customer buy the product. There are several psychological factors that drive desirability - depending on the market demographics. I.e, each market segment has a different  psychological factors that drive desirability. Understanding this correctly and delivering it will make customers say "Wow!" by just looking at the product.

Usability defines how usable the product is. Usability is all about getting the right user experience. Usability of a product has to be developed from the customer perspective. One needs to understand how customers use the product and then look at various means/options to enhance that.

Affordability helps define the selling price. Affordability is a measure of how many customers are willing to pay what price for the product. A highly priced product will have less number of possible customers, i.e., low affordability; while a low priced product will have large number of possible customers. So for a given product and market segment, the affordability for products changes.

Value of Design

Product has value only when buyer sees an advantage in using the product. For example Vertu makes designer cell phones which has an exclusive set of customers. The cell phone from a functionality point of view is same as a Nokia phone, but it is design that sets Vertu apart.

The Value of design is seen when it:

Changes the purchase criteria: Make people choose the product based on user experience over product functionality. iPhone & Vertu is a classic example of this. Mac Book Air is also a good example where product design (form factor) changed customers' buying decision.

Enforces Brand Experience: Every brand is a promise. The product design must deliver on that promise, which create experiences during interactions with handling the product for the first time. For example, Bose sound systems must deliver on the brand of offering superior audio quality.

Segments the market: Product design by itself can create a new segment in the market. For example, Vertu created an upmarket, designer cell phone market segment. Bose created elegant and high-end audio system market. Sony PlayStation created a new segment in video gaming market.

Designers can created value to products by:
1. Enhancing price/performance: Create products that shatter all the established Price and performance expectations of customers.

2. Adding soft values such as: Convenience, Ease of service, rewarding customer loyalty, Product Customization, Life-style enhancers etc. Soft values are often not the attributes of the product itself, but it more about the product eco-system. For example iPad leveraged the existing Apps ecosystem of distribution, ease of usability, customer loyalty etc.

Product Design & Profitability

Product has also be designed for profitability. Once the product's economic feasibility and affordability is defined, the product must be designed to meet the internal profit margin requirements.

A number of design approaches can be used to lower product costs, including:

1. Intelligent specifications which cost less
2. Design-driven cost reductions;
3. Increased commonality and design reuse;
4. Product architecture planning;

In order to make objective trade-offs between cost and value, a means to quantify the impact of design choices on customer value is needed. Established methodologies like QFD, Conjoint Analyses, and Pugh Matrices make it possible to provide the objective linkages between design and value.

In most cases, product design choices is cost-engineered bottom-up, the cost of the finished product and then analyzed for the expected impact on customer value. Ideally, one should start with the product value point and then engineer the product for costs. When products are designed for value, then  it is possible to take better decisions regarding specific design choices.

The Design Team

It takes several teams to build products. Important among them are:

Design: Whose job is to make Products Useful & Desirable
Engineering: Whose job is to make products Possible & Affordable
Marketing: Whose job is to make products Saleable & Distributable

When all the three teams work together for a common purpose, then there will  be successful products.

Closing Thoughts

Product design is not just a one-off effort, but it is an ongoing, systematic approach to improving the product value and profits. As products evolve, the design boundaries are continuously tested and the product value proposition must be constantly improved, design improvements are done for improving profits.

Wednesday, September 26, 2012

Apple loses its way with Maps

Today Apple's iPhone5 is a hot news - albeit for wrong reasons. Critics and users are screaming mad about Apple's decision to abandon Google Maps and replace with their own product. Apple acquired 3C Technologies in October 2011  for its mapping software. Apple was hoping to recreate what Nokia accomplished by acquiring Navteq for map application

It was not the first time Apple had made such a blunder, Apple has made many, many mistakes before: See: Blunders of Apple.

But this blunder stands out from the rest mainly because the decision to change the maps app was a strategic, egoistic blunder. The other mistakes were either with product design or material or manufacturing.

Agreed that changing business conditions forced Jim Cook to move far away from Google, but then it was Apple's decision to sue (indirectly) Google or any company that used Google's Android. Steve Jobs once commented that he was willing to go thermonuclear on Android and the Maps App became a "collateral damage" in this war.

What should have Apple done?

From a product management perspective, all product decisions must be in-line with the company's strategy. So the replacement of Google Maps was inevitable, but product management could have done either one of the two things:

1. Delay the replacement of Apple's Maps Software till it catches up with Google.
2. License Nokia's Map software and offer that as replacement to Google Maps.

Since Apple's map software was clearly not ready for release, product management should have delayed the Map App changes in iOS 6. ( It takes a lot of guts to stand up to the CEO and say that, but that was the right thing to do)

Now that things are out in open, Apple faces two choices:

1. Quickly fix the mapping App. Which is not an easy option.
2. Allow users to install Google Maps, like YouTube app.
3. Drop C3 mapping technology & License Nokia's Navteq maps or MapInfo from Pitney Bowes. (MapInfo is commonly used as Microsoft Maps)

Given the three options, it looks like Apple will try option-1, i.e, fix the mapping software. Only under intense pressure from customer & customer groups, Apple may allow users to download a Google Map App. In case Apple is unable to fix the Map App, then Apple will license the technology from other company (which is highly unlikely)

Closing Thoughts
The errors in the Map App will not affect iPhone5 sales. People will buy iPhone5 irrespective of the app. Customers will always find a workaround - just use the Google Maps in the  browser. So from user perspective this is not a show stopper.

The glitches in Apple's Map App was blown out of proportion, and media made a big noise. But in the end, all the negative publicity on Maps helped Apple push up iPhone5 sales to a new record for a new smart phone. Apple sold 5 Million units of iPhone5 in just 3 days!

Building an Organization for Successful Innovation

Six years ago, EMC's India COE had just started and within a short span of three years, the Indian center became the leader in number of innovation ideas submitted. In 2011,  EMC  held its annual innovation summit meeting in Bangalore, moving it from Hopkinton for the first time. This was a considerable achievement given the fact that EMC is a global organization with R&D Centers in 11 countries.

The success of  innovation at  EMC  Center in India is a result of a sustained efforts and concentrated activities which led to an organizational process and part of organization culture. The success seen at  EMC  center in Bangalore can be replicated in any organization.

Organizational Capabilities

At the organizational level, there are four necessary capabilities that forms foundation for innovative culture.

1. Customer Insight

Great innovations start with customer insight. Organization have to work closely with customers and have multiple channels open to interact and gather information about and from customers, and distribute this information widely within the company. Organization also need to create opportunities for customers to participate directly with employees in product development process. This helps diffuse the knowledge gained from customer insights among all employees. Also see: Anthropology

2. Global Network

In today's global world,  "headquarters knows best" mentality  will not work. Global units must be encouraged to collaborate together and leverage knowledge that may be dispersed across the globe. At EMC most developmental projects require interacting with people from other geographic locations. This helps  integrate multiple sites into a seamlessly managed innovation network.

3. Supporting Organization

Organizations must be structured such that there are dedicated groups and tools to foster innovation. At  EMC, the Chief Technology Office (CTO) is dedicated to develop innovative products. HR conducts training programs on Innovative, creative thinking, patent laws etc. IT creates and maintains dedicated tools for collaborating and innovation management.

4. Vision for the Future 

Vision for the future sets the direction for innovation. Without direction, there will be thousands on innovative ideas which will go no where, and all innovation efforts will be wasted. At  EMC, the top leadership and all internal communication points to the central vision of Cloud Computing & Big Data. Three years ago,  EMC did not have much products for the cloud, the vision of the cloud based future set the trend & direction for all innovation activities.

People Skills for Innovation 

It is not the organization that innovates, it is the people who innovate. This implies that certain people skills must be developed in the organization as well. The basic skills sets needed for innovation are:

1. Leadership: Ability for individuals to take leadership in each innovation project

2. Curiosity: Be eager to know what's happening around us and understand what is needed.

3. Creativity: Ability to think of differently but in a constructive way and be of value to the organization

4. Learning: Ability to learn new technologies, tools and methods on one's own initiative - with or without formal training programs.

5. Agility: Ability to quickly develop a solution and implement it.

6. Sensitivity: Understand the cultural and technical limitations of current & proposed solutions and ability to work within those limitations.

The employees of the organization must have the above skills. It may not be possible to have a formal training program to imbibe these skills to employees. Instead try to hire people who have the right skills for innovation and assist them with formal training, mentorship and guidance as needed.

Closing Thoughts

If Innovation has to become a core competence of any organization, then one has to start with building the right organizational capabilities and follow it up with people skills. Remember that people are inherently creative and innovative, its only the organization and channeling that innovation into successful products/services will lead to profitability.

End Note: In last five years, EMC has been consistently growing at 10-12% year on year. The profitability, revenue growth and market share is steadily increasing - all this is due to its core organizational capabilities and innovation.

Tuesday, September 25, 2012

Writing a Good Statement of Work (SOW)

In the world of software development, bulk of the software being developed in customer software. Where the software is being developed to meet specific needs of only one customer. In such cases, the starting point for the project planning is the SOW and is fundamental to the success of the project.

Writing a good statement of work is no easy task. Having an vaguely worded SOW is an invitation for a project failure and is often the reason parties end up in a dispute.

A best practice is to have a joint team from both the developer & customer organization to write an SOW. This will reduce the likelihood of conflicts during the project startup stage.

From project management perspective, a good SOW must have the following features:

1. Background

The SOW should explain the background of the project explaining why the project is necessary and critical for the organization. Having the business background for the project is important so that everyone in the project team understand the bigger picture and the goals for the project, i.e., the project success criteria must be clearly articulated in such a way that every one in the project team understand what has to be accomplished.

The SOW sets the context of the project by defining the purpose, objectives, scope, constrains, assumptions and reference documents.

2. Points of Contact

Specify points of contact, including who will be the customer [project] managers interfacing with seller personnel during work accomplishment. At a minimum, a point of contact who has decision-making authority during work accomplishment should be specified. This individual will participate in CCB meetings and will be empowered to provide direction to the seller during work accomplishment.

3. Task Specifications & Deliverables 

This is the main section of the SOW. The SOW should specify the individual tasks that has to be done by seller/developer and by the buyer/customer. In a custom software development, there will be inputs & tasks to be done by the buyer.

For each of the tasks, there must be an associated deliverable, which lists out when & how that task is associated with the list deliverables. The SOW must also list out the dependencies (if applicable) for each task.  These tasks will be rolled into the project plan.

All deliverables must have specific dates. But this date could be changed only upon the approval from the CCB.

4. SOW $$ Value

The SOW should have financial information:

1. Total value of the contract
2. Payment terms, schedules & conditions.
3. Limits for certain types of expenses.

The financial information provides the limits of the project and gives the buyer an idea of the total costs involved. The pricing of such custom software development projects can be in terms of: Fixed Price or Time & Materials billing. Financial terms sets the ground for project planning.

5. Project Life Cycle

Though SOW is written for a one-off development, there could be multiple deliverables and maintenance works associated. Defining the life cycle of the software being developed will give developer and buyer various options for risk mitigation, and also gives greater flexibility to add new features as business conditions change. For example, customer wants a billing system to be built and maintained for a period of 5 years. During the period, vendor/developer is asked to release patches & upgrades every six months. This system will give greater flexibility for the buyer in terms of getting new/additional features, and also serves as a risk mitigation strategy in cases where when there is a feature schedule slippage, or when customer finds a bug in actual production usage.

6. Change Control Board

Change Control board and Change control mechanism must be explicitly defined in the SOW. The change control mechanism must be understood by all stake holders & team members. All changes to the initial SOW must be approved by the CCB and must be documented and tracked to a particular change request ID. CCB also provides as a channel for customer-vendor dialogue and interactions.

7. Risk Assessment & Risk Mitigation plan

SOW must have section in which the known risks at the start  are documented and appropriate risk mitigation strategy defined. For example, changes to taxation rules could be risk to the billing software project. In addition, the SOW must allow the seller to assess the risks involved in accomplishing the work as per SOW.  The Project plan will have the complete risks documented and risk assessment plans documented.  Also see: Risk Assessment in Software development

8. Joint Project Management Office

Since custom software development is a joint activity of the buyer & developer, a joint project management office will be required. The working details, authority & responsibility between the buyer & developer must be documented in the SOW. Having a pre-stablished Project management policies will help speed up decision making during project execution.

9. Existing Seller Practices

Today majority of software service providers e.g.: IBM, HP, Accenture, CSC etc have an established engineering practices and organizational policies and procedures that sellers are supposed to follow. The SOW must have a reference these items. Developers follow their internal policies & procedures and this in some cases may impact the project or may be impractical for the project or could be in conflict with the buyer's policies.  So having an clear reference to the vendor practices, policies, & procedures will help avoid future conflicts and when required the SOW can specify which of the vendor practices, policies, & procedures that must be changed or waived for this current development.

Closing Thoughts 

In the world of custom software development the SOW is the starting point for the project. Having a well defined SOW is critical for the project's success. In many cases, there will be master agreement between the vendor and buyer, which provides details on Joint Program management policies, pricing & payment mechanisms, and project governance details. In such cases, the SOW should have a reference to the relevant sections of the master agreement.

Having a well defined SOW forms the solid foundation upon which the project will be completed.

Sunday, September 23, 2012

Software Product Management & Product End of Life

No software product can be sold and supported forever. All software products must be phased out in a planned manner - which must be planned at the time of product release. An outdated software can turn into a maintenance & support nightmare. Knowing when to discontinue a product is vital for company's profitability.

A key aspect of product management is to determine when and how a product must be retired.
How to decide?

How do you kill a product that is no longer profitable? And how do you know that it's time?

To know when to retire a product, one needs to understand the underlying costing of software products,  Product life cycles and opportunity costs.

Product Costs Model

In a software product life cycle, the majority of costs are incurred during the product development phase. Once the product development is completed, the cost of making subsequent copies is zero, but there are other costs associated with the software product. These costs are not obvious but are substantial.

The two biggest costs are: Cost of selling and Cost of customer support. These two costs tend to have a "U" curve behavior. The costs of selling is very high at the launch of the product and goes down as the product becomes more popular. But as the product ages, the product becomes outdated and the cost of sales start to climb up. Similarly, product maintenance costs - i.e, customer support will be very high when the product is launched and customer discover various bugs or need help/support to implement the software. As the usage increases and bugs are fixed, customers also develop best practices, the product support costs reduces. But as the product ages, the system environment (Hardware, OS, databases etc) changes and the older software may not be compatible with the new environment - which prompts increased support calls & hence increasing support costs.

Another factor to consider is the opportunity costs. Companies can persuade customers to upgrade to a new version of the product - that can bring in additional revenue only if the current product is killed. So if the company continues to sell an old product, it can often eat into the potential sales of new product.

When, the cost of sales + Cost of support + opportunity costs = Net revenue; for a product, It is time to retire the product.

Companies such as Microsoft, Oracle, HP etc.  routinely announce EOL for their current products and also have replacement products for their customers. For example, Microsoft announced the EOL for Windows XP after releasing Windows 8, so customers can upgrade to Windows 8.

Product Strategy Directive

The final factor to consider is the overarching product strategy. This is probably the easiest to decide. When a product no longer fits into the company's distinctive competence & market strategy, it is best to kill the product. (regardless of the profitability and costs).

Usually product managers know when a product is past its prime and well managed products are retired. But there are cases when products are maintained beyond its useful life - mainly due to the political pressures:

1. The product is a pet project for one of the founders or CEO or VP.
2. The product is critical to one or few customers.
3. Salesforce resist removing the product from their list of products in their bag. In large companies with direct salesforce, salesmen often use some software products as a deal sweetener: "Sign the deal by this date & get this software free" offers.

The best way to plan for the product retirement is to build a financial data based reports for each product in the portfolio and then retire the product before it becomes no longer profitable. The costs of sustaining a product can be estimated ahead of time & based on these estimates the product can be retired. Most companies review their product portfolio on a quarterly basis to determine the support costs and decide when to retire a product.

For example, if it costs roughly $150,000 per technical employee per year to support the product, so if the product is bringing in less than $200,000 per year then it is time to kill the product.

Once the decision to retire a product is made, the next challenge is how to implement it?

Ideally, a product must be retired without losing any customers. So when a product is retired, customers must move to another product which has higher profitability. This is usually done my offering upgrades to a newer product which is better, has more features/functionality and has a larger user base (thus increase the wallet share).

Companies accomplish this by releasing a newer version of the product - Oracle 9.0 was replaced by Oracle 10.0 etc.

EOL communications 

First, an internal communication must go to all sales & customer support about the product's EOL and date. This helps removing the product from all sales pipelines and manufacturing plans (in case the product is still shipped as physical kits in CD/DVD). After the EOL date sales will not get any commission for selling the product. If there is an alternate or a replacement product available, then sales teams must be trained about the new product that will replace the one being retired.

Next, communication to all customers, customer support teams, external sales partners, channel support partners, value-added-resellers must be sent about the planned EOL and its replacement product.

Usually, EOL is implemented in two phases:

1. End of Sale
2. End of Support

End-of-Sale: After a particular date, the retired product cannot be sold. The existing customers are encouraged to migrate to the newer/replacement product at the earliest.

The next important date is End of Support. This marks the true EOL for the product. After this date, the product will no longer be supported. Customer can continue to use the old product at their own costs. The product support teams will no longer offer support or provide bug fixes to the retired product after this date.

In case the EOL decision was based on strategic direction and there is no replacement product, then tell all employees and customers that this product is no longer viable for the company and hence will be discontinued. Company may choose to provide technical support and bug fixes for some more time till "End of Support" is reached.  This notification is usually done via letter or e-mail to the buying contact in the client site.

If the product is an service, then End of Life communication must provide a time frame for customers to retrieve and transfer all data/services to an alternate provider. Also after the EOL, customers must be provided with an option of retrieving their data (at a cost)

In case the EOL decision was based on strategic direction and there is no replacement product, then there is a potential risk of losing customers for good. Losing a customer for one product may trigger a "run" response from the customer and customer may opt to exit all other products from the same company/vendor as well. Care must be taken to retain the customer while retiring a product. This is best accomplished by tying up with an alternate vendor who has a similar product/service - which customers can migrate to, and provide necessary help for migration.

Pre-planned EOL

Today, with Agile product management strategy, products come with a predefined EOL. The product's EOL dates are defined at the time the product is launched and is written into the product agreements. Typically, the product use agreement would state that the current product would automatically hit an End of sale, once the next version of the software is released and the product will be supported for a fixed period of time after it hits the End-of-sale date; i.e, Version 1.0 will not be sold once Version 2.0 is released and Version 1.0 will be supported for next 18 months only.

This pre-planned EOL is a good practice, especially for  mature products which undergo periodic upgrades. Today companies have predefined EOL policies in place. Example of an EOL:


Closing Thoughts 

End-of-life planning and execution is a critical function in product management. The main objective of EOL is to maintain product profitability while enhancing sales by moving customers to newer products. Retire the product, Retain the customer is the mantra for all EOL activities.

Product EOL is also a good time to fire/eliminate unwanted customers. There may by customers who may not be worth keeping. Such customers can be eliminated by offering a very high cost of upgrade/replacement - which will force them away from your products.

For customers who are worth retaining, special services may be offered like: Free upgrades, or free technical services for the upgrade, or extended support on older product till the customer upgrades etc.

In enterprise software, EOL is not a blanket activity, it needs to be planned carefully and executed well to retain valuable customers. All products must be retired before the profitability is affected. It is always a rational financial decision.

"A product whose costs exceeds its revenue must be retired."

Overview of a Project Plan

Releasing new software products, on-time and on-budget, represent a significant investment for an organization.  Because of the critical nature of software products on company's profitability, more attention needs to be paid to effective project management and how it impacts the overall business strategy.

Releasing products on time & on budget should not be a "one-off" isolated event, but a repeatable & predictable aspect, and a core business capability that drives the profitability of the business. 

Releasing products on time is a core project management function and the effectiveness of an organization's project management process can make or break the bottom line of the business. 

With this in mind, stakeholders are demanding greater accountability in the way projects are managed and demand full visibility into the project plan and project status. To ensure successful project, Project managers work with the program management office (PMO). This article provides an overview of a ideal project plan needed for software product development.  

The Project Plan

An ideal project plan has seven main sections.

1. Project Overview
2. Risk Assessment & Risk Mitigation Plan
3. Project Governance Plans
4. Development Plans
5. Quality Assurance Plans
6. Project Work Schedule
7. Project Resource Plans

1. Project Overview

Project Overview sets the context of the project by defining the purpose, objectives, scope, constrains, assumptions and reference documents. 

Product Requirement Document is usually the starting point for the project. The PRD defines the product functions - which translates into project objectives, project scope, and project timelines. Project managers then work out the project constrains,  and assumptions.

The Project Overview should have the statement of purpose of the project. This helps communicate the high-level understanding to all stakeholders. The project overview should also have the background of the project explaining why the project is necessary and critical for the organization. The goals for the project, i.e., the project success criteria must be clearly articulated in such a way that every one in the project team understand what has to be accomplished.

The project scope - i.e., the boundaries of the project must also be defined in the project overview. The project scope clearly tells what will be done and what will not be done, where ever it is needed - for example work allotments for contractors etc.  Things outside the project scope will not be done and planned for. Project managers must constantly monitor and prevent out-of-scope activities.  

Once the objectives and scope are defined, the project assumptions & constrains are listed. This assumptions and constrains become the basis on which the project plan is written. If the assumptions turnout to be wrong, the project plans will have to be changed accordingly.

2. Risk Assessment & Risk Mitigation Plans

Once a PRD is presented to project management office, PMO starts the Risk assessment and develops the Risk mitigation plan. All projects have to be classified into High, Medium & low risk projects. For more details on project risk assessment see: ( 

Once the risks are identified, the risk mitigation plans must also be developed and documented for each of the identified risks. The risk mitigation plan may involve changes to project schedule or release plans.

3. Project Governance Plans

The project governance plans defines the management oversight, coordination and review activities for a project. In most cases, the project governance plans may not be explicitly called out in a project plan because there would be an established Program Management Office (PMO) - whose main job is to provide management inputs to the project. Even in such cases there are few specific details of management plans will have to be published in project plan. Such as:

1. Project Team Organization: The size of the project team, Names of team leads and other key personnel.
2. Contractors (if any)
3. Reporting structure for all project personnel.
4. Frequency and schedule of Management Oversight & review meetings, status reviews.
5. CCB members and frequency of CCB review meetings

The PMO provides various management functions for the project: Resource allocation, budgeting, review business case, Project review, validate project assumptions, standardize tools & process etc.

4. Project Development Plans

Project development plans define how the product will be developed. It contains details on how the development team will develop the product that meets the PRD. This lists out all the efforts involved, all the development tasks that has to be accomplished, tools used. Typically, the project is divided into stages and list of  tasks to be done in each stage is listed out, along with milestones to be achieved and deliverables for each stage. 

For software product development projects, development activities include defining OS/System Platform requirements, allocating hardware and software tools needed, high level design describing data flow, conducting design reviews, product documentation, code reviews, providing training for operational use.  
Developmental stage leads the quality assurance stage.

5. Quality Assurance Plans

The quality assurance (QA) plans are a set of tasks that are required to ensure that the final product meets the PRD. QA plans details the checks and balances to be used to help ensure that each developed software product satisfies the defined requirements. 

The QA plans also lists out the checks and balances that are in place in form of quality assurance, verification and validation, test and evaluation, and configuration management. The QA plans are detailed for and tied to the development tasks - i.e., every developmental task must be tied to a QA task. 

In software product development, QA planning status with examining the PRD for congruency, testability, and consistency; preparing test plans; writing the test strategy; determining standards conformance; completing test procedures; conducting acceptance testing; performing test procedures in the operational environment; base lining products; and archiving incident reports and change requests.  

Product QA activities include defining test strategies and test data; comparing prototype requirements with the skeleton prototype; preparing acceptance test procedures; preparing beta procedures, preparing product acceptance testing and customer acceptance.

The QA plans supports the product development plans and provides management an insight into the status of the product development activities. 

6. Project Schedule.

The project schedule contains the complete schedule of the project as its stands on that day. At the start of the project, an initial schedule is planned out and as the project develops there could be changes in the plan. The project schedule captures the current schedule and the original planned schedule for documenting the project progress and post project assessments.

7. Project Resource Plans

Project resource plans identified all the resources required to complete the project. This includes all people, tools, hardware resources etc. Project resource plans document the initial resources allocations and actual usage for documenting the project progress and post project assessments.

Closing Thoughts

Detailed Project plan is the first  indicator of the preparedness for project success in any new product development projects. As product manager, I look at the project plan as a key indicator of how work is progressing and plan for next steps accordingly.  The absence of a detailed project plan is a leading indicator of an impending failure. The level of detail in the project plan is vital in taking right decisions for the success of the project. 

Tuesday, September 18, 2012

Apple is losing its Innovation Edge

Apple released its iPhone5 with great fanfare on 12th September. But unlike earlier releases, the iPhone5 had no major innovation. For the first time Apple was playing catch-up with its arch rival Samsung and had failed to add any new innovative feature in  iPhone5 .

Apart from LTE, a bigger screen  & the much hated smaller connector -  iPhone5  had no new feature. Apple had blatantly copied Samsung Galaxy S-III in terms of LTE and form factor improvements. With this failure to innovate has made Apple  iPhone5  a follower than a leader. Samsung now leads with its stylus technology used in Galaxy Note and with bigger screens. Nokia too has managed to get ahead in technology innovation with wireless charging & Window's "active tiles" user interface.

The lack of innovation in  iPhone5 and iPad3 could be an early sign of trouble at  Apple. Probably suffering from innovation fatigue and the top management being distracted with endless law suits.

As I see it,  Apple now runs a risk of losing its technology lead right at the crucial moment when Microsoft/Nokia are making a last effort to stay relevant in the market. Apple's iOS has some glaring gaps in terms business applications and is now lagging behind Android and Windows 8.0 in terms of cloud integration. Apple's iCloud is good but is not the best. Dropbox, Gdrive, Office365, & Amazon's Kindle are getting ahead of Apple's iCloud.

If Apple continues on this path of mediocre products, it will soon loose its way and hand over its crown to Google. Will Apple continue to be a leading innovator? We will have to wait and watch. For now I am waiting for the following innovations from Apple:

1. Improvements to its email & calendar client, email client must match Outlook in iOS.

2. Completely wireless device. All iOS devices should be totally wireless. Period.

3. Better Office applications - match MS Office in terms of functionality.

4. Match or beat Samsung Note in terms of copy, paste and edit functionality

5. True multi-tasking, ability to have multiple applications to share the same display and ability to switch seamlessly from one application to another.

6. Safe and secure email, chat, video conferencing with 256-bit encryption. Apple must beat Blackberry in terms of security.

7. Projector Screens. I would like to project the display on to any surface.

8. Virtual Screens. Ability to send the display outputs to other screens - either TV screen, or other mobile phones or computers or cameras or tablets etc. for remote assistance or other interesting uses.

9. Better data management. The current content/data management tools on iOS devices are too cumbersome to use. Apple should match or beat Zoho or Dropbox functionality in terms of data management functions.

10. Better integration of Photo album app in iOS with cloud & other devices to share/distribute photos/videos in real time

11. Projected keyboards. The current keyboard in iPhone is too small to type, instead have the device project a keyboard on to any surface.

12. Enhanced Siri for voice based user interface.

There is an almost an infinite ideas for new innovative features needed in iOS platforms. Bigger screen and faster Internet connection was too little on an innovation for  Apple standards. The next one year will tell how aggressive  Apple will be with its innovation engine. Competitors such as Samsung, Motorola, Nokia are almost catching up with Apple and have even managed to get a little ahead.

Only time will tell if  Apple will continue on the innovation path set by Steve Jobs, or will it fall back on a mediocre products without Steve Jobs - as it had become in the past.

Risk Assessment in New Software Product Development Projects

All new Software product development plans involve risks. These risks must be handled and managed using project management techniques.  From a project planning perspective, risks is classified into high risk, medium risk, or low risk, and appropriate risk mitigation plans has to be developed. Project risk management is a complex subject and has several nuances. However for simplicity of understanding, this article will deal with risk assessment from new product development perspective.

At the high level, the risk for any new product development project can be classified into:

1. Probability of the product not delivered on time.
2. Probability of the product not developed within budget
3. Probability of the product not having all the required features or not working as intended.

The job of management is to assess the risks and develop risk mitigation strategy.  With good management and product development process, all risks can be assessed early in development process and eliminated by proper allocation of resources.

A good approach for risk assessment includes:

1. Establishing a set of risk assessment criteria derived from both the organization's experience and industry wide data.

2. Consensus among all the parties involved - i.e., Product manager, marketing, finance, engineering, QA, &  project manager etc. The entire team agrees on the various risks involved in the project.

Based on this assessment, the project risk is usually classified into High(> 30% probability), Medium (> 20% probability) or Low risk ( < 10% probability).

It is important to establish a company wide database of risk criteria for your software systems development projects. In large organizations, office of program management maintains this and is primarily responsible for risk assessment.  The risk assessment logic can also be applied at each individual task level, sub-task level, etc. Furthermore, as the project unfolds, this logic can be applied on a periodic or event-driven basis as a part of your overall risk management approach.

Once the risk assessments are completed, the product team: Product manager, marketing, finance, engineering, QA, &  project manager etc., is responsible to developing the risk mitigation team.

Often times the risk mitigation plan would involve adding resources to the area that has high risks. If additional resources does not mitigate the risk, then in some cases certain requirements may have to be modified.

Risk Criteria

The main outcome of risk assessment exercise is to identify all the risks involved in the project and based on the set of risks, the project is classified into High, Medium or Low risk project.

1. High Risk Projects 

Projects that have more than two of the following risks identified, then such product development projects are usually classified as high risk project:

In case of new product development which is developing a "new-to-world" or "new-to-company" type of products - the risks are always high due to:

1. Unique product
2. Lack of clear requirements documentation.
3. Inexperienced development staff
4. No clear QA & test plans
5. Unknown customer use cases
6. Financial constraints
7. Technical challenges such unavailable technology or tools, etc.

Even projects that have high levels of subcontractor labor - with at least 50% of total development labor should be treated as high risk projects - due to less management oversight, lack of labor flexibility, and over dependence on subcontractor.

The project must be classified as "high-risk" if the product is a mission critical product - i.e., the failure of the product leads to death or injury or very large financial losses.  For example failure of Control system products can lead to death or injury during testing, Financial trading software that can lead to big losses (like the one that brought down Knight Capital.  Knight Capital lost $440 million in 45 minutes of trade.

Such high risk products must have extensive beta testing programs before they can be released.

Even projects that are just new revisions of an existing product can become high risk project if:

1. Development or QA resources are not fully committed.
2. Product requirements are not fully defined.
3. Project funding is not secured - i.e., management team is not in full agreement for the project.
4. There is no slack or buffers in the project schedule.

Once a project is identified as a "high-risk" project, full commitment from all stake holders is required for risk mitigation. Without total commitment from all the stake holders the new product development project is doomed to fail. In such a case, the project must be kept in abeyance till all stake holders agree and give their full commitment.  

High risk projects demand a very close monitoring of project and project risks. High risk projects require a greater commitment of resources - perhaps in form of reserve pool of resources being identified and kept ready for rapid deployment if needed.

High risk projects also require high levels of testing, Quality assurance and on-site validation. For high risk projects - about 65-75% of the total efforts are allocated to testing & quality assurance.

Risk mitigation plans for such high risk projects are almost always never complete, and with the risk materializes, the management team will have to tailor/modify risk mitigation plans.

2. Medium-risk projects 

Medium risk projects are usually the average software products that are:
1. Another revision of a current product.
2. Does not play a mission critical role at customer site
3. Customer has no critical dependency on the product
4. The functionality of the product is well understood.
5. Developer has some flexibility on release dates
6. Product has few fall back options: reduce functionality or release a patch after the release etc.
7. There is no over dependence on subcontracted labor (i.e., subcontracted labor is less than 50%)
8. Most of the project efforts are in product development - i.e., to add new features.
9. Failure of the product at customer site results in a negative publicity for the product or/& company.

Routine product enhancements can also become a medium risk project if:

1. The development or QA staff is inexperienced
2. Product testing procedures or resources are inadequate for the new features
3. There is little slack or buffer in project schedule
4. Requirements are not fully understood by the development team
5. There is uncertainty in product requirements - either the PRD is not fully developed.
6. There is dependency on external partners or vendors
7. External Market conditions are uncertain - i.,e possible recession etc.

Medium risk projects have to be monitored with pre-approved risk mitigation plans. These risk mitigation plans must be exercised immediately when needed to avoid  project failures.

3. Low-risk Projects

Projects that are not classified into high risk or medium risk projects are by default low-risk projects. In Low risk projects:

1. Product requirements are fully understood.
2. Have experienced development staff.
3. Have flexible schedules
4. Product failures do not cause any losses & can be easily rectified with a patch releases.

In low risk projects, most  (> 80%) of the resources are allocated for product development and has no allocated reserves. Usually teams/resources for low risk projects are identified as reserve resources for high risk projects, and such resources can be quickly redeployed for high risk projects - if there is a need.

Risk Mitigation planning

In most of the cases, risk mitigation plans translates to identification of additional resources that can be used when needed. In reality, most organizations are stretched for resources and often will have nothing to spare for a high risk project. In such cases, Management is running on hope & luck - to see the project through. Failures in such situation will be disastrous - often at an enormous cost. Many startups die because they cannot afford resources for risk mitigation. Even in large companies, projects get canceled when there are no resources for risk mitigation.

As a prudent management planning, companies today are using the option of killing the product development projects are part of their risk mitigation strategy. In mission critical projects, it may be prudent to kill the product if the risks become too high.

Closing Thoughts

It is important for all stake holders to be involved in the risk assessment process & achieve consensus on project risks. Risk assessment starts with the product definition stage, right at the time of developing the product requirements and then working as a team to develop plans for risk mitigation.

All stake holders must have full visibility to risk identification, risk assessment and risk mitigation plans. This leads to better understanding of the risks associated with the new product development projects and thus allocate the right resources needed for successful new product development.

Risk mitigation plans are almost always never complete, mainly because, resource estimating is, at best, educated guesswork. So when a project risk materializes, the entire management and project teams will have to work to mitigate it. This often needs heroic efforts from few individuals.

Product managers must be prudent to kill the project when necessary. Many a times it is better to kill a project than throw more resources at a doomed project. This decision of killing a project is more of an art than science.

Monday, September 17, 2012

Product Management and Software Product Development Lifecycle

Software product development is a complex activity and product managers play an important role all through the product development cycle. As companies mature, a standard way of new product development is developed. Product managers will have to focus on internal product development process along with focus on customer requirements and market conditions.

The product development activity is internal to the organization and from product management activities perspective, it is often referred to as "Inbound Product Management". This article is a brief description of all what roles product management plays in the product development life cycle - a.k.a "Inbound Product Management".

Typical software product development lifecycle consists of six distinct stages:

1. Requirements definition
2. Product design
3. Product Development  & QA
4. User Acceptance or Beta program
5. General release
6. Operation & maintenance

Product management plays an important role in each of these six stages.  In this article, I will briefly go over the activities done during each of the six stages.

Requirements Definition 

Requirements definition stage focuses primarily on what the final software product should do. This is often documented in terms of what functions to be performed,  on what platform (hardware/software & other dependencies) This may include performance details, functional details, serviceability details etc..

Each requirements must be prioritized and ranked in the Product Requirement Document (PRD). External dependencies, if any, must also be listed - so that proper project risk assessment can be done.  The requirements must be "unambiguous," "complete," and "traceable."

The PRD must be written in such a way that both development and quality assurance teams must be able to understand the requirements in its completeness,   consistency, stability, verifiability, modifiability, and traceability.

Project management takes this PRD and develops a project plan based on effort estimations and estimated risks. Once the PRD & project plan is approved, any change to the product requirements or project plan must be approved by the change control board. The project management tasks include monitoring the assessed risk and planning risk mitigation strategies as needed. As the project goes into execution, project management refines planned budgets and schedules.

Note that it is very important to establish the change control board (CCB) early in the project planning stage. As the project progresses, both the requirements and product designs get further refined.

As the project proceeds, the various project dynamics result in the need to refine the requirements or the design implementation. Any change to the agreed-upon project plan must be presented to CCB and it is the duty of CCB to approve or reject the proposed changes. The CCB meetings continue throughout the product development life cycle stages.

In some organizations, CCB function will be done by Program Management Teams (PMT) or/and by Program Leadership Management Teams (PLMT)

Product Design Stage

The main activity in this stage to define how the software accomplishes the stated requirements.

A specific requirement can be implemented in several different ways, it the software architecture and design teams responsibility to decide on how the system must be designed to meet the specific requirements including:

1. Hardware & Software platform definition
2. Defining all major systems & subsystems
3. Splitting of functions across different Systems or subsystems.
4. Data-flows into and out of different Systems or subsystems.
5. Defining data transformations in each System or subsystems.
6. Defining Algorithms & Design for Systems or subsystems.
7. Defining system validation methods for Systems or subsystems.
8. Defining quantitative performance measurement & evaluation criteria.
9. Design to confirm to various standards
10. Developing test procedures & test strategy.
11. Product documentation plan
12. User Acceptance Or Beta program Plans

In addition other design activities may be required depending on the type of software being developed.

The designs are then submitted to management team for approval. Once the designs are approved, any changes to the design will require explicit approval from CCB (or PMT/PLMT)

The product management tasks is to understand the design and how the design meets the customer requirements. Product managers play the role of customer and give valuable design inputs during the design phase.

The role of project management is to monitor closely the schedules and refine the project plan, Identify dependencies & project risks. Many times the product design work does not finish as planned and the product schedules are affected. Project planning activities should account for such potential schedule risks.

Product Development Stage 

In software product development, the main activity in this stage is mainly coding and testing. The main objective in this stage is to convert the detailed design into language that computer hardware can understand and perform.

The product management tasks is to monitor the development process and deciding whether the computer code is ready to ship to the customer. As software development progresses, there will be bugs: i.e.., defects and implementation variance from the actual design. Some of these bugs are show stoppers, some are critical and some are minor. Bugs are often classified based on severity: Sev-1,2,3,4 etc..

Management function is to determine the severity of the bug and then decide on whether the software is ready for release.

These management decisions are made at CCB meetings in presence of quality assurance team, engineering development teams, product marketing and all stake holders. The stake holders define the "acceptance criteria" and then make the final call on when to release the product.

User Acceptance Testing or Beta program

In User Acceptance Testing (UAT) or Beta program stage, the software product is actually deployed and tested in customer environment. This is a product assurance task where the customer and developed will examine the software for mutual approval.

Often times, the internal testing and quality assurance procedures may not be able to replicate the complex customer environments and customers may need time to really use and test the product before buying it. From product development perspective, customer acceptance is the ultimate quality assurance - implying that the newly developed product meets the stated requirements.

The beta programs can be extensive - running into several months, or a short cycle to test out certain new features, depending on the software maturity and reliability.

Product management tasks in this stage include monitoring the delivery of the product to the customer and soliciting customer feedback, improving the product based on the feedback. This may include tailoring the product or the customer environment - if the product is intended for a range of customers with specialized needs. Many enterprise software products (e.g.: SAP, Oracle, etc..) may require changes in customer's system environment to make the product work. These customizations and customer validation will be done in this phase.

Successful completion of this User Acceptance Testing or Beta program includes

1. Developing software systems that meet customer needs - including all customizations and system changes.

2. Packaging the final tested software code along with user documentation. All customizations and changes must become part of the final product.

Today companies capture the "golden image" of the OS, supporting databases, servers etc. into a shrink-wrapped system software - that can be deployed off the shelf for each custom deployment. This helps in operational & sustenance stage.

General Release

Once the software product completes the UAT or quality acceptance testing, the finished product is then released for distribution. Software is often distributed in form of physical kits - which consists of installable code, product documentation & license keys. Software products are now being distributed over Internet - where customers can download the entire product.

Product Management activities during this stage include training the users or in many times training the trainers, conducting product road shows, product demos and various product marketing activities.

The general release also indicates the end of the software development project, project teams & CCB are disbanded.

Operation & Maintenance Stage 

The main activity in this stage is to support customers' use of the product. Customer support groups are actively involved in educating customers to use the product, collecting product feedback from customers, documenting product bugs & providing fixes.

As the main activity in this stage happens at the customer site, product mangers must monitor operational use of the product, collect customer feedback, collect customer suggestions on product improvement, compiling and analyzing customer feedback and determining potential follow-on work.

A byproduct during this stage is customer detection of latent software defects and customer definition of enhancements or new capabilities that helps define the next product development cycle.

Closing Thoughts

Product development is often thought as an ongoing cycle of continuous development where one version of the software replaces the older version. From a product development lifecycle perspective, this is partially true. Product management can implement a phased development of new features through multiple releases - and thus minimize the risks and also enhance product acceptance in the market.

Eventually, all products will reach its logical end - i.e., no more new development, and then enter the death phase, where all product functions are also stopped. Product managers play a very important role in determining when to terminate a product. Usually product termination is also carried out in a planned and phased manner called as "End-Of-Life" (EOL) planning.

See: Software Product Management  & Product End of Life

Tuesday, September 11, 2012

Project Planning and Software Product Development

All software product development and project management go hand-in-hand. Since software products has to be released with a predefined set of functions and features on a pre planned release schedule, project planning is one of the most important aspect of successful product development.

Every product manager has to spend substantial time on project planning, in most large organizations, there will be a dedicated program management and project management teams who will play a critical part of new product development.

Once the customer requirements are identified, the next step is to develop a 'Project plan'

A project plan, in the initial stage is an estimate of how much effort, cost and time is needed to develop the software development.

Just as the software development, project planning is also an iterative process. As the product plan gets further refined, project plan also gets further developed. The project plan is a living document - which changes in response to changing product plan. Therefore, a good project management must accommodate changes. A good project plan will have change management systems built into it. It is a good practice to have a "Change Control Board" to monitor and manage project changes.

Key Concepts in Project Planning

Software product development is an iterative process - i.e., products are constantly developed, Products have several release versions (rev 1.0, 2.0, 3. 0 etc). This iterative process is reflected in software project planning. Software project planning is not a one time activity - instead it is a iterative activity where each project is followed with another project. In agile methodology, each product development iteration could have multiple project iterations. Thus software product development and software Project planning go hand-in-hand, unlike projects in construction or any other industry.

Key concepts in project planning are:

1. Software product development life cycle provides a basic framework for project planning. The project plan is derived from the product development life cycle. Essentially the project plan is done to ensure that the new product meets the stated customer requirements.

2. Project plan must account for all management overheads & interactions between product management, engineering development, test/QA teams, customer support, product marketing teams throughout the project life cycle. A project plan must have synchronization meetings & project review between various stakeholders to ensure successful product development.

3. Project Plan must accommodate changes in a planned and controlled manner. A Change Control Board (CCB) is essentially in dealing with the inevitable changes that occur in the project.

4. Project plan is an ongoing negotiation between the customer ( in most cases represented by product manger) and product development teams - engineering, QA, finance etc. The project plan offers a balanced scorecard for all stake holders to create a win-win situation.

5. Project plan maps out all resources, resource utilization, schedules and milestones that are needed during the course of the project life cycle. The project plan sets the overall boundary conditions for the project within which the product has to be developed. These boundary conditions are often referred to as project constrains.

6. Project plan needs to assess risks involved to determine the appropriate mix of management, development, and product assurance.  There is a strong correlation between project risk and how resources are allocated for the project. Project plan must document the risk assessments and the risk mitigation plans.  

7. Project Planning is required for all software product development effort  and there are no standard project template or "one-size-fits-all" project framework. A project planning will often require a dedicated project management teams - who develop and maintain the project plan and ensure all teams work & deliver as per the plan.

Closing Thoughts

In the world of software product development is a complex activity involving several stake holders. A good project management forms the basic foundation for successful product development.  

Software Product Manager's responsibilities

What do software product managers do?

This is a very common question from engineers and managers. Though there are many ways to answer this, the main role product managers do for any product is to ensure products are developed in a consistent manner that meets customer's needs, and ensures a reasonable profit. But this is like an over arching view of product from 30000 feet above ground, but it aptly captures the role of all product managers.

In software industry, there are several contradictory demands. These are contradictory because two demands run at cross purposes against each other. Most common ones are:

  • Deliver the software on time & within budget.
  • Ensure that the last-minute requests are included in this release.
  • Don't provide short-term fixes for long term problems.
  • Add this one feature as part of a patch release.
  • Shipping six releases per quarter/year is not acceptable.
  • We all have to work on limited budgets and rescues.
  • We cannot compromise on quality

Product development exercise is filled with conflicting needs. Every stake holder has a set of needs that often runs against other set of stated needs. The product manager will have to deal with conflicts successfully to have successful products.

In a hyper-competitive world, One has to release products on time and with features that customers expect. Delay in product releases or missing out on a feature is not acceptable.

To ensure success, product managers have to start with customers to understand what customer wants:

1. What are the features & functions of the product?
2. When do they need the product?
3. What price the customer is willing to pay for the product?

Product managers will then have to translate the customer needs into:

1. Product Plan - what features & functionality will be delivered
2. Product release Plan - When the release should happen
3. Product Pricing Plan - How the product must be priced and sold.

Product managers must create the above plans to ensure that the product delivers that the customers want, Is delivered on time, and the product makes a reasonable profit.

Since product mangers are not superheros to do all that, they have to work with project management, engineering management, product marketing & finance to develop a workable plan.

A good product plan is the one that meets both the customer needs and makes a good profit. Success in the software product development business is not a one-shot deal. It has to be a repeatable process that can be repeated across multiple customer segments. Product managers will have to create processes and systems that has the ability to produce successful software products consistently.

Software product development process is usually a delicate balance of various business factors - which often leads to the saying "There is no 'one way' to develop software products."

The software development process is  constantly changing and evolving to:

1. Accommodate organizational changes.
2. Software development is an developer-customer partnership where both parties actively participate and agree on the end product.
3. Software development is an ongoing exercise in risk reduction
4. People are the most important factor in software development. This implies constant people & skills development exercise along with product development.
5. Document and measure progress of product development.

Software Product development is never a constant process. It is an ever changing dynamic process - which needs to be controlled and guided to ensure product success and that in essence is the main role of product managers.

Friday, September 07, 2012

Improving Innovation with increased market awareness

A global economic slowdown in 2012 has increased the competitive pressures, while the economic pressures has increased in the complexity of corporate finance. In such a challenging environment, there is a growing consensus that innovation is stalling or even decreasing. The high failure rate of product innovation is often sighted as an evidence to the slowdown.

The ecomonic crisis in the USA & Europe, ageing population in Japan, Germany and the subsequent economic slowdown in Asia has led to an ever increasing price pressure from customers and suppliers, low-cost competition, and high expectations for profitable growth from investors and shareholders. To respond to these challenges, product companies must change the innovation process to achieve a higher level of innovation efficiency to remain competitive and drive top-line growth.

Accoding to IDC survey, only 25% of all projects result in a product that reaches the market and after that 80-90% of products fail in the market place. This implies that a vast amount of product development efforts gets wasted. In today's world, companies cannot afford frivolous & wasteful innovation.

The new mantra is "Effective & Effecient Innovation"

The new paradigm of innovation calls for a different approach towards innovation. The old view of treating innovation as an inherently unstructured and unmanageable process must go. Instead a holistic view of innovation landscape must be embraced to maximize the returns on R&D investments.

While the required resources needed for innovation is getting increasingly scarce, companies have responded to it by:

Investing in project management process and management tools.
Setting up globally distributed R&D centers.

While the investment in project management process & tools has made innovation projects meet the timelines and budgets, but that has not refelected in product success.

Globally distributed R&D centers has addressed the resource scarcity and increased the pace of innovation. But again global innovation has not translated into product success.

So in last decade 2000-2010, companies have improved the effeciency of innovation process and in the process companies released an ever increasing numbers of new products. The volume of new products introduced in the last decade is unprecedented, the rate of product failures has also sky rocketed.

In other words, companies found a faster ways to fail!

While failures are the stepping stone for success, companies cannot afford to failures. So the way companies innovate has to change.

Innovation Gap - The Market Blindness

Obviously there must be some mistakes in the innovation process - which is leading to such high failure rates.

As a product manager and an innovation coach and innovator, I have obsserved few interesting innovation gaps.

The most startling gap is called as Market Blindness - which has several facets:

1. Customer Agnostic Innovation
2. Eco-system Agnostic Innovation
3. Economy Agnostic Innovation
4. Me-too Products Introduction
5. Confuse the customer with Innovation
6. Agile product developement
7. Accounting($$) driven Innovation managment

In today's gloabally connected market place, the market is so dynamic that the innovators are often blind to the actual market requirements. So when the product finally hits the market - both the innovators and customers are equally confused - leading to product failure.

For example, Nokia rushed Lumia 800, 710 & 900 on Windows 7.8. Microsoft then went ahead and announced Windows 8.0 - which will not run on Lumia 710, 800 & 900! Obviously, customers will not rush to buy Lumia 920 which runs on Windows 8.0!

This is a classic case of complete market blindness.

In the rush to innovate, innovators forget about the customers. In many cases, engineers working on the innovation have no idea of what the customer wants & needs. The function of customer research is often handled by marketing. In large global organizations, the innovators and customers never come face-to-face, which often leads to customer agnostic innovation. Many software products fail because the innovators failed to understand the customer needs.

Today Companies have to depend on external eco-systems for the success of new products. For example, Smart Phones needs carriers, Apps & App market place to succeed. If the eco-system does not exist, the product will not succeed. HP's TouchPad tablet is an classic example of eco-system agnostic innovation.

Many products need certain econmic conditions to succeed. During the course of innovation, if the underlying economic condition changes, then the innovation will fail in the market place. For example, Concord, the supersonic plane failed in the market because it turned out to be too expensive to operate and customers were not willing to pay the high ticket prices.

Imitation is the best form of flattery, but that does not prevent companies from launching mee-too products. Sony tablet, Sony Xepria, LG Andriod phones etc have failed because these products could not differentiate themselves for the market leaders.

Innovative products should please the customer and not confuse them. Too often, companies release products that are really confuses the customer. Blackberry playbook was one such example. Customers could not make sense of why they could not check their emails on Playbook and why playbook had to be paired up with a phone.

Innovation is good, but too much of it in too short steps is a bad thing. Agile product development is a hot concept in the industry - where companies release regular updates to the product on a fixed time periods. Having too many releases confuses the customer - which one to buy? Should I wait for the next release? In the end, customer may defer the buy decision or just buy and become dissatisfied with the purchase. The Personal computer industry and software sector is notorious in this. Companies like Dell, HP, have so frequent product releases, and each release is a minor enhancement over the previous one. Such a high volume of product releases has killed the WoW! Factor out of their innovation. Customers no longer jump in joy by seeing a new product - instead mearly yawn or totally ignore the new products.

Improving Innovation with increased market awareness

In the course of product innovation, companies have invested heavily into product design, project managment & developed a plethora of tools (CAD, CAE, CAM etc.). But in the process have almost forgotten the poor customer.

The focus on greater effiency has made companies rely on partners for market eco-system development. Companies have decentralized & outsourced various functions which caused critical information to be fragmented and scattered across the world - often operating in deparmental & geographic silos. As a result the innovation teams are often working blind in their own silo, toiling on products which customers may not need.

In order to be successful, companies will have to make their innovation process more customer centric and innovators must be aware of market needs and market conditions.

I have written several articles on Customer Co-creation as means of innovation, Anthropology as an innovation tool to highlight the need for market awareness before, during and after innovation.

I have taken R&D engineers to customer sites - to let see and observe customer operations first hand to help engineers understand customer needs and this has led to successful products. In the long run, the process of customer engagement during the innovation cycle must be institutionalized and built into project management process.

Marketing organization must also be plugged into the innovation process and must provide constant inputs during innovation process. See: Product Innovation Management and Marketing

While successful companies have led with fewer products - but with a far greater success rates. The key difference between success & failure is market focus and tenacity.