A little summary of Product Management
As I work with some of the best Product Managers in the world.
First, let’s take care of some definitions.
Product Managers - These individuals are responsible for communicating the needs of users, or potential users, to product developers on what will appeal to the customer. Woo, in this case, is to cause the customer to desire to use the product.
Will the vehicle have standard doors, Seagull doors, or reverse hinge doors?
Is the report designed for a single customer's use, or is it generic enough for all users?
Are there enough features in the MVP (Minimally viable Product) for the customer to see the value of the product?
Project Managers - This is what people mistakenly think Product Managers are. Project Managers, create transparency. They expose risk, threats, and victories.
Risks - Like when an engineer comments that there are conflicting specifications. Or too many features for the timetable.
Threats - When time tables are dictated rather than discussed with the team building the product. When there is a technology risk, such as a hosting organization retiring support for key components.
Victories - When the product is delivered on time, and in spec. Or when a product developer makes time to provide enough information, in collaboration with sales, to close a deal on another account.
Product Owner - The product owner is similar to a Product Manager, but the Product Manager owns the scope of the product's lifetime. The product owner will own the scope of the features that they want released.
I like to think of it as the Product Manager owning the budget for the product throughout its whole life cycle. But the Product Owner owns the purse from which the developers are paid. If the Product Owner doesn’t sign off on a feature, then it isn’t done.
Scrum Master (regardless of their title) - These guys are the facilitators of everything that the development team needs. They keep an eye out for warnings of failures, so that they can report them. They expose the work of the team members. They work to make sure that all roadblocks have been addressed, if not eliminated or resolved. Their involvement begins at the time the development team is being built and ends after the product is released and the development work is complete.
Sometimes, the Project Manager and Scrum Master for the team are the same person. While at other times, each specializes as needed.
If you have Product Managers and Product Owners, then generally, Product Managers manage more than one product, or if the product is huge, more than one Product Owner is assigned to that mega product. Some companies don’t distinguish between a product owner and a product manager, so they refer to all of them as Product Managers and scale the management according to their title.
Jr - Part of one product, or a small product. IE: Bicycle
Mid - A standard-sized product. IE: Moped or Motorcycle
Sr - Two or more products, or one larger product. IE: Luxury Motorcycle, or Sedan
Principle - Two or more products. IE: 2500 series Pickup Truck, and a Muscle Car
Director - Doesn’t manage products, but does manage Product Managers. IE: All of the above Product Managers.
Another way to categorize all of this is by distinguishing between the Stakeholder Team and the Development Team. Or what we call the Chicken vs the Pig. The chicken (Stakeholder) contributes their egg to the breakfast (Product), but the Pig (Development) is fully committed into the breakfast.
Product Owners, Product Managers, Scrum Masters, Project Managers, etc., are all like Chickens. They are valuable to the delivery of the product, but if they took a week off, with proper preparation, it shouldn’t significantly impact the team.
The hands-on team, or development team, is comprised of everyone who requires technical skills related to the work being completed. These can include Wielders, Home Builders, Roofers, Engine Mechanics, Software Engineers, Test Engineers, Quality Assurance investigators, Quality Control Investigators or Engineers, Plumbers, Electricians, Farmers, and others. The only rule is that if they have to produce a tangible item, such as fruit, a completed building, a road, artwork, or documentation, or ensure that what is being delivered is of the highest quality, then they are in the Pig category. That is their investment.
Now you know what I am talking about, let’s focus on the purpose of this document.
The most important thing a product manager or owner must be able to do is communicate effectively. Then communicate more. And finally, speak again.
Communication Level One
A product manager must be able to answer the great Adverb. Who, What, Where, When, Why, and How.
Who is requesting the feature? If the user is not the same person as the requestor, then who will the user be?
Where on the product does this feature need to be implemented?
When do they need this feature?
What do they need this feature to do?
Please ensure that you separate 'What,' 'Why,' and 'How,' so that the correct details are in the appropriate category. It will help you be detailed, but not overwhelm your development team.
Focus on the output of this feature.
Why do they need this feature?
Is this solving a problem? Ensure the why and the what align well to create a complete picture.
Focus on the benefit of this feature, compared to if the feature didn’t exist.
How will this address their challenge, and how will it be delivered?
Focus on the details of the expectation to ensure that the feature meets the need.
You don’t want a 3-mile-long conveyor belt from a farm to the bakery when the baker just needed a delivery van that can hold enough apples for a day’s worth of baking.
Communication Level Two
Now, answer the question: how can we deliver a fixed amount of work within a specified period in a way that demonstrates progress, but not too much progress? One of the problems in many solution designs is that they may look good on paper, but if you don’t review progress, you may not know how far off the mark you are from the original request.
Let’s assume you plan to show progress every week. That means the WHOLE team, both the Chicken and the Pigs, agree that the iteration rate is every week. It is common to make this every two or three weeks. It is also very common to use a method called Kanban.
Kanban is where you receive a feature request or a whole product request, and the team reviews the request, breaking it down into individual, demonstrable steps. These are commonly called User Stories. However, the User story process is also common when using iterations. Once at least one story is defined, the development team can start working on it. Once all stories are done, the feature is done.
The most significant difference between Kanban and iteration is that Kanban demos at the user story level, as the story is completed. In contrast, Iterations demo the story at the end of the iteration. With Kanban, you have more interruptions during the demonstration process. However, you may find that your interruptions are much shorter.
I prefer Kanban, but I also see the benefit of iterations. This also needs to be a team decision, rather than a top-down dictate. The only exception to this is if you have several teams working on the same product or integrated products, in which case, you may need to have all teams follow the same process to minimize the risk of cross-team interference.
Let’s assume you have finished a feature. It is now time for…
Communication Level 3
The product manager needs to communicate with the stakeholders on what has been completed. Obtain feedback on the completed work, and then either proceed to the next feature or create additional feature notes to detail the deficiency of the demonstrated feature to the development team, so that they may repeat the Level 2 process.
This is more of the art of communication if you have deficiencies. To be clear, you don’t want to start with blame or finish with it. If there is a change, then you have a change or deficiency, and you document it so that it can be turned into more than one story. The development team will almost always be more emotionally invested in a solid product deployment than the stakeholders. The development team wants it out right and on time. I don’t know any development team that wants to work on a feature, then repeat working on the feature, and continue in that loop. That is why the product owner must have access to both the target user stakeholder and the development team for clear communication.
This is where I’m stopping for tonight, because I need to talk about how Software Architects are still needed for software projects. However, this will be a future post.
References
ProductPlan: Product Manager vs. Product Owner. ProductPlan
Wikipedia: Product Manager & Product Owner definitions Wikipedia. Wikipedia
Everything else was just off the top of my head from decades of work.