Michelle is a Senior product management and product marketing leader with a proven record of accomplishments in leading and implementing product management programs in diverse organizations to create, develop and position successful award winning products. Continue reading
Product Managers early into their career might get a bit frustrated when their product features do not sometimes make an impact in the market with the users. Usually, they get questioned on why an investment was made in a feature which has made little or no impact. Does it mean good Product Managers have to be good astrologers? Not at all. If only Product Managers knew what the future is – so perfectly – they could have chosen a profession which is a lot more lucrative – professing the future for world leaders and business conglomerates – who struggle to make the right decisions. Product Managers work on features or products – small and big – some make big impact in the market – some don’t. Does it mean Product Managers are gamblers and work on something at random. Not at all.
Product Managers should have their ears on the ground. They should know the pulse of their users. Essentially a product walks with the foot of the Product Manager. Based on hours of interaction with users, analysis of vast data and knowledge of the market – a Product Manager comes up with what would be the next thing that would solve a (burning) user/customer problem or improve user engagement. It might appear to others as mere intuition – but it is not; Product Management is not Astrology. However, such carefully acquired intuitions can go wrong and make a Product Manager appear more as a Gambler. Again – where the Product Manager’s skill comes into effect is to define what one will measure when the new feature is rolled out and what would be the minimal viable product to extract maximum learning. Essentially – “fail fast” – determine that something is not working and warrants no further investment or needs a pivot based on the learning. There is no gambling involved here.
A corollary of this argument would be when products/features are successful; the same Product Managers are termed visionaries.
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.
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…
(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))
As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.
Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles Continue reading
A product road-map is a schedule of action items that a product owner believes will help improve market share and/or profitability of his product. This list of action items is compiled by processing inputs from various sources including but not limiting to sales, marketing research group, etc (read Collecting requirements and building radar). Action items include product release in newer geographies, features targeting vertical specific requirements, technology (platform, OS, frameworks etc) upgrades, improvised user experience etc along with time lines. Ideally it is talking about priorities with respect to the product life cycle. Continue reading
As the world embraces the Agile methodologies with gusto, it is important to get certain elements right to ensure that the key Agile principles are properly implemented. One such element is Transparency. A mature Product Backlog goes a long way in ensuring transparency.
For the beginner, a Product Backlog is a wish list of features or enhancements that would make your product great. It contains User stories which are features or enhancements written in the language of the end user. Contrary to Waterfall projects which have a baselined and frozen list of requirements, the Product Backlog is kept alive and constantly modified through the life of the Product. It is this changing nature of the Product Backlog that is both an asset and a potential liability. It is important to ensure that the Product Backlog does not become just a stale document of EVERYTHING that might or might not get implemented in the product’s lifetime. It is the Product Manager’s responsibility to maintain a mature backlog and once done, everyone involved in the organization stands to gain from it.
With this background, I shall now attempt to define the characteristics of “A Mature Product Backlog”.
Valuable User Stories: A Mature Product Backlog contains user stories that deliver value to the customer. Each user story should take the product one step closer to the product that the end user desires. Additionally, each user story should have Acceptance criteria clearly listing the boundary conditions, performance criteria and other quality expectations.
Prioritized Backlog: The Product Backlog should be prioritized by the Product Owner in terms of the highest value stories at the top of the list. Another factor to be considered is the Risk involved in implementing the user story. It is a good idea to categorize user stories on Value and Risk and then prioritize the backlog on Value first and Risk next. High Value Low Risk stories would be at the top with the Low Value High Risk stories at the bottom.
INVEST(ed) User stories: A mature Product Backlog has user stories that follow Bill wake’s Independant, Negotiable, Valuable, Estimable, Sized appropriately and Testable (INVEST) mnemonic.
A definite list: The backlog is a list of user stories that will make your product great and it is not possible to only have a certain number of user stories in it. However, instead of having an endless list of small and big features, all I want you to do is a) Keep features that are due to be implemented in the current Release very detailed, b) Group similar features that are part of future releases into Epics and c) Keep user stories from future releases big and break them down into smaller user stories only as you come close to implementing them.
Estimated User stories: This is an Optional requirement for a mature Backlog. It is great to have a Product Backlog with user stories that are assigned story points to determine the size and effort involved. This helps the Product Owner in prioritizing the user stories. For estimating a large number of user stories, Planning poker could be ineffective and the Affinity estimating technique will be a better method.
Over to you now. do let us know if something is missing in this list.
(Pic: Thanks to Flickr: Creative Commons for the Backlog pic)
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.