Author Archives: Abhay

About Abhay

Abhay has over 15 years of experience in shaping ideas into products that brings profit to business and delight to it's users. He has been instrumental in driving ideas to launches in various capacities and domains. This includes over half a dozen ideas that are today making profit and few that could not survive the tough terrain of product life cycle. Abhay brings in rich experience in building teams, developing products and putting right process in place. Abhay express and share on; https://twitter.com/#!/mathurabhay http://successmanagers.blogspot.com https://productmantra.wordpress.com/

Solving the puzzle – “water proof umbrella”

In my previous post, “Case Study: The Waterproof Umbrella” I wrote about “Out of Context engineers”. Engineers who are working on product or on feature but are not sure about its usage or need. While the earlier post was focused more on challenges, this time it is more about what a product manager should do to help engineers gain contextual knowledge.

There are ways by which you as a product owner can make the out-of-context engineers have a better understanding about product.

Detail requirements along with context : Charity begins at home, so why not start with little extra effort to help engineers understand something more about the product needs. When you write requirement definition or user stories, do ensure to include sections like “feature purpose”, “problem definition”,  “Expectation (from feature on implementation)”. A typical ‘User Story’ with ‘uses cases’ is not good enough for many engineers to understand the context or need, it rather just focuses on solution space and has bare minimal focus on problem definition or customer voice. Including suggested section along with accurate data helps engineers to connect problem definition with use cases and in-turn helps in designing an effective and elegant solution.

Customer experience : It is highly recommended that engineers who mostly have cubicle working habits should be taken out to meet customers, partners and field staff. When you go out to meet customers for a presentation or for a follow-up meeting, take one of these champs along with you. Let them have customer exposure, understand the expectation from horse’s mouth and feel the context. What is being suggested here is not something new but is definitely something which is not practiced so popularly; successful product companies like Intuit does practice this which is termed as “Follow Me Home”. You will also find a reference of this in “Lean Start-up” by Eric Ries. What this does is that it brings in a lot of contextual information to engineers, helps them understand that the customer focus is more on solving a problem and not necessary developing a feature as mostly perceived by engineers.

On many occasions, there are business or legal constraints due to which it is not possible to take an engineer along with you. For such scenarios, ensure that you share experience from customer meeting with the team and help team come to same level of understanding as you are.

Market updates : Send out updates in form of write-ups, ppts or even as a small talk once in a while to engineering team on what’s happening in market place, what is competition doing, newer announcements by government or by compliance agencies which could probably impact a feature or aspect of your product design. You chose the frequency, but ensure do not over-do or be so rare that engineers lose interest in such updates. This is an attempt to keep engineers connected with market place and also help them understand the business aspects of the product. They will sooner or later appreciate such information and also its implication on feature design or product road-map.

It is always advisable to have someone in the team who can challenge your understanding, only to help develop a better product and a better professional out of you. I take this as part of product manager’s responsibility to keep his team connected with the market and in turn with customer. Spend some extra time to detail out things that you might not have been doing, spend some time educating your team to ramp-up their understanding about business and problem you are trying to solve.

@mathurabhay

Case Study: The Waterproof Umbrella

This one is a old story. This happened somewhere, sometime in late 1950s.

Case Study: Waterproof Umbrella

Case Study

AB Corporation is among the leading manufacturer of Umbrellas. They manufacture a range of umbrellas that protect users from rain and blazing sunlight. Competition is heating up as there are many new entrants in the industry and AB corp is facing stiff competition ahead of the monsoon season. The Product Manager of monsoon umbrella proposes new range of attractive umbrellas to increase market share and profitability. Idea is to shred away old type dull looking umbrellas and introduce colorful and stylish umbrellas that just don’t protect from rain but also becomes a style quotient in this monsoon.

So the Product Manager calls for a  brainstorming session with research and development team and puts forward the proposal of launching a new  range of designer umbrellas for this monsoon. He shares following specification with the team;

Key attributes of the umbrella were envisage as:

  1. Weight: 30% lighter than the existing umbrella series.
  2. Cloth color: 6 colors, blue, yellow, white, black, red and green.
  3. Cloth material: 40% Transparent
  4. Tube: silver color, non-corrosive coating
  5. Rib: fiber
  6. Top end: lesser than 2 inch with protected ferrule
  7. Handle: straight (not like hockey stick) with soft leather cover

….other attributes remains as they are today.

Research team found the idea worthwhile and started working on new assignment with various ideas and one fine day invited Product Manager to have look at their new offering. On the day of first demo, Product Manager took this invention in his hand for the first time, it was lighter than what he had planned for and it was looking stunning in those bright colors. A dream come true indeed. That evening Product Manager decides to take one umbrella back home, use it for few days and even show to shppowners in nearby locality to seek their opinion.

Next day morning on his way to office, Product Manager gets first opportunity to use his new umbrella. It started drizzling and our man opened his umbrella and started walking with pride. In no time rain was at its peak and he felt like hero, but only for few minutes. Soon, water started seeping, water cracked through the cloth and starting falling on product manager. No this definitely was not kool. He ran through his way all the way till office, straight into the R&D office. Wet and upset, he started talking to team in an assertive manner, sharing his morning experience. “What a crap have you developed? this could not withstand a normal rain for more than few minutes. How do I sell this?”. The team though was puzzled, they were surprise to see our man in such a mood. “Oh well, we thought you liked the Umbrella. But this one is not a waterproof umbrella. Why did you use this in rain?”. Now that took product manager by surprise, “What do you mean, an Umbrella is supposed to be used when it rains.” The argument continued till Product Manager realized what had happened.

Research team’s understanding was that the new umbrella would be used for protection / shielding against sun light. That’s how it has been traditionally. They had never designed anything other than black umbrellas for rain. To make the matter worse, product manager in his specs never mentioned that the cloth used should be waterproof, specs just mentioned about color and transparency.

Today, at fag end of 2013 we still end up meeting such “Out of Context engineers” who would go on developing anything without learning about domain and market. While a Product Manager may try and detail as  much as he can but the question is more about engineers with very low level of involvement in their work. They are brilliant and once specifications are delivered they would deliver what is asked as mentioned in the document. Now why would an engineer limit his thinking or design to what is mentioned in a document? Why do they miss on something that is so obvious and expected? The out of context engineers often end-up creating such horror stories. Escape route is always very easy: it was not covered in the specifications.

Mitigation

While the engineers would work as they work, what best a Product Manager can do to avoid unplanned bath on road is to set the expectations clearly. Be sure of what you have communicated and be sure that you do routine checks and verification with research team as they work and not at the fag end. There is always too much detailing to do but they are necessary, do not take things for granted, mention all expectations and specifications. A little extra effort may save the day for you, and of-course a pair of clothes as well.

@mathurabhay

5 pitfalls of startup failure

5PITFALLSProduct managers, entrepreneurs and business worldwide are busy solving problems that each of these hope would bring in great relief of their target audience. Outcome is never guaranteed but one thing we know for sure is that, less than 10% of these ideas will actually see a successful life. Most, almost 90+ percentage of these will cease in their early stage. There are many reasons of failure and if you have decided to kick-start your entrepreneurial journey, here are 5 pitfalls that you must be careful of.

  1. Wrong problem. You believe it is a problem which actually is not a problem or you have failed to define it accurately. Who has problem? will he/ she pay to get it resolved? what is the frequency at which problem occurs ? etc – know *.* of the problem before you move on to next step.
  2. Poorly designed solution. You have identified the right problem, but somehow messed up with the solution. Accuracy, efficiency and effectiveness of the solution is not good enough to solve the identified problem and hence even if you have identified and scoped out problem accurately your solution pulls you down.
  3. Bad execution. Poorly defined business process or team selection ends up killing a bright opportunity. People and process when defined and chosen wrongly kills a well identified opportunity and then solution designed hardly matters, you are sure to lose the battle.
  4. No Monetization. For many, monetization plan is either never defined or not thought through properly. Important questions like revenue model, cash flow etc remains unanswered even when product has entered into maturity phase. Profit is purpose of business and this purpose should be well defined in early stages as well should get matured as your product or solution does.
  5. Short Scale. All looks good and you are even making profit. However, making profit is not good enough to sustain a business. How much profit? and at what scale are very important. It is imperative that the idea that you are working on is scalable else you are sure to end up slogging too hard for earning your daily bread and hence it might not be sustainable for long run.

Failing in any of the above aspects would result in competition or substitute offerings eating up your share of pie. Needless to say that it pains most when you fail on to capitalize on opportunities that you identified at right time and in right position. Entrepreneurship is all about taking chances, improving success probability and mitigating risks and you as owner of your business you are expected to take care of these pitfalls.

So what do you do to ensure that you are not victimized by any of these pitfalls. Keep it simple, have these five potential pitfalls noted on a post-it and put on your desk. Never ever let any of these slip out of your thought process. Think about these when you design new feature, when you create deployment model, set revenue targets or when you are working on user experience. Of course there are many validation point that you will come across but validation comes little late than your thought process and your thought process is first check point for you to have optimal path towards success.

@mathurabhay

5 things that Scott Cook looks in a Product Manager

The Power of Product Experiments - insights from Scott Cook, Intuit Founder

Scott Cook in the session

23rd October, 2013 will be a date I will remember for a long time to come. I was among lucky few to be invited by Intuit Bangalore to participate in “The Power of Product Experiments – insights” session conducted by none other than Scott Cook, the founder of Intuit.

While there was tons of learning and insights shared by the champion on product experiment, there was something in particular for product management professionals that I wish to share with you all. Answering to one of the questions from audience on “What traits does he look in a product manager?”, he said:

  1. Passion
  2. Problem solver
  3. Learner (absorb all like sponge)
  4. Someone who gets things done
  5. Subject Matter Expert on something and is willing to learn more

cross posted on : http://successmanagers.blogspot.in/

@mathurabhay

Prevent Product’s Mortality

There are situations when a product manager takes certain steps that are not so commonly expected from the owner of the product, like escalating issues to top executive. While many may consider this as weakness or inability to handle certain situation but at times in the interest of product it becomes important that the product manager escalates certain issues / situation to top executives. Two main reasons that I experienced that caused such a scenario are: “engineering fails to understand business priorities” and “business fails to understand engineering challenges”. And reasons for such a situation are;

  1. Out of sync engineering
  2. Pressure of numbers from business

Out of Sync engineering

Engineering has simply failed to appreciate the business needs. They are working at slower than the expected pace or in a different direction. Engineering must work at the right velocity – a combination of speed and direction; if not, they are sure to miss on certain critical milestones set by business. It only means that in such situations the organization is bound to miss on some of the opportunities and will have to take a hit on either top line or bottom line or both.

Along with speed it is also important that the Engineering works in the right direction. This means that there is no gap between what is expected and what is being developed. While a Product Manager is expected to take care of such deviations many a times the Product Manager becomes a helpless spectator of being overwritten by design limitations, technological challenges or simply by someone in higher up ranks in engineering who is not aligned with the product vision.

This is a situation that I call as ‘out-of-sync’ – the Engineering is out of sync. The least that is expected out of a Product Manager at this stage is that he merely acts like a spectator and let Engineering go out of sync with market/business expectations. It is very much the duty of a Product Manager to ensure that he escalates such ‘out-of-sync’ situations to top executives at the right time for them to intervene and ensure that engineering is back in sync with the business priorities.

Pressure of Numbers from business

Profit is purpose of business and it is this purpose that drives all activities within the organization. When numbers are not met (top line or bottom line or both) the pressure of missing targets is sure to percolate down to all departments and projects.

When winning new orders becomes tough, when supporting legacy product eats up to much of bottom line and with customer satisfaction levels takes a nose dive, it is natural that pressure on new product being developed will be high; this is for a simple reason that everyone in the organization believes that the new product will ease their life and this new product is the only savior.

The probability that this pressure will break the team (Engineering team) is very high. Pressure of numbers has potential to crack and break a well settled voyage. And unless the Product Manager jumps in and escalates such situations to top executives, chances of a complete burn-out is very high; only a soothing balm from top brass will help reduce the pressure on Engineering.

Concluding remarks

While Product Managers own  a product and they are the one who decides on priorities, it would be wrong on the part of the organization to leave everything up to a Product Manager and enjoy the show. For Product Managers it is important to understand that they are the one who must initiate these escalations in the interest of the product and strategy. To win you must have a committed and passionate team and what could be better than to have top management also in your side.

@mathurabhay

Product Manager as Sales enabler

One of the many key roles of a Product Manager is that of a ‘Sales enabler’. This means, helping sales to improvise on conversion ratio, conversion of a prospect to a paying customer. While there is nothing much that a product manager can teach sales about sales, however they can play a crucial role in influencing customer and by helping them in build trust and confidence in product sold to them.

Think of a product manager as a walking & talking “Sales-Solution-Guide”, may be something like a breathing wikipedia of the product. Sales should be able to take them to all potential large customers or even to an existing key customer.  Here product managers takes on greater responsibility of market success and such a shift typically happens largely in introduction and growth phase of the product wherein quick conversion is imperative to the success of the organization.

Here are few value adds that a product owner should focus on while working with sales or running a product demo with customer; remember it is product managers responsibility to be valued and not to be seen as liability:

  1. Know your product, functions and technicalities. Have a very good command of your product features and intricacies of user experience. It would not leave a good impression on customer if you repeat this too often ‘I shall get back to you on this’.
  2. Highlight customer benefits against each feature demonstrated, ensure you speak more of customer interest, few examples: how a particular feature impacts staff productivity or data security. May be even on reliability of data.
  3. Aspects that can be translated to monetary benefit like increase in top line or bottom line should be explained thoroughly. Question audience if they have any doubts over monitory benefits of the product. Typical example: lower cost of ownership for customer (in terms of hardware requirements and maintenance).
  4. Study competition well, as much as you can. Be prepared (or be honest) to answer questions on competition strengths and values that you are still trying to match.
  5. Customers often ask for more, more than what is offered or even required. Know well what level of customization is doable and in what time duration. It gives immense pleasure to customer when they convince a vendor for customization so please do not rob them off this pleasure, be prepared for taking some extra work for engineering.
  6. One of the most common question that I have faced is “how frequently do you upgrade your product and at what cost would we get it”. While on most occasions you will be able to pass on the question related to cost but ‘frequency of software upgrade’ is domain of product manager. You are expected to answer this but be sure that you neither exaggerate nor should you play too safe by being conservative.
  7. Towards the end, buy some time from customer to present technology road-map. Show customer the benefits of going with you, show them what they will miss if they go for alternate product or solution. This matters a lot to the customer and they expect you to present this to them.

I have always enjoyed the responsibility of ‘sales enabler’. I see this as an opportunity to meet and talk to customers whom I represent day-in and day-out in my organization. Perhaps I must say that, it is these opportunities that keeps me up-to-date with customer priorities and market demand, in-turn makes me more effective in my role as a product manager.

@mathurabhay

——

Ladder to Product Management

Engineers largely get into the job without any exposure to sales, operations or financial aspects of the business. In contrast, the role of product manager has its roots in marketing function. The switch in role from engineer to product manager is more of a shift in mindset, something that looks easy on face value but is tremendously difficult to achieve. Given an opportunity, it is wise to get some field experience prior to getting into the routine activities of the product manager. Here are few steps that I suggest that will such aspirants become a better product manager or step into the role of a product manager.

Ladder to Product Management

Ladder to Product Management

Business model: First step is the purpose of existence of any business. What is that is making me money? why are they paying choosing us, buying from and paying us? This brings in a major change in an individuals mindset specifically when he / she is moving from technology to a product management role. Look at your product from a buyer’s point of view rather than an engineer’s point of view, trust me, square looks quite circular when you bring in this change in angle.

Standards: Compliance, rules and regulations are very important. They govern the way business work, products are developed and services are delivered. Feel lucky if you don’t have any such guidance but if you have better master them as they are most important while writing specs or negotiating with customers.

Operations: Knowing about operations is as important as knowing the various practices of the religion one follows. What is to be and how is it to be done and why is to be done. Products developed by software are tested in lab under controlled environment, whereas on most occasions these products are deployed and used in hostile environment with lots of unknowns. Learn about operations as it helps in knowing what can be committed and what not, what should be on road-map and what not, and lastly how to develop and how not to.

Competition: Who else is there and how different are they? What is that they do better and what is it that are not doing good. What could have been done better while developing the product and are pitfalls that should be avoided. Competition helps us understand a larger picture of the product / domain we are in. It helps us understand the taste of customers in various market segments.

Customer exposure: Success of a product is measured by the Customer adaptation of the product. It is very important for a product manager to understand what their prospects and existing customers are expecting out of their product. A first hand customer experience is always preferred as often customer requirements gets diluted as they traverse down to product owners. Learning customer behavior, preferences, challenges and ecosystem helps product owner’s in authoring customer friendly specification and in taking right decisions in the course of the product development.

@mathurabhay