Tag Archives: Agile

Juan Fernandez @ ‘The Three Questions for Product Manager’

JFJuan Fernandez has been working as a Product Manager for Liferay since 2013, after transitioning from being a software engineer. As a product Manager, his expertise includes product vision definition and development, strategy and product, portfolio management. Juan holds a B.S. in Software Engineering from the university of Seville, Spain.

We thank Juan for taking out time and be part of ‘Three Questions for Product Manager’ series. With Juan we will focus on some of the core aspects of the product management. I am sure you will enjoy reading responses from Juan.

Product Mantra: As a product manager, where would you like to spend more time, talking to customers or working on UX?

Juan Fernandez: I have zero doubts about this: talking to customers (or even better, listening to them) is one of the most critical tasks a product manager has to constantly be doing. Customer feedback, along with market research, is what helps us drive our roadmaps and steer the direction of the product, so, yes, definitely communication with customers is where I’d like to spend more time.

Regarding working on the user experience, I think that it is certainly true that as a product manager it is one of your duties to make sure the experience using your product is delightful, and a decent degree of knowledge in this area is always great, but it’s the User Experience expert, the UX designer, who needs to do the user research and analysis and finally design the optimal experience, not the product manager.

Product Mantra: How would you comment to ‘product managers are a jack of all and master of none’?

Juan Fernandez: I think we are often seen that way, but I don’t like the negative implications of that sentence. I see product management as a role that is needed to connect the dots: a person that brings market knowledge to the product team, and also brings product information to sales, marketing, analysts, customers, etc. Because of that you must be able to wear several hats, you need to be able to understand deeply technical issues, or be part of business talks…and that is why you are sometimes seen as jack of all trades: not a purely technical person, not a pure business guy, always in the middle of everything.

But in spite of this fact, I think a product manager needs to be master of one thing: you need to master the market needs. Having a deep understanding on what your customers need, what the market is demanding, and what those problems are, is the most valuable thing you can bring to the table: that is what you really need to be good at.

Product Mantra: How important is it for a product manager to have experience of project management?

Juan Fernandez: There’s often confusion about these two positions, product and project management, but at the same time they are extremely different.

In my opinion, the key for differentiating both roles is this: the product manager helps define what problems need to be solved while the project manager helps by coordinating the product team in the execution of a solution for those problems. The former is a strategic role, and the latter is a tactical one.

Having clarified this, I’ve seen product managers transitioning from sales, engineering and also from project management positions, and each of them, each of us, have different challenges when adapting to the new position. The challenge for a product manager with a project management background is to leave the control of all the execution details behind and focus on the vision and strategy of the product.

Thanks Juan.

Juan Fernandez on Social Media

  1. Follow Juan on twitter at: @juanferrub
  2. Get connected with her on Linkedin:-  https://es.linkedin.com/pub/juan-fernández-rubio/24/bb3/583
  3. Read his blogs: https://medium.com/@juanferrub

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

3 Key Personality Enhancements from Agile

All over the world, Agile methodologies are changing the ways of working and are leading to faster value realization for both the businesses and customers. The value that Agile methodologies are bringing is evident from the fast paced and the high volume of companies and organizations adopting Agile.

Scrum-personalImpr

However, the angle that we are looking at here are the personality improvements that individuals get from being in an Agile team. These are traits that team members get from working in a self organized Scrum team and will be an asset for life. These traits are visible across most flavours of Agile, but we shall stick to Scrum for the moment.

Small steps with feedback: Scrum advocates frequent small releases to market with valuable content rather than one big release at the end of the project. This way, each time a small release is made, feedback is obtained and is ploughed back into the product to make it better. Scrum teaches you to take small steps towards the goal, not relying on one big jump at a later point of time. Scrum understands that planning is important, but it is more important to get moving. Similarly, with each personal goal, it is good to identify the goal, break it down into smaller parts, implement them one at a time, observe the results and fine tune or change the goal as needed. Many times, the personal goals and resolutions need constant reminding and by making frequent small changes, you are not only keeping the goal alive, you are also taking steady steps towards the final goal. As Ralph Waldo Emerson puts it “An ounce of action is worth a ton of theory”

Effective Improved Communication: Scrum puts power into your hands as a team member. To exercise this power, you have to talk and express yourself in planning and estimation sessions, make your voice heard in daily stand-up meetings and voice your opinions in Retrospectives. Scrum’s rituals are all about being heard without being dominant. Initially, it might be hard for some team members to lose their inhibition, but Scrum’s daily stand-ups, planning meetings and retrospectives urge each one to open up and participate. In a positive way, team members are forced to open up in a trusted team environment and over time, this gives confidence to individuals to be more expressive in bigger groups and forums. Voila, Scrum has made you a better public speaker.

See the other person’s perspective: A team composition in Scrum consists of subject matter experts (SMEs) in Development, Testing, etc. As they plan together and work together Sprint after Sprint, they orient themselves towards the Sprint goal each time. With this, once a person is done with his/her task, he/she is now looking to pick up and contribute towards any other task that needs to be completed to meet the Sprint goal. The team member is picking up new cross functional skills and looking at things in a new perspective along with contributing towards the Sprint goal. Development and testing silos are broken and the team becomes self organized. Each person is able to understand and appreciate the other’s views and experience.
This experience teaches us to think more broadly when we face a situation in life where instead of criticizing a person who holds a different perspective, we try to put ourselves in his/her shoes and think from their perspective. Though this is no rocket science, the experience from working in an Agile cross functional team allows us to pause and listen to a perspective that could be valid and totally different.

Do let us know how your personality has gained by working in an Agile environment.