Mar 07

When people ask me what type of work I do? I proudly answer Product Management in technology companies. Please don’t be mistaken with that statement…I don’t feel proud because a role Product Management bestows me lot of power (in literal sense). On the contrary I believe it is one of those roles, which has very less formal authority.

While I was trying to figure out how to explain my Product Management role in layman terms I came across a hilarious video @ http://www.youtube.com/watch?v=ZiBeKrwfU90, which explains what Product Management is. I couldn’t control myself from laughing out loud. In the video Product Manager (ostensibly CEO of the product) explains how (in roundabout way) her job is to make sure that customer don’t puke (because of the product). And, having seen how Product Managers work in various companies Product Manager in the video is not far from the truth.

Honestly, if someone asks me give an example of a role where you Accountability without Authority…I would without a doubt say Product Management. And, I guess this is THE thing, which I hate about product management. You are RESPONSIBLE for a lot but don’t have much formal AUTHORITY and sometimes EMPOWERMENT.

And the problem gets further complicated if you work in Technology Company where relevant stakeholders don’t understand the role of Product Management. What I have observed is that most stakeholders liken the role of Product Management to that of Requirement Manager, Product Architect, UI Architect, Program Manager or Marketing. When I see this happening I recall the “blindfolded men and elephant story” which I read in my childhood, where every blindfolded person touches different part of the elephant and convincingly explains about how elephant looks on the basis of their view.

I guess this happens because most people don’t understand how Product Manager works with various stakeholders such as sales, engineers, support, customers, channel, and business partners, management, board of directors and anyone else who is necessary to ensure product success. And, trust me some of these people with whom Product Manager needs to collaborate are very difficult people to work with :) . These stakeholders probably see what Product Management does for them and keep only that perspective.

The sad part is that NOT every Product Manager succeeds…if you go by statistics you would realize that
1. Up to 95% of NEW product introductions fail
2. Most products have 80% FEATURES, which are never used
3. And, approximately 50% of the R&D investments are wasted

I believe these things happen because either Product Management is not well understood by various stakeholders (including Product Managers themselves) or when these roles are not empowered enough.

Hold on! Things are not as gloomy with respect to Product Management as you might have started thinking about it. So the question is, why do still I love being a Product Manager despite of all these drawbacks?

The answer is…that being in Product Management I become the owner of the customer problem area AND am also become responsible to best address that problem domain through a user friendly solution in a competitive environment. I become the voice of the customers and start representing them while making business decisions and am forced to develop alliances to ensure product success. And, this is what makes Product Management challenging, which I love the most. Product Management is one of the toughest yet one of the most rewarding roles because it provides enormous opportunities to learn, improve, and make an impact. It also teaches me how to become better person because I am FORCED to learn skills to get things done without much formal authority.

In my opinion Product Management is not a role for timids or power mongers. It’s neither a role for people who want to just show off or want to hide behind the walls. It’s a role for people who really want to try and solve real problems. It’s a role for people who dream of bringing innovations to make things easy for others. It’s a role for people who dream of making world a better place by improving the way people live, learn, work, and play.

And yes it’s difficult to be in Product Management but it doesn’t kill you. And, as I always believed that what doesn’t kill you makes you stronger (and Kelly Clarkson through her song has made me feel that I am not the only person who believes in such ideology).

Tagged with:
Jul 27

In any casual conversation about product usability, most people would agree that it’s good to have a product that works well and is easy to use. Every one of us has stories about how one particular product is so great and how one is unable to use another product. The issue is that although everyone understands user experience is important, most product organizations (especially IT products) pay little attention to it (which is a topic of separate discussion and discussed to some extent on my earlier post Can Product Usability be an afterthought?)

The best way to capture User Experience Quotient of your product is to do some Usability Testing. During usability testing try to capture metrics such as follows

  1. Task Success – This metrics is related to effectiveness and captures whether the task was completed successfully or not. Each task identified for the product should be scored individually as success or failure. To measure success, you need to know what constitutes success, so you should define the success criteria for each task prior to the data collection.
  2. Time-on-task – This metrics is related to efficiency and captures the amount of time spent in completing the task. The time it takes a user to perform a task says a lot about the usability of the product. In almost every situation, the faster a participant can complete a task, the better the experience I am sure you wouldn’t have heard user complaining that a task took less time than expected.
  3. Errors - Most errors are the outcomes of situation where the alternate task flows are not taken into consideration while designing the task workflow. In simple words errors are outcomes of incorrect actions, which lead to task failure. Errors can tell how many mistakes were made, where they were made within the product, how various designs produce different frequencies and types of errors, and generally how usable something really is.
  4. Efficiency – Along with Time-on-task metrics one should also measure how much effort is required to complete the task. This cab done by measuring the number of actions or steps that user takes in performing each task. An action can be clicking a link on a web page, pressing a button on a microwave oven or a mobile phone, or flipping a switch on an aircraft. The more actions taken by a participant, the more effort involved and the overall goal should be to minimize the effort required by reducing the number of actions required.
  5. Learn-ability – Users need to learn how to use product and easier the product to learn higher the chances of its success. Learnability is the extent to which something can be learned. It can be measured by looking at how much time and effort are required to become proficient with something.
  6. Issue-based Metrics – A usability issue might involve confusion around a particular term or piece of content, method of navigation, or just not noticing something that should be noticed. What do we mean by usability issues? There’s no simple definition, so here are some examples:
    1. Anything that prevents task completion
    2. Anything that takes someone ‘‘off-course’’
    3. Anything that creates some level of confusion
    4. Anything that produces an error
    5. Not seeing something that should be noticed
    6. Assuming something is correct when it is not
    7. Assuming a task is complete when it is not
    8. Performing the wrong action
    9. Misinterpreting some piece of content
    10. Not understanding the navigation
  7. Self Reported Metrics – Self-reported data gives the most important information about users’ perception of the system and their interaction with it. At an emotional level, the data may even tell something about how the users feel about the system. In many situations, these kinds of reactions are the main thing to care about. Even if it takes users forever to perform something with a system, if the experience makes them happy, that may be the only thing that matters. Some attributes of the product or website which can be obtained through self-reported metrics Visual appeal, Perceived efficiency, Usefulness, Enjoyment, Credibility, Appropriateness of terminology, Ease of navigation, and Responsiveness etc.
  8. Behavioral and Psychological Metrics – While using the product, most users do much more than just completing the task. They may laugh, groan, shout, grimace, smile, fidget in their chair, look aimlessly around, or drum their fingers on the objects. These are all behaviors that are potentially measurable and offer insights into the usability of the product. Most of this body language and verbalization can be observed and noted but some types of subtle or fleeting behavior are harder to observe.
  9. Live Web Metrics – When dealing with a live web based products, there’s a potential treasure trove of data available about what the visitors to application are actually doing—what pages they’re visiting, what links they’re clicking on, and what paths they’re following. The challenge usually isn’t getting the raw data but making sense of it.

This type of metrics will help you understand what perceptions users can form while using the product. Of course, this data can then be used to identify what needs to be done to make the product user friendly.  After all, every product companies ultimate goal is to make the users think of using their product first (so that they can sell more of that product :) ).

I recommend reading following blogs to improve your User Experience knowledge and then apply it rigorously while building products. I am confident that results will speak for themselves!

http://www.useit.com/

http://www.measuringusability.com/

http://www.measuringuserexperience.com/

Tagged with:
Apr 20

In very few companies what to develop in the next product release is decided based on gut feel. In most companies there is some process, which is followed while making decision on prospective product release and some even require a formal business case. There are various business case templates available on the internet, which can be used to capture the required information to build a formal business case. The considerations, to be factored while developing a business case for a prospective product release, can be subjective though and some of them are highlighted in the picture below.

Prospective Product Release – Business Case Considerations


In my opinion, the most important component of the business case should address following questions in high level introductory section

  1. What features are we trying to implement?
  2. Why are we trying to implement these features?
  3. When do we want these features to be implemented?
  4. What will it do for the company?
  5. How will it benefit customers (current or potential)?

I also believe that while it is important for Product Managers to be able to drive the product as per their knowledge, business sense and gut feel, it is equally important for them to communicate their thought process to various product stakeholders to obtain their buy-in so as to reduce the business risk of prospective release. Every company is different but we feel following stakeholders must be part of Business Case review

  1. Marketing
  2. Engineering
  3. Presales
  4. Support

While above stakeholders can provide validations from the company point of view we also believe that Product Managers or Product Owners should try to validate the business case from external stakeholders such as Customers (current or potential), Partners or System Integrators etc. Such validated business case will provide solid confidence to the internal stakeholders, who are supposed to opine on the go ahead of the prospective product release.

In my opinion, the most important part (which is most often missed out or not taken seriously) of the business case is the “success criteria” for the prospective release. I believe that success criteria must be mandated and should list out what benefit the Product Manager or Product Owner believes, company will obtain and in what timeframe because of implementing the prospective product release. Examples of such criteria could be expected growth in revenue, improvement in competitive position; expected reduction in implementation costs, or improved proposal compliance etc. Identification of such success criteria coupled with monitoring of attainment of the success criteria post release, will provide meaningful background information for making business case decisions in future.

Of course, this is what I think with respect to business case requirements for a prospective product release. What do you think?

As a Product Manager or Product Owner, do you even have to create a business case? If yes, what information do you put in the business case for a prospective product release?

Tagged with:
Mar 20

When top executives of the product companies were asked about what makes most products unsuccessful following four major factors emerged as per recent research[1]

1. Failing to Incorporate Voice of the Customer into the Process

The “Voice of the Customer” is the term to describe the stated and unstated customer needs or requirements. There is no one monolithic voice of the customer. Customer voices are diverse- internal and external. In addition to the external customer, there are multiple customer voices within a single organization: the voice of the sales organization, the voice of the development teams, and the voice of the supporting or maintenance organization. These diverse voices must be considered, reconciled and balanced to develop a truly successful product.

2. Failing to Align Product Execution with Company Strategy

The survey indicated that often companies are developing the wrong products with the wrong features because of a substantial disconnect between C-level strategy setters and those managing product execution.

Priorities trickle down from c-suite management; but product developers often do not have the right plan allocation, or resources to execute on delivery. Hence, there is a significant disconnect between what the development teams are working on versus what was handed down based on corporate objectives.

3. Failing to Automate Innovation Processes

The need for speed in the product development cycle is a major priority yet complex products, complex requirements, complex development lifecycle slow things down. Paper based and other manual processes add fuel to the fire slowing things down even further or worse, completely missing key customer requirements or market opportunities.

Almost half (48%) of respondents report their business pace will be faster and another 38% expect more uncertainty and volatility. Better and faster is seen as the way to survive and thrive. Yet, survey results show that nearly 70% of companies are still on a manual process (using spreadsheets and word documents) when it comes to managing their innovation processes across the enterprise.

4. Failing to Mitigate Planning and Execution Risk

With less than 50% of product launches successful, the risk of product failure is high. Mitigating planning and execution risk cited as the # 1 challenge in most companies. Specific risk areas mentioned include the inability to plan resources to match timing and constraints leading to missed market opportunities due to missing launch deadlines and the inability to manage product and execution dependencies across multiple teams and regions.

And when asked which initiatives these companies have planned or starting or accelerating in the coming year the results were as shown in the picture below. As you can see the most popular answer was ‘Product Portfolio Management’ as the key innovation management initiative that most companies plan to start accelerating in the coming year: 70% of executives plan to make an investment in a portfolio solution to maximize profitability or value of the portfolio, provide balance and support the strategy of the enterprise in 2011.

Of course, this is what the research has to say, what is your reality?


[1] Aberdeen Research Study June 2010

Tagged with:
Feb 19

Have you ever faced a situation where you as a product professional think you have taken all the right steps and released a feature but somehow the response from the sales/presales and potential customers is lukewarm? I have definitely witnessed such situations in my early Product Management career.

In most companies once the requirements are frozen the prototyping work is either skipped or not given the importance it deserves. What happens then is that the sales/presales and everybody else (even the Product Manager or Product Owner) gets to see the product just when product is about to get released. Of course, this may not be true for startup or recently started product but it can definitely happen in organizations where product has matured OR product development community believes that they understand how the user uses the product. I am not here to say that the development community is right or wrong but instead I advocate that it is responsibility of the Product Manager or Product Owner to make sure that the product release meets the requirement and user expectations without getting biased about anything else.

The recommended approach for obtaining early feedback on prospective product release is depicted in the picture below. Instead of making this a formal process I recommend product professionals to first understand and get convinced about why such review mechanism is required and then negotiate with implementation teams to have such reviews. Of course, some reviews must be made formal but most of these reviews can be informally conducted without making too much fuss about the process. While following such process Product Manager or Product Owner can expect some hiccups here and there but I believe that as long as the implementation team understands the intent of such reviews they wouldn’t hesitate to make them happen.

Prospective Product Release – Implementation Review Approach

Again, this is what I would do and would recommend, what approach do you follow to obtain early feedback on prospective product release?

Tagged with:
Jan 18

In most companies although the product decisions are made by Product Managers, Product Owners or Executives they rely on what is called product committee or product board to evolve product decisions. The right product board constitution is a topic for debate but I feel it must have members from Product Management, Product Marketing, Engineering, Regional Subject Matter Experts, Presales member etc. Such product board should be involved in following types of activities

  • Suggest, review and help prioritize the product strategy and roadmaps
  • Contribute into, and in review of, the Product Requirements Documents
  • Represent the interests of individual business units into the product planning process
  • Provide implementation feedback into the product management and development process
  • Review product implementation and provide early feedback in to product development process
  • Tracking of product roadmap dependencies on regional projects and highlight impact of changes or re-plan accordingly

However, I would caution you that until unless these product board activities are made key result areas for the product board members the likelihood of achieving product board goals is very much Product Manager or Product Owners dependent. Only if the Product Manager or Product Owner can use the board effectively then product will be an asset or else it can turn out to be a liability as every product board member will have duties to fulfill.

The best way for such product boards to work would be for any of its member to be able to call for action or meeting for any of the following activities and then run the meeting to till closure

  • Input into product strategy
  • Potential delay to product release date
  • Product or Demo Requirements Document input/review
  • Discuss important Change Request that affects the product roadmap/region/customer

Along with above mentioned product boards I also recommend that you have an executive level steering committee to validate the product strategy and resolve product decision conflicts (should they arise).  The recommended members for product steering committee are

  1. Head of Product Management
  2. Head of Product Marketing
  3. Head of Engineering
  4. Chief Technology Officer
  5. Regional Businesses Heads (when required)

I have seen structure and process being followed in product companies with varied degree of success. What is your experience? Do you use product boards or steering committees? How is your experience with such process?

Tagged with:
Dec 19

Which feature(s) to implement next or first is a difficult to answer question whether you are managing a matured product or trying to build new product? Of course, the question changes to which features to implement first when you are trying to build new product but the conundrum is same.  I tried asking these questions to various Product Managers as well successful Entrepreneurs and although I got different types of answers most of them had few common threads such as

  1. Features, which will make most money
  2. Features, which can be built within shortest possible time
  3. Features, which are absolutely essential for product/release to enter the market

Overall I understood that there were multiple ways to look at the desirability or necessity of the features and most Product Managers or Entrepreneurs try to identify the Feature ROI before they decide to take a shot at implementing it. Some of the considerations of Feature ROI are (grouped by internal and external focus)

Feature ROI Factors PNG

Feature ROI Considerations

The question of which feature to build becomes even complicated (rather painful) for a Product Manager to begin with than for an Entrepreneur. The reason being, in case Product Manager someone in the company (mostly executives) will definitely ask a business case for the prospective release and to illustrate the ROI for the shortlisted features. That doesn’t mean Entrepreneur can escape the pain as he/she may not need to answer anybody the same way Product Manager because the pain comes later when the judged feature(s) do not yield the results expected results.

So the question, which arises now, is “how” can one assess the appropriateness of the feature and then determine the real ROI for above mentioned considerations?

The straight forward answer is that there is no magic formula to address this problem. At the max what a Product Manager or Entrepreneur can do is that try to go to the source of the information where such information can be obtained. For example, the external factors such as Customer Demand & Revenue Potential can be directly assessed with customers or derived from market research data. And, Competitive Necessity & Regulatory Compliance can be ascertained through the industry knowledge or market research.

On the other hand considerations with internal focus are comparatively easy to ascertain as data for such judgment can be requested and obtained through implementation teams. As you can probably guess, experience suggests that ascertaining internal Feature ROI considerations is much easier than external ones as the source of data in case of later is beyond organizational control. Therefore, the guidance is that we take such data with pinch of salt and try expecting lower than proposed returns for external focused Feature ROI considerations.

I personally prefer to solve the most pressing problem(s) for majority of customers. Such approach guarantees that even if I misjudge the feature potential it I end up solving most pressing problem(s) for some customers or relatively important problem(s) for most customers.

What practices do you follow when you have to create a business case for a prospective product release?

Tagged with:
Dec 10

During your concept testing you must make sure that we not only try to understand what customers need from the solution perspective but also validate your business model i.e. why it makes sense for you to build what you are building? It may also be helpful to do further market validation and analysis to ascertain the size of the market. Overall, I see three validations depicted in the picture below, which you will need to perform when you are in concept testing.

Validation BMP

Figure: Validations @ Concept Testing Stage

The market validation is more about validating whether proposed solution makes sense. Since we have already discussed in post How do I know whether my idea is worth to be built into a product I will not elaborate further on that. But I think it will be a good idea to make sure you re-validate your assessment of your solution solving customer problems it intends to solve during concept testing stage as well.

While doing offering validations, in order to understand customer needs I recommend you ask yourself following questions to improve the customer understanding, which should lead you build better user experience for the solution you are trying build.

  1. Who is/are typical user(s)?
  2. How often customer will use the product?
  3. How many users will use this product? (single user vs. multiple users)
  4. In what conditions will customers use the product?
  5. Who will buy the product? What are the motivations behind buying the product?
  6. How much will be buyers willing to pay for this product?

Also, you must answer whether you are building this because solution similar to yours is unavailable or similar solution is available BUT does not meet customer needs. In either case make sure that along with understanding customer problem and solution attributes you start validating your business model. With business model I mean try identifying answers to important questions such as following to gauge sustainability of your product and company.

  1. How big is your market?
  2. How will you make money (both revenue and profits)?
  3. How will you charge the customers? (one time vs. recurring)
  4. How will you sell the product or solution (direct vs. partners)?
  5. Do you have a competitive advantage, which you can sustain?
  6. Do you have any specific competitive advantage? If yes, what is it? How you will use it?
  7. How are you going to make sure that you have demand for your product?
  8. Are you going to need partners? If yes, of what type and why? What will they get? How will you entice them to do business with you?
  9. When you demonstrated prototype, did any customer show willingness to pay for your product?
  10. When you demonstrated prototype, were customers able to associate with your products value proposition and positioning?
  11. How is your cost structure? How much money will be required in near future? How will you get money?

As you can see while trying to answer these questions you will start understating the customer problems as well as the business which plan to build around your solution.

One thing I must say though…lot of gurus say that…if you don’t think you have distinctive competitive advantage then it may not be worthwhile to build offering or product. I beg to differ…because sometimes people don’t know whether they have distinct competitive advantage (like one in the cartoon below) OR it is possible to build one over the initial years.  The only problem is most funding agencies will not be willing to pay you money because they would expect that you have one :) .

Talking Dogs

Tagged with:
Nov 17

Last week I attended NASSCOM Product Conclave 2010 (http://www.nasscom.in), which focused on how product companies can change India’s future and how NASSCOM is trying to bring up an ecosystem, which will help existing product companies to expand their business as well entrepreneurs to start product ventures. I must say that this year’s Product Conclave was well planned to achieve the objectives of bringing the entire software product ecosystem together under one roof to introspect and look ahead at the evolving landscape and the next set of challenges.

During the conclave I had pleasure of meeting Mr. Gabriel Steinhardt, a recognized international high-tech product management expert, author, lecturer and developer of practical tools and methodologies that increase product managers’ productivity. Incidentally Gabriel also heads BlackBlot (http://www.blackblot.com) a product management services companies worldwide, which specializes in helping organizations to evolve their product management professionals.

I also attended a session where Gabriel talked about Product Management & Marketing maturity of the organizations and then demonstrated a spreadsheet based tool to ascertain Product Management Maturity of the organization.  What I could gather was that the maturity Product Management of an organization will eventually impact the business growth and customer satisfaction. The parameters used to ascertain the maturity of Product Management function were as follows

Product Management Maturity Assessment Parameters

Figure: Product Management Maturity Assessment Parameters

On the above parameters you could rate your organization using either 3 point (High, Medium, Low) or 5 point scale (Very High, High, Medium, Low, Very Low) and easily understand how matured your Product Management & Marketing function is.  Of course, it wouldn’t matter how mature your Product Management function is unless you are making your numbers profitably year over year but I think there is direct correlation…may be that can be a topic for another discussion. The bottom-line is that the more matured Product Management function you have the higher the chances of your organization making your numbers profitably.

I know you won’t take my word for it so let me quote what Ms. Carol Bartz (CEO, Yahoo!) said on Product Management during the same NASSCOM Product Conclave 2010 event and I quote

‘To be a market driven company we (Yahoo!) believe that Product Management is very important…‘

What do you think?

Tagged with:
Oct 18

In my last blog I discussed how you can ascertain whether your idea is worth building into product at very high level. In this blog I will try to go over details of what type of activities you should perform, what methods are available and what should you try to learn during your concept testing and market validation of your idea.

During your concept testing and market validation I recommend you to plan on doing at least following research activities to

  1. Target market assessment
  2. Concept/Prototype development
  3. Demonstrate unique value proposition
  4. Validate market for your product & assess saleability

Theoretically speaking concept testing is the process of using quantitative and qualitative methods to evaluate customer response to a product idea prior to the introduction of a product to the market. The various methods generally used for concept testing are

  1. Personal interviews
  2. Focus groups
  3. Structured surveys
  4. Conjoint analysis
  5. Channel interviews
  6. Competitive profiles and benchmarks

You can be rest assured that your market validation process is successful if you have

  1. Understood the existing workflow and business or consumer problems
  2. Assessed the alternate solutions (not competitive products)
  3. Assessed competitive products
  4. Identified benefits the new concept will provide
  5. Quantified the value of product features
  6. Assessed interest in alternative product configurations
  7. Tested pricing sensitivity and demand
  8. Understood the purchase process and decision makers

On a lighter note I remember reading somewhere Jumping into a startup without market testing can be like skydiving without a parachute”

But I beg to differ because I believe that

“Jumping into a startup without market testing can be like skydiving without testing the parachute”.

Jumpt Without Parachute

Source: http://www.cartoonistgroup.com/

The reason I say that is because in my opinion everyone who jumps into a startup almost always believes that they have a parachute (their idea) but only thing they don’t know is whether it will work or not? :)

What do you think?

Tagged with:
preload preload preload

Social Widgets powered by AB-WebLog.com.