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

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.