A product manager’s primary roles are, well, um — hmm, that is a good question. A product manager’s main task is doing everything to make sure the product does not fail. A PM is tasked with defining a product’s vision and planning the steps to reach that ideal state for a product. This section will look at some of the typical hats that a product manager will take on. We will look at some of the methods used and provide resources on how to maximize a PM’s effectiveness: the role of the product manager is in companies of different scales, how product managers handle the development of products, and how product managers coerce stakeholders to achieve results.

TL;DR

1. If your product fails, it fails because of you. The product manager is always at fault.
   1. It could mean that the product never addressed core user needs to reach product market fit.
   2. This does not mean you suck at being a Product Manager; it means you have room to grow.
   3. It could mean you are working at a company scale that does not fit your methods, culture, and knowledge.
2. You should see that the role of a product manager in managing products is no small component of a product manager’s job.
   1. Roadmaps, stakeholder management, user research, advanced analytics, 
   2. Product managers wear many hats and can be more technical, growth-oriented, or individual feature-oriented.
3. There are a lot of complexities that can emerge from a product. You should strive to create the best documentation possible to remove uncertainties and show all product components. 
   1. Product managers are industry experts with strong communication skills.
   2.  Product backlog and individual documents for critical decisions that effect your business are of the utmost importance to document.
   3. You can over-document keep things concise and point to the vision and objectives you are trying to set and how you aim to achieve them.

What Is a Product Manager Minus the 5000 USD course?

I have been browsing the web, and there are many cases of product manager resources being inaccessible because a 5000 USD price tag blocks the learning material. At the same time, there are tons of resources readily available on Reddit, Youtube, and various other sites — but they have difficulty condensing what a product manager is. A comprehensive definition does not exist, and that is the problem of the role itself — along with lack of material. 

A product manager does work in these three areas to synthesize a working product

Product managers operate in a function that requires them to lead diversely skilled teams to a common goal—working with developers, artists, marketing, and UA to improve their products. 

Product Managers are supposed to construct roadmaps to clarify where their product will be in a year. These roadmaps are often feature-based (i.e., we will try to ship x features at x time). This means having the forethought to understand conflicts and plan long-term. One tool that I like for making my roadmaps is stormboard that has a simple post-it note system — there are many options such as Miro, or even a simple excel.

Product managers are the voice of the customer and address the critical product strategies to allow for a product to first target customers that are facing a problem and, as a result, need a solution to simplify that problem. Product managers then can define the methods to address these user needs by creating a solution that includes: a value proposition, a feature set, and the user experience. If the product fails, the product manager fails — that is the double-edged sword. 

Product Development Pyramid Showing the Stages of a Product

The product manager is responsible for ensuring that the change being developed addresses the needs it sets out to solve. Depending on the product development framework, product managers can be known as customer representatives, product owners, or visionaries. Product owners determine the needs of the users and then translate those needs into potential solutions. With those solutions, the product owner asks the developers for estimated costs and timelines.

The product manager discovers the user’s needs and prioritizes that need over all other needs based on the market potential, qualitative and quantitative research, and deep knowledge of the problem space. The product manager can bring this information to launch and add value to their product. But companies require a different PM for every product. However, being a PM at a mobile app startup is very different from being a PM at a scaled mobile app company. Let’s dig into that. A good example is Gibson Biddle’s newsletter. Gibson defines three different orientations: starter, builder, and superscalar. A starter will be doing pretty much everything working in a dynamic environment where design, development, positioning, etc., all lie on that product manager to execute. 

For example, a scaled company like Snapchat would be looking for a superscalar or a builder at their stage, highly specialized product management jobs that need experts in those specific areas, or need to become experts pretty quickly. While, for that starter company, a generalist product manager might allow for quicker development and fewer communication headaches trying to reach product-market fit.

Technical Product Manager, Growth Product Manager, Product Marketing Manager, and Product Manager?

Product manager serves as an umbrella term to describe a process that begins with the user and ends with a product that can “cross the chasm” into a product-market fit with great solution design. 

You can see in these examples that these product managers are more feature managers than overarching product managers. They need to define the methods for these individual services rather than the whole product itself. This is because Snapchat has exceptional engagement, retention, and monetization, and as a result, their product is at hyper-scale. 

Growth product managers and product marketing managers are more similar. Growth focuses on both user acquisition and product features. The goal for a growth manager is to deal with a double-edged sword to increase the product’s value. At the same time, a product marketing manager might focus on the marketing coefficients of users, creatives, and channels.

Technical product managers are responsible for managing the work required to deliver a solution that meets the product’s needs and ensuring that the project’s objectives are met. Project managers are accountable for the definition of design at some level in an initiative. In general, you will see that TPMs will have amassed an extensive understanding of technology systems, development methodologies, and even code themselves.

It is not a secret that Linkedin stores a lot of information when searching for a job. You will see that a Snapchat PM posting often contains a clarifying statement check below.

 Product managers in highly specialized feature-based business units

Product managers often receive jobs due to highly specialized experience. In a B2B Fintech company, it would probably be advisable to hire a PM with an extensive background, education, or social connections in the finance industry. Product managers are about the intersection between the product you are making and the users. A technical product manager can often transition from being a developer to building out high-tech products, the same goes for a user acquisition specialist or account executive transitioning to a product marketing manager.

The Product Manager, the Developer, and the User

The product manager, the developers, and the users — what they bring to the table

main roles:

• Discovering Needs: The developer is a great problem solver, but without a product manager, they won’t know which problems need to be solved and what solution to solve them with.
• Tasks Translation: A product manager needs to translate a developer’s technical design or methodology into the user’s problem statement and design acceptance criteria to meet that problem statement.
• Weighing Cost Benefits: Once tickets are decided upon, the product managers monitor and address ad-hoc issues if they were to emerge.
• Opportunity Analysis: With a complete set of information of needs, feasibility, problem, solution, and cost-benefit, a product manager can make an informed decision on which opportunities they should pursue first.
• Priority: Prioritization is where a product manager faces off with other team’s preferences and special interests. There are a lot of methods to convince and negotiate externals. But at this point, the PM should have based their decision of what is essential based on actual data from users and a complete understanding of the problem/solution space.
•  

Agile:

While a technical mindset is not required for product managers is not required. Making a product will be tremendously more straightforward if a PM can speak the language of a product builder. Agile is a flexible mindset that embodies a set of values and principles that involve addressing constant change. This method is based on the principles of the Agile Manifesto.

A method of organization that focuses on:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile is not a single approach but has many different methods to enact change and improve products. Extreme programming, Scrum, Kanban, DevOps, etc., all of these frameworks are to make the development process fit the organization and team. I will cover waterfall (not an agile methodology), scrum, and Kanban, but first, let’s talk about the product backlog.

What is a Backlog and Why Make One?

Now, if you have user stories, you might need an easy method to document them and update them as the product develops over time.

This is called a product backlog because a product can have a ton of new features. Product managers and their teams have to determine what features will come first. This is the process of prioritization. The product backlog offers a central place to store all significant feature requests (Epics) and more minor feature requests. A product backlog is just an organized list of user stories or problems with definitions of acceptance criteria that means the solution the developers made satisfied the ticket. 

For a product manager, the standard method to detail the user stories that a project addresses are to list them in a user backlog. There are many methods to illustrate this backlog, such as creating Excel or a common development platform like Jira. The storage point does not matter, only that the content is there and described in enough detail. 

Product Backlog (PB) is where all stakeholders can access this information:

• Upcoming features (break down to executable units such as user story and subtask)
• Bugs
• Release history and planning

It is the role of product managers to keep the product backlog informative and transparent (If not, the product manager will waste time answering unnecessary questions from stakeholders or fail to communicate). Product managers are communicators at their heart, so all information they produce must be made with communication in mind.

 

Critical steps in working with PM

• Define Vision/Goal/Target to satisfy stakeholder needs
• Populate product backlog with user stories and sub-tasks
• Grooming to have a well-prepared backlog (Normally, the product manager will do this step with input from stakeholders and before the sprint)
  • Categorize into Epic for quickly searching and presenting
  • Prioritize stories/tasks by changing their orders
  • If necessary, break down big stories/tasks into smaller ones to make them more manageable.
  • Update descriptions for stories/tasks based on actual product status
  • Clean up irrelevant stories/tasks

In general, the product manager should spend at least 10-20% of working time to perform those actions, which helps them have a much better image of the product’s current and future. The product manager’s small component is this organizational effort of the product backlog. At the same time, a majority of their time should be spent talking to coworkers in customer-facing roles to understand the current status of user needs better. From constant communication, the product manager updates their strategy.

Critical meetings which will adjust PB

• Monthly/Quarterly planning: where high-level epics and user stories will be proposed and confirmed. Planning is communicating to the company at large and sharing the PM vision/roadmap with stakeholders.
• Sprint Planning: where the product team will execute detailed user stories, tasks, bugs. Sprint planning can be done weekly, bi-weekly, or monthly — depends on the culture and working methodology.
• Sprint Demo: The development team shows their work over the sprint and shows that the product or feature meets the acceptance criteria.
• Sprint Review: The product manager will decide whether user stories, tasks, bugs have been done correctly or need to be adjusted in the next sprint. This is where the development team gets to raise issues that arise and better address them in the future (usually keep doing, stop doing, start doing)
• Monthly/Quarterly review: where PB should be groomed thoroughly based on the insight of previous periods. The PM and the tech lead will often meet weekly to re-affirm the current status and negotiate more clearly what the sprint aims to accomplish.

User Stories:

While motivations offer the product owner generalizable categories that their games can address, a user story is a specific narrative that you have sourced from reading reviews, conducting user research through surveys, or interviewing.

User stories generally consist of five elements: title, description, story point, acceptance criteria, and a definition of done. We will not dive into this entire topic right now. But you can understand how a user story looks below.

As a, I want [so that ]

This is the generic title structure for user stories. They rely on three mechanics.

• User role: A specific user or persona with particular needs that you aim to address in your product’s core value proposition.
• Goal: the story’s goal, which is usually the user’s pain point or the user’s problem. It can also be a feature or function in the product, tool, or pipeline.
• Reason: The benefit to the customer or user when this feature or function is used.
  For example: As a battle royale player, I want a mute player button to stop being distracted by some of the other players to enjoy the game without being harassed.

Notes on User Stories:

What makes a good story? Bill Wake’s article and blog suggested the acronym INVEST, which stands for the following attributes of a good story:

• Independent: Stories should be independent of other stories in the order they are implemented. Dependencies create problems that make them hard to prioritize and estimate.
• Negotiable: Stories are not contracts or detailed requirements. User stories are placeholders for conversation between the stakeholders and the team. Negotiable stories raise questions on purpose because dialogue makes better products.
• Valuable: Stories need to communicate value to the player and the team developing and marketing the game. The product owner adjusts the priority of user stories on the product backlog by judging their worth.
• Estimable: Stories need to be estimated. This requires knowledge about what we are building and how we are going to build it. If not enough is known or the story’s scope is too large, we cannot estimate it well enough. (It’s time to promote that story to epic and break it down into more minor, detailed reports).
• Sized appropriately: Stories need to be small enough to be finished in a sprint.
• Testable: The story should be written so that it is verified before the end of the sprint. Without this, the team cannot determine whether the story satisfied the stakeholders. It’s best to use the conditions of satisfaction on the card’s back to define those tests. Some stories require approval to check off.

Waterfall a Straightforward Development Method

Waterfall project management works best for projects with extended, detailed plans that require one phase to be done before another can start. These projects require a single timeline, and changes are often discouraged and costly. This contrasts with agile project management, which involves shorter project cycles, constant testing and adaptation, and simultaneous overlapping work by multiple teams or contributors. 

 Waterfall Design: generally used for one-off projects, very rigid and step-by-step

• Requirements: This is the stage in which the manager analyzes and gathers all the requirements and documentation for the project.
• System design: During this phase, the manager designs the workflow model for the project.
• Implementation: The system is put into practice in this phase; this is where things get built.
• Testing: During this phase, each element is tested to ensure they work as expected and fulfill the requirements.
• Deployment: (in the case of a service) or delivery (in the case of a product): The service or product is officially launched in this phase.
• Maintenance: In this final, ongoing stage, the team performs upkeep and maintenance on the resulting product or service.

The waterfall method is best used for simple projects or initially designing a product for MVP. As development progresses and the product becomes more complex, trending towards agile methods is advisable. However, the simplicity of waterfall makes your stakeholders love you — if you can deliver a successful product using it.

Scrum Keeping Things Locked and Limiting Refactoring

Scrum functions with a product owner; as noted earlier, the product manager can have the responsibilities of a product owner, especially if a product owner is directly involved with customers, strategy, and business — a product manager and product owner are the same things. Scrum operates on sprints to ship working software at the end of each cycle; there can be technology sprints for tech teams and design sprints for creative teams.

A generic Scrum sprint: Consists of selecting an epic from a product backlog and designing over a week or month into a finalized version that is ready to ship

A lightweight process management framework based on empirical process control scrum aims to limit the input to work scope and increase specific deliverables. Work is performed in a series of fixed-length iterations called “sprints,” which last month or less. At the end of each sprint, the team must produce high-quality working software that could be potentially shipped or otherwise delivered as a product to a customer.

Kanban Matching Work Scope with Developer Speed

It is a lean manufacturing concept born at Toyota rooted in some of the foundational agile development principles, which allowed it to be ported over from manufacturing to tech-product development. Kanban’s process is to handle complex projects and unplanned work by limiting work in progress to focus on one ticket at a time.

A Kanban board: designed to show the actual progress of the sprint, Kanban boards aim to reduce cognitive load and work in progress at any time.

Kanban is very dynamic and does not require fixed iterations. Work moves through the development process as a continuous flow of activity. A key feature is to limit the amount of work underway at any one time (limiting work in progress).

Central to this perspective, the team focuses on only a fixed number of items at any one time. Work may begin on a new item only when required to maintain flow downstream after the previous article has been completed.

The Product Manager and Stakeholders:

A product is only as good as its documentation. Far too often in a company, information is miscommunicated by stakeholders with special interests (most commonly bonuses or OKRs). The most important of these documents is the product requirements document. This is where all critical information, including an executive summary, objectives, detailed product timeline, requirements, and any additional information regarding the product or solution.

Another important document that I instituted in my own work is the ADR (architectural decision Record). Far too often, you will look at a product and wonder why a team decided to hardcode some logic into the product or use some service as a core architecture. This document aims to stop that guessing game for new employees dealing with decisions from two years ago, and every in the original team left. Because of my proximity to the development team in shipping Amanotes infrastructure, we also started a standardized demo document. Every Friday, we detail exactly what the scope of the sprint was. We make this document to deliver to all stakeholders and base it on the acceptance criteria defined in the user story.

Another important document is the Incidence report; when your database dies at 2 am on Sunday, you can make a detailed document on how to avoid that for future Sundays. Finally, one of my favorites is the A/B testing space standardized templates to measure the impact of a feature on product health. At Amanotes, we have our own proprietary testing system, and we document all tests in the same format. Hence, no knowledge is hidden, and we do not retest the same experiment — well, without alterations.

You should see that the role of a product manager in managing products is no small component of a product manager’s job. At the same time, the product manager does not have to be actively constructing the features. The product manager directly issues the design and connection to the business goals to the development team.

There are a lot of complexities that can emerge from a project. A product manager is set to communicate vision, communicate with stakeholders, and act in the best interest of the product’s users — while keeping the business up and running.

If you have made it this far, thank you for reading my blog. This blog serves to document my ideas, learnings, and applying concepts to my min-max framework. Check out this first official post on product development. I am happy to converse with all — reach out at cam@min-max.tech.

Building Moments

I hope you all enjoy your week, with lockdown in Vietnam I have the perfect time to try out Amazon Game’s new MMORPG New World built on the Lumberyard engine.  It is also interesting that Amazon just announced their developer preview for their new O3DE an open-source engine competing with Unity and Unreal.

This week I finally updated my PC’s CPU featuring a B550i from ASUS and a 5800x. First, upgrade since I initially built this PC in university from my salary working at a wine store. Building a PC in Vietnam does not come at a premium, and a CPU update was much needed.

References:

Atlassian. “Is the Agile Manifesto Still a Thing?” Atlassian. Accessed July 18, 2021. https://www.atlassian.com/agile/manifesto.

Biddle, Gibson. “What Are Your Top Tips for a Product Leader Resume/CV?” Accessed July 18, 2021. https://askgib.substack.com/p/what-are-your-top-tips-for-a-pm-resumecv.

Olsen, Dan. The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. 1st edition. Hoboken: Wiley, 2015.

Wake, Bill. “INVEST in Good Stories, and SMART Tasks – XP123.” Accessed July 18, 2021. https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/.