Category Archives: Case Study

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

The Silent Achiever

Here is a good article about the 7 Must Have Project Management skills. I really liked the way that it is laid out and I believe that these skills are Must Haves for a successful Project Manager. However, the skill No. 6 “Recognize and solve problems quickly” rang a bell. I do agree that a Project Manager should be able to see and resolve a problem quickly. However, what I think is a better skill to have is the ability to predict a particular problem or risk before it happens, work on it pro-actively and nip the problem in the bud.

The difference here is between a Hero and a Silent Achiever. Imagine two adjacent fields with dry grass and bushes on a hot summer day. On one, there is a fire caused by the extreme heat while on the other field, there isn’t. A Hero might be seen as one who goes in a helicopter, stoops low and douses the bush fire that is raging. The Silent Achiever is one who realized that the atmosphere is dry and hot, predicted the bush fire and cut the grass or sprinkled enough water on the field to ensure that the bush fire does not occur. So, for the casual observer, it seems to be Business as usual and the effort put in by the Silent Achiever is not usually noticed. Continue reading

Technology: Aids the experience or robs you of it?

Technology aids you and it sometimes overwhelms you. But, have you faced a situation where it robbed you of an experience?? Here is my case in point.

The use of a Digital camera: Helps me to capture moments that can be re-lived many times in later days. I have looked back at pics of family and friends that I took years ago and felt nostalgic about the moments. I am a keen photo enthusiast and love to use a digital camera whenever possible. However, I have at times felt that it has robbed me of experiencing an event as it happens. I recently went to the Sea World at San Antonio where the famous Shamu whale show is held. Me and my 6 year old kid were very excited at the beginning of the show. However, I had thrust upon myself the additional responsibility of capturing pics of the killer whales in action using a digital camera. What happened over the next 20 mins is something that most digital camera users would have experienced. My kid completely enjoyed the experience where the whales were performing various acrobatics and jumping in and out of the water with great precision. Me, on the other hand was trying hard to predict the whale’s next move, pinpoint the exact location of the move in the big pool and point my camera at the right place. And I was usually wrong.. So, by the time I turned around and pointed the camera and clicked, the whale was done with its flawless acrobatic movement and was back in the water. What I was left with was a picture of the turbulence in the water. See some pics below.

ShamuShow2ShamuShow3

Continue reading

Documentation updates in Agile Projects

Scrum and other flavors of Agile expect a potentially shippable product at the end of each Iteration or Sprint. This typically means that each user story within the Sprint has to be developed, integrated, tested, documented and made deployable to production. While this is not new, I have seen many variations to this in my experience with Agile teams. I am going to deal now only with the Release documentation part here. Everything else is out of scope for now.

Consider the scenario below.
In a reasonably small organization, we have the Product Marketing manager Laura who doubles up as Product manager of a desktop application GoldSpot that back-ends with a database server. Laura is responsible for pretty much everything on GoldSpot. She is always seen juggling and shuffling between business case evaluation, wire-framing, product backlog creation and constant prioritization, user acceptance testing, creation and updates to user and admin documentation, customer demos, marketing communication, etc. The product development team consists of 3 developers, 2 test engineers and a Scrum master. The team and Laura meet over Skype for the Sprint planning meeting, the daily standups, Sprint review and retrospectives. The team is in their third Sprint, have just created a prototype worth showing to customers and have 3 more Sprints to go in this Release.
Wanting to adhere to the practices of Scrum, the Scrum master asks Laura to update the User and Admin guides as part of each user story and each Sprint. However, Laura who is severely short of time, finds this to be an overhead to her. Here is her stance. “The product GoldSpot is atleast 3 Sprints away from the Beta Release and has a good amount of functionality and UI changes going in between now and then. If I make updates to the Beta documentation (User guide, Admin guide) in each Sprint, I will definitely have to revisit it in the coming Sprints and over write them when the UI or functionality changes. Also, I am the person who is providing demos to customers and know each feature well. I am showing GoldSpot to customers but not distributing it to them right now. In my backlog of tasks to do, I definitely feel that updating the guides is low priority and something that will move to the top of the list in the final Sprint or the one before that. This is like the customer communication or the training that we do when we get close to the Beta Release.”
I definitely feel that Laura has a point and while Scrum advocates a potentially shippable product at the end of each Sprint, it does not really go into the specifics of what makes the product potentially shippable. I have seen this model work well for Scrum teams where the Release documentation is written by the Product Manager or by a Technical Writer who is spread thin across different products.

Is it then time to take the “Release documentation update” activity out of the Sprint’s Definition of done? Or should we persist on getting it done in each Sprint?

Let me know what you think.

Case study: When you want to expand the target segment of your product

Sunita had just returned back from the product camp in the weekend with some fresh ideas and that got her thinking about what had happened to her product in the last quarter. Sunita was the new Product Manager of her company’s flagship product which faced plateauing revenues – a mid-life crisis for the product, which seems to be quite natural for all products. Challenged with the task of improving the same, she found that the product was once a roaring success (rather it still is) and had crossed many chasms successfully. The product completely concentrated on the small and medium business (SMB) segment of the market. After brainstorming with Steven, the Product Marketing manager and with Molly, the VP of Sales – there was enough market research data that indicated that there was a need for a similar product in the large enterprises. Sunita had taken the strategically important decision of retrofitting the existing product with features required for the large enterprises; this she thought was cost effective – as the expansion of the product line can happen with almost the same product as base.

Three months into the whole exercise – she started getting strange vibes from the market. Continue reading

Case Study: Success was Inevitable

Some time ago, I was assigned a critical task at work. The task was to take the ownership of our new software solution for tablet devices that my company was banking big on. It was a strategic initiative that top executives was hoping high on and the company had a few prestigious customers lined up for demonstrations and piloting the product Continue reading