Ah, product management methodologies…based on the term alone you would be led to think that understanding product management management was simply remembering a hard and fast set of rules. The truth is that depending one where you work, the more apt terms to use might “product management suggestions” or “product management omnishambles“.
Glibness aside, what you should take away from comments is that, for want of a better term, as a product manager, you have a lot of professional discretion as to how you go about structuring your workflow. In fact, it is this latitude, fostered by the fact that there are few if any natural or scientific laws that govern our work, that make it such a challenging endeavor.
I’d even go so far as to posit that the reason d’etre of product management methodologies is to reduce the entropy associated with product development.
But before you dive in to product management methodologies, I think we need to do some intellectual housekeeping:
- When many people want an understanding of product management methodologies, of en what they really want to understand is “How do you build software products?” So, to handle this duality, this article gives you the basics for understanding product management methodologies, but also expands into the product development lifecycle, its stages as well as the typical activities associated with each stage.
- Most people entering this professional arena and even semi seasoned professional would benefit from a bit of level-setting with regards to the success of any software product. In fact I think a key component of understanding product management methodologies is knowing that over 50% of all “digital” projects fail:
- BCG estimates that 70% of digital transformation efforts fall short of meeting targets.
- A 2020 CISQ report found that the total cost of unsuccessful development projects among US firms is an estimated $260B, while the total cost of operational failures caused by poor quality software is estimated at $1.56 trillion.
- The Standish Group’s 2020 CHAOS report estimates that around 66% of software projects fail.
Reducing Entropy with Product Management Methodologies
Or maybe I am confusing entropy with chaos. I don’t know, physics wasn’t my thing in school.
What’s the diff really, all I know that as a product manager I want to reduce the disorder associated with pushing the little baby product out of the bird’s nest.
Some say one of the largest challenges facing a product managers is finding the ideal methodology. I say that the biggest product management challenging isn’t finding a methodology, it is having the political savvy and determination to enforce that methodology on the stakeholders so things don’t turn into a total shit show.
While there’s a wide assortment of methodologies to choose from, each one has its own principles, rules, practices, processes, and pros and cons. And, there’s no such thing as a one-size-fits-all approach.
Think of these methodologies as a series of steps that a product manager needs to execute (with the help of a team, of course ) to design, develop, and test a product toward its successful launch/ release. As an aside, you can compare and contrast product management and project management in our article, Project Management Vs Product Management…What’s The Diff.
The biggest issues with all of these methodologies we are going to discuss is twofold:
- Some methodology disciples treat the frameworks like religious dogma.
- They all have shortcomings that become apparent once the rubber hits the road. They often work well in very small companies, but when you start growing teams, they require modification.
Anyone experienced with product management knows that most work environment picks and choosing from different methodologies in order to build their own internal processes. As there are some internal business requirements (like finance) that required greater documentation and planning that out of the box Agile provides for.
So in order to prepare you for the real world, it is essential that I am successful in ensuring you have an understanding of product management methodologies. This means knowing that we are really talking about project management and that these methodologies span a spectrum of rigidity, from Waterfall, with cast in stone product specs and months of top secret development time, to methodologies with Dominique Dawes-like flexibility, in which a project gets divided into the smallest tasks feasible, and code gets pushed live as soon as possible.
One of the most common problems that is universal to all software projects is that are technological unknowns and developing the solution took much longer than intended, so a three-month project estimate actually took six months to complete. Proponents of every single methodology like to claim that this is a problem with every other methodology, but realistically, the problem is universal.
The waterfall method is the oldest development methodology and was used in the writing of the Old Testament. OK, maybe not that old, but it is famous for its “carved in stone” specifications.
As you might guess, the waterfall method is very structured, with explicit, linearly sequenced stages. It’s called “waterfall” because you do not progress from one stage to the next stage until the current stage is done, like water over a waterfall.
- A detailed specification allows everyone to have the false comfort of knowing what the product may look like.
- Works on a product where the requirements and technology are well known.
- With a scope that is fixed early on, engineers have the opportunity to make “optimal” design decisions.
- Theoretically, the project has clear and easily understandable milestones.
- Customers might not know their exact requirements up front.
- Depending on the length of the project, what you build might not meet the customers’ needs when it finally get released. A good initial decision might be wrong when you release the product.
- Limited change management. New data isn’t factored into product requirements that were developed earlier.
- Minimal time constraints on development, which always leads to slippage on the release date.
Waterfall Development Stages
Involves understanding the problem that needs to be solved and requires the product manager to do a lot of the heavy lifting, identifying the right opportunity and writing a detailed product requirement document. Waterfall product requirement documents are detailed and complete, attempting to specify much of the project up front. They are not living documents, but rather large and detailed bibles for the product.
The product requirement document is used to determine the system requirements, hardware and overall architecture.
Creation of the software code in small programs called units. Each unit is developed and tested for its functionality via Unit Testing.
Integration and Testing
The software units developed during the implementation phase are integrated into a system after testing of each unit. Once integrated, software testing continues to find any flaws or errors.
Once the functional and non-functional testing is done, the product is deployed/released into the market. Products often ship with known bugs, as they’d never release if you fixed every bug.
Involves making modifications to the system to fix bugs or improve performance. At this point, product managers are often involved in prioritizing bugs to make sure the ones that will affect customers the most are fixed before release.
Agile development methodologies, of which there are many, focus on building the simplest thing you can, gather user feedback, and then iterate on the product. This focuses you on building the features customers want.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Proponents of agile follow an incremental approach, planning out a relatively small unit of work, build it, gather feedback and then feedback and experience to figure out what to build next. These small units of work can be organized either around time or around a group of tasks.
And this is where I need to pour a bit of water on some ideals here. You also need to recognize that:
- A “small unit of work” and “short period of time” are relative terms
- You still need an overall plan as to where you are going with your product. Even if you follow Agile requirements gathering processes, your plan cannot change with every sprint. In fact, many user stories take more than a sprint to design, code, test and deploy. You cannot be building willy-nilly.
And with that, I will get off my soap box and continue describing agile methodologies
- Openness to change, quick iterations, and delivering working software, building a minimum viable product (MVP) rather than the fully featured product.
- Moving quickly to get feedback.
- Incremental testing during each sprint/cycle, which leads to a higher-quality product with fewer bugs.
As I climb back on my soapbox from before, I would say that sure, in theory, a breadth-first approach where each sprint or cycle “ideally” produces a usable piece software that you can use to get feedback from customers or clients.
The definition of “functional” is quite broad and ambiguous to say the least; what users consider functional and what developers do are two different items. With agile, sprints/cycles are usually focused on getting to a very minimal but functional app initially and then adding features to each section as needed, you can often end up with a bunch of half finished features.
- Agile put a lot more demands on the product manager as new features are being scoped out continuously, sometimes and you will be involved in release management, quality assurance and bug testing.
- You will have a giant fucking backlog, because” Hey, we are agile”.
- An engineering shit show. Solutions require time and if you are focused on delivering new code all the time, you can expect people to take shortcuts, and not be happy about it.
- Scaleability of teams is always hard. Agile can also be tricky to scale to large teams.
- Reactionary development, rather than planning out a roadmap and maintaining a product vision.
How Do You Build Products?
Agile! No, Scrum….wait, let’s try waterfall.
Hang around a tech company long enough and you will have heard some of these terms, and while they are the names of widely adopted methodologies, they are pretty much too high level and un-nuanced to be of use to anyone other than a senior executive making a buzzword based presentation.
Before you can really appreciate and understand different product management methodologies, you need to understand how it is that products get built or otherwise, this will be like learning to drive a car by reading an instruction manual when what you need is experience.
So although it seems circuitous, you need to understand the nuances to understand how all the pieces fit together as selecting the right tool depends on the time and place.
Introducing The Product Development Lifecycle
However, there is one big “BUT” here. When most people discuss methodologies, what they are losing sight of is the tools you actually use to design products. In fact I would argue in most cases, the specific product management methodologies are secondary to the tools of a product manager for three reasons:
- While you can have all the textbook knowledge and certifications associated with each different methodology, you use the tools to get things done.
- Everyone bastardizes these methodologies and uses their own in house flavor
- The same tool can be used across different methodology. Agile or Waterfall, you still need to manage the fucking software product roadmap.
While gallons of nerd sweat has been spent arguing about the intricacies of the product development life cycle (Are there 4 stages? 5 stages? 6 stages? What are the stage called? I think you get the idea, it’s a semantic nerd fest ) , it pretty much goes through these iterative stages, with different product management methodologies being applied.
- Opportunity identification (What problem are you trying to solve)
- Solution design
- Product building
- Marketing/user acquisition
- Gathering feedback
Objective: Figure out a problem that people would exchange something of economic value to solve. In start up companies, this company is pretty much the product, in more mature companies, it probably relates to an existing product. The output of this stage is typically captured in a product requirement document and usually addresses Typically this involves:
- Hypothesis Creation: Identify a problem, that if solved has the most meaningful impact on a company’s goal as measured by the selected metrics (aka Success Metrics). If this is a brand new product, a success metric should monitor how often users complete a core action. If there product is further along in its life, you should be testing and measuring for retention and self-perpetuating success. Product managers often call this process Product Hypothesis Testing in order to sound important 😉
- Opportunity Scoping: Clear identification of the problem, along with high level requirements.
- Learning about the company, specifically its:
- Current products, if they exist. Focus on understanding the company’s core value proposition.
- Goals (ie Growth/Revenue/User Retention) and metrics
- Target customers (i.e. Consumer/Small Business/Enterprise),
- Expertise, and,
- Competitive landscape. You need to know about both competitive and replacement products as well as industry trends.
- Develop plan for the MVP. This a product with the most minimal feature set possible that solved the problem identified by your hypothesis.
Product Management Methodologies/Tools:
- Usage Data/Metrics: Product management and user metrics are the peanut butter and jam of the tech world. Metrics the measurement of different aspects of your product. Success metrics, sometimes called key performance indicators (KPIs), are the key metrics that define how well your product is performing and help validate if our current strategy is working. Success metrics are defined by your current strategy and goal and change over time based on your short-term goals.
- Bug reports
- Customer feedback
- User Surveys.
- User Personas: Used to help you understand your customersWho are the customers, why do they buy. Attempt to segment and group the variability within the customer base. Group common traits amongst our customers in to personas, fictional, typical customers. A single product can have multiple personas associated with it.
- Customer Personas
- Product Roadmaps
- Use Cases
- Wire framing
- Flow charting
- MVP testing
Objective:. Determine the feasibility for the MVP. The PM’s objective is to deliver a prototype that has been validated by both user testing and passed the engineering/design sniff test.
Coordination of activities between internal subject matter experts like engineering and design
Product Management Methodology/Tools:
Objective:. Build something already damn it! You do this by trading off getting something done well versus something done fast.
How: Manage technical debt. Manage the interaction between engineering and design as edge cases and technical hurdles come up during development
Product Management Methodology/Tools:
- Feedback tools
- User Testing
Objective:. Attract new users.
How: Focus on the benefits of your product, not its features
Product Management Methodology/Tools:
- Feedback tools
- Beta testing
- Marketing assets
Objective:. Hit your success metrics and develop suggestions for the next iteration
How: Retrospective meetings and recommendations for future development
Product Management Methodology/Tools:
- Feedback tools
- Beta testing
- User analytics