Category Archives: self improvement

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

Advertisements

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.

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

What’s your concern?

What keeps you concernsawake at night? what is one thing that keeps you on your toes?. The answer to this question is probably the core tenet of your profile and also your  organization’s expectation from you. It is good to know the answer to this question since it also helps in prioritizing your tasks at work. Here are some replies that I often to get to listen.

  1. too many bugs towards the tail end of the release
  2. long backlog list, I have too many features to add to the product
  3. competition, losing too many orders to them
  4. scope creeps
  5. over demanding stake holders
  6. Unreasonable customer demands
  7. opportunities  in market place
  8. too much interference from top management
  9. product road map
  10. …..many more

The answer to this question is important for you. Should this concern be your top focus? Is this concern taking away crucial hours from your planned strategic work, if so you are prone to spend significant amount of your time in coming days doing firefighting. Spend sometime, to begin with may be every week to get answer to this question. List down your top concerns and be sure you have strategic plan for concerns that are your priorities and permanent alternate solutions for concerns that are not part on top of your to-do / KRA list.

@mathurabhay

Simplicity is the ultimate sophistication

I had to drop a cheque to credit to my account; these days regardless of the value of the cheque you can drop them into the cheque drop box and usually the money gets credited to your account in a few days. The problem is when you have a high value cheque and the palpitations are high until the money gets credited – just because you are paranoid about not handing over the cheque to a teller at the bank counter. I headed to ICICI Bank to deposit my cheque and see this drop box

icici

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.

Product Mantra: You are Unique

“You are Unique” is the Mantra of motivation, confidence building and getting convinced that “Yes, I can do this”

Let me start with a confession. This product mantra “You are unique” is borrowed from / influenced by the title of a book authored by the most popular president of India, Dr A P J Abdul Kalam. This book hit the stands a few weeks backs and is already one of the most sought after books in the Indian Market. This book is already in its second print and for sure several more will follow.

{ order this book: Flipkart, Publishers: Punya Publishing}

Continue reading