Tag Archives: product management

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

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))