Category Archives: Management

Questions to Answer before you take on a Problem

Problems are solved to make something easier for the user and financially beneficial to the organization. While it is challenging to quantify and thus measure user benefits (easy to communicate with friends), financial benefits are relatively easily measured in terms of impact on top and/or bottom line.

But before we talk of measuring output let us exclusively talk about the problem. Before you decide to put in efforts and money in solving a problem, let us be sure that the problem has undergone set of quality analysis and is proven worth addressing beyond any doubts.

Am I the right person to solve the problem? (Introspection)

So you have a problem in hand or you are given a problem to solve. The first parameter in the quality analysis metrics of a problem is that “am I the guy who solves this problem?” let us put down an example here.

The technology head who designed an in-flight entertainment system was called to solve a problem of many passengers not viewing the movies while flying. More and more passengers are shutting down the movie in less than 20 minutes. A primary survey results show that flyers did not enjoy the movie.

Airline is worried that these passengers may jump on to competition for simple reason that they do not like our entertainment system and get bored in our flight. So this problem must be addressed before it starts impacting business in serious manner.

The problem here could be related to poor collection of movies, streaming challenges, user interface of entertainment system, sound clarity, related to display quality of the screen or may be something else. Here it is important to appreciate the business challenge but at the same time if you are not the right guy you better make a case and pass it on. For example, what if the poor collection is the cause of this problem? Or even for that matter display screen which might have to be sourced from a vendor. Those being the case, get the screens replaced with better quality screens. Now if there are issues related to poor audio experience, user experience or streaming than the head of technology has a job in hand.

A passionate problem solver often gets carried away in such situations, consequences of which will cause further damage to the business. Here it is important to be wise than good. Identify the root cause, let the problem go to the right person (this is not passing on the buck). You may also end up finding more than one root cause on why passengers do not like the in-flight entertainment system. In such scenarios you may have a part of problem to solve and part may fall elsewhere.

 Do we have the right set of skills? If not can we acquire them? (Feasibility)

If there is a problem that it must be solved. And we you are the one who is expected to do so than it is important that you assess the feasibility aspect as well. In above case of in-flight entertainment system, suppose the root cause identified is “poor collection of movies” and you as a product manager is expected to solve the issue. It is important to understand that the solution here is non-technical (better collection of movies). Answer simple set of questions,

  1. What is preferred set of movies?
  2. Who are my typical customers (professionals, family on vacation, religious people etc)
  3. What will motivate my customers to watch a movie to its full length?
  4. Do I need to have more language options?

And many more such questions need to be answered. Typically a Behavioral science professional may be a better person to solve this puzzle (of collection of movies). So you as a product manager may end up hiring an expert of behavioral science or outsource this puzzle to agency. This is your contribution in solving this problem. Remember every issue is not a technical issue but most issues will have a solution related to human aspect. It is recommended not to stretch your-self to unknown territories but get someone who is familiar with such situations.

 Potential of the problem (scalability and profitability)

So how about measuring the impact of not solving or impact if the problem gets solved? So what if I get some games instead sourcing movies, may be getting games might be easier and cost effective alternate? And even if I source good movies considering the variety in taste is this a viable solution to implement in all the routers. Also, if it is movies the solution may say that we need to regularly update our collection. Can we think of alternates? Will my flyer pay for premium entertainment services like in-flight internet? What entertainment services are offered by my competitors?

The scalability and profitability aspect of a problem will talk about;

  1. Competing and complimentary services
  2. Market size and target market sizing
  3. Pocket size of buyer and their ability and willingness to make payments that suits your pricing
  4. Economics, solving this problem will help me enhance my top-line and / or my bottom line

To judge quality of problem it is important to assess all the four aspects (mentioned in bullet points above) of problem potential. Assess scalability and profitability critically. Challenge every aspect of possible solution, identify impact on top-line and bottom-line and never ever ignore assessing alternate approaches.

 Life cycle, available window of ROI

Well all sounds good, we a have problem for which we have right skill set, is definitely scalable and profitable, but this not where it ends. How about life of the problem? To make healthy returns out of your investment it becomes important that the problem stays for a longer duration and your investment in solution fetches you returns for a longer duration.

In our case study of in-flight entertainment system, what if root cause is seasonal turbulence which might ease out in next 15 days or so. Passengers may not be enjoying movie when the flight experiences turbulence. Or it may be a season where most of the passengers are business travelers who may not want to watch a movie but instead focus on intellectual reading or discussions, could it be season where foreign tourist occupies most seats that are not so keen to watch a movie.

So the point is, if the life of a problem is short it may not be a good idea (on most occasions) to invest (time and money) on such problems. Instead figure out problems that here to stay for long and you have market for longer duration.

To add, here is one more example, a software company was struggling to upgrade their software in a particular geography due to poor connectivity in that region. Company invested heavily on engineering and research activity to solve the problem and figure out light weight upgrades that would work even in low bandwidth conditions. Company took its time solve this puzzle, however in a very short time telecom companies upgraded their infrastructure in the region and bandwidth was at par with other regions in the geography. Now here, if the software company had done some research or if they had got in touch with service providers in the region they would have learned that this problem of low bandwidth is short lived and it is not wise to put our engineering resources in solving a puzzle that would eventually be solved by someone else.

So ensure to have answer to following question

  1. Do I have enough time to recover my investment and make profit? Problem should not get outdated or obsolete in short time.

 Conclusion 

A good problem is the problems that will help my business fetch more money by keeping my customers happy. A happy customer is one who believes (is convinced) that he/ she is getting what is they are paying for or are getting more than what they are paying for. A happy business owner is one who believes (is convinced) that he is selling his product or services at a better profit margins than competitors. And a good problem solver is one who makes both (customer and business owner) convince that they have a reason to be happy.

Hence it is of paramount importance for a problem solver to put the problem through a comprehensive quality analysis before jumping onto solving the problem. So when it comes to solving a problem, this is probably the only way to make both business owner and customer happy.

@mathurabhay

Advertisements

Banish long Sprint Planning meetings

In the Agile world, a Sprint Planning meeting would typically have the Business / Product Owner listing and explaining each story to be delivered and the team goes about doing their best to understand each story based on questions and discussions. The team then estimate the effort needed for each story and commit to whatever they think is feasible within the Sprint duration. For a 2 week Sprint, this typically takes around 3-4 hours.

In many cases, discussions on stories unearth scenarios that need further Analysis by the Product Owner before they can be ready for development. These stories cannot be picked up for development even if they are of highest priority since there are some unknowns about them. This means that the Sprint backlog could consist of stories that are not of highest priority. Also, this results in a long Planning meeting due to more discussions and more stories to discuss.

Is there a way to change this and ensure that the Sprint backlog is filled with stories of highest priority and value? Also, is it possible to have a shorter planning meeting?

Fortunately, the answer is Yes…

The key is to remove the discussions and visit all possible scenarios up front.

The answer is to have an Elaboration session for the next Sprint in the middle of the current Sprint. The Scrum Master gets the team and the Product Owner together for the Elaboration session. Here, the Product Owner presents the stories for development in the next Sprint and solicits questions and feedback. The team and Product owner discuss all possible scenarios and get a complete understanding. There is a huge possibility that some stories might not be ready for development. The Product Owner then has the time to action these before the actual Sprint planning meeting a week later.

This way, the team is fully aware of the stories coming up in the next Planning meeting, the Product owner has time to fine tune his high priority stories and many stories can be committed to and taken up for development without much discussion at the planning meeting. All this leads to a short planning meeting and a less stressed out team. The additional meeting that is added would provide value by unearthing issues up front thus providing enough time for resolution.

I strongly encourage management and teams to try this option out. Do let us know how this worked for you.

Product Management by Committee

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.

remix-monkeys-dance-clan-by-same-cc-by-sa-3-0

When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…

@SampathPrahalad

(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))

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

When the Product Manager is no longer really a Product Manager

When a new game changing feature is introduced, a Product Manager Owner – true to one’s role, does not draw lines limiting responsibilities, owns all the aspects of the feature from operations to user experience to go-to-market. The Owner comes up with the metrics that needs to be measured, works closely with all the departments like the master of an orchestra to ensure that the feature delights the customer and meets business objectives. This will usually take several iterations, pivots based on learning from experiments and sometimes operational changes for the product to gather critical mass and reach a cruising altitude. What happens next usually is that this Product Owner sub-consciously transitions into Product Manager – continuing to manage every nitty-gritty of the feature in a typical run-the-business sort of operation; nothing wrong – perfectly fine. This sub-conscious operation leads to most often playing the roles of Program Manager or an Engineering Manager or an Operations Manager. Organizations can often fail to take cognizance of such a situation and any such protracted scenario can lead to:

  • Professional staffing ignored: Product Manager operating in roles which require specialized skill-set to maximize efficiency can reduce overall efficiency. For example a skilled project manager brings his expertise in efficient resource utilization and a product manager really may not be able to concentrate on that aspect they way it should be done.
  • Reduced strategic thinking: The Product Manager is bogged down by issues that needs to be solved to run the business that he stops thinking strategically from a product’s road map perspective. A product stagnates. Crossing the chasm after a long period gets tougher and interventions become painful.
  • A rock-star Product Manager does not remain one

What should be done ideally?

  • A product manager (ideally the director of product management) should identify when the product’s/feature’s gestation period ends and requires product management not to hang-on to things which are not typically functions of product management. This requires structural changes in the organization and establishment of matrix structures to function effectively
  • The product manager should define process and the corresponding operational metrics required for healthy functioning of the feature and help in setting up specialized teams for the purpose before abdicating some roles which he used to play

Tailpiece

There is another school of thought that Product Managers have to be jack of all trades. Definitely, yes. It is needed during gestation period and perhaps during formative years of the product.

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

Putting on your negotiation hat

IMG_0452

This post is dedicated to one of world’s best negotiators, Nelson Mandela. His negotiations with the South African apartheid government are a great example of a skilled negotiator.

Product managers perform a leadership role within a company, continuously performing various cross-functional initiatives between development, sales, marketing and customer service teams. Conflicts arise often as each team tries to achieve their objectives and one needs to be really skilled at dealing with the differences. It is important to realize that when negotiating, both the relationship with the stakeholders and the outcome of the discussion is very important. A good strategy to follow in these circumstances is the principled negotiation method that is described in the book ‘Getting to Yes’ (Fisher and Ury). Some key highlights of this method are:

  • Focus on interests and not positions
  • Invent options for mutual gain
  • Use objective criteria

Always Focus on interests and not positions
Interests are the needs, desires, concerns, and fears – these are the things one really cares about or wants. They often underlie people’s positions and this is the tangible item that people say that they want. As Fisher and Ury explain:

“Your position is something you have decided upon. Your interests are what caused you to so decide.”

An example of this would be negotiating on features for the next major release. After intense planning with various stakeholders, a product manager releases the plan for the next six months. An executive would like to add an additional feature; the conversation could go something like this:

Executive:  I would need this additional feature in our next release; it is for our most valued customer. It really needs to be in the next six months.
Product manager:  The current features in the roadmap will take six months; this has been carefully planned and estimated. We can consider removing one of the existing features and adding this one.
Executive: That is not possible, our clients are expecting these features, we have already committed to them.
Product manager: What is the reason you need this feature in the next release? Maybe I can suggest an alternative solution?
Executive: I promised our client this feature for the next release some time back, I need to keep to my word.
Product manager: This is interesting, I had a discussion with the same client recently and I am almost sure we can offer them an alternative solution. Maybe we should have a discussion with them and consider our options first.
Executive: Okay, let us go ahead with this discussion.

Note how the executive communicated his position first and his interests were revealed only after asking the ‘why’. Also notice how the possibilities become broader when his/her interests become clearer. Once the interest is revealed, various solutions can be considered.

Inventing options for mutual gain
It is important to generate not just one but many options when considering solutions. Way too often only one option is considered simply because stakeholders believe they know the right answer, and this leads to premature closure.

Product managers must take the lead to understand the problem space and assist in generating various options. He/she has deep product knowledge and also a good technical understanding; this is an advantage when generating creative solutions.

Brainstorming can be used to generate options and it is important to separate the act of inventing options to the act of judging. First invent, and then decide later.

“Expand the pie before dividing it – skills at inventing options is one of the most useful assets a negotiator can have.”

Insist on using objective criteria
Facts and data are really important in negotiation, it is important to seek  “a wise agreement as judged by any objective standard”. During negotiations, never yield to pressure, only to principles.

Executives and managers like to make very strong statements about products, this is great but always keep in mind, these are just opinions. Keep an open mind, invite them to state their reasoning, suggest object criteria and refuse to budget except on this basis. Product managers must drive decisions based on data, this could be: market and customer related data, product metrics, and technical information. At the same time be open to reason and be there to actively listen.