Product lifecycle

The product life cycle is made up of four high level distinct phases

Introduction
This is the phase which the product first hit's the market, in this phase the Product manager informs the market, makes the product accessable to its target audience, and collects feedback from early adopter on how to potentially improve the product.

Growth
During this phase the market begins to adopt the product and demand increases, potential competitors may also be entering the market with similar products; the Product manager must step of marketing efforts as well as ensure that the product is available. The goal is to continue to iterate the product with new features based on customer input the product and capture more market share.

Maturity
As the product enters this phase, growth tends to flatten out, most of the market has been captured by yourself or competitors, there are no more untapped customers, during this phase the marketing strategy changes from acquiring new customers, to stealing your competitors customers. The product generally has iterations with fewer new features.

Decline
As the market changes or new technologies begin to emerge the product enteres its decline phase, during this phase the product manger's goal is to timely and gracefully remove the product from the market while conducting initial research for the next product.

As the product moves through the four phases the demand for the product grows, levels off, and finally begins to decline, unlike a project manager, the ideal product manager would be focus his or her efforts on that prodcut from introduction through to decline, and beyond.

Stacy matrix

The Stacey Matrix is a framework developed by Ralph Stacey, a British organizational theorist. It's purpose is to help organizations understand the level of uncertainty and complexity in decision-making. It provides guidance on which approaches to problem-solving and management are most suitable in different situations.

The Stacey matrix groups potential projects into four main categories:

Simple: The requirements are clear, there is consensus not only what needs to be built, but the technology that will be used. Projects like this are generally best delivered using a traditional sequential approach. 

Complicated - political: Projects fall into this category when stakeholders agree that something needs to be done, however there isn't consensus on what to do; in situations like this it is best to fall back on UX-research and traditional analysis methods, to further investigate the problem, moving forward without a common vision of success is il-advised.

Complicated - technical: If the stakeholders agree on what needs to be done, however they do not agree on how it should be delivered and choosing the appropriate technology through investigation is not possible, it is best to preform a proof of concept. In a POC the technical doubt is targeted, the development team demonstrates that the chosen technology is fit for purpose. This technical doubt can come in the form of complex features, performance benchmarks, security, or even usability. 

Complicated: whether the the complication stems from a political or a technological challenge, it is best to resolve this and either classify the project as Simple or Complex, this no mans land is often where projects land, generally projects that start without a clear objective or a validated technology have a high risk of failure, irregardless of methodology.

Complex category: these are projects that despite best efforts, there remains a significant level of risk associated with the unknown, either what needs to be delivered or how it needs to be delivered. Projects which fall into this "complex" category are well suited for an iterative approach, the specific methodology, be it Scrum, Kanban, MVP, etc needs to be assessed on a case by case basis.

Chaotic category: initiatives that fall into this category are best avoided, with an extreme amount of uncertainty in regards to both technology as well as scope, it is best to resolve this level of doubt or to consider the opportunity cost of pursuing such a high risk project. Unless absolutely necessary 

To properly classify a project we have to assess the level of certainty of what needs to be accomplished along with how it will be accomplished. 

Assessment of what

1. Do we know exactly with certainty that we are targeting the problem and not a symptom?
2. Do we know the business value of the Solution?
3. Do we have a clear value proposition?
4. Do we know exactly what the outcome will look like?
5. What evidence do we have supporting the above?

Assessment of how

1. Do we know exactly what technology stack will the solution be implemented with?
2. Do we have infrastructure diagrams proving the solution is feasible?
3. Do we have software architectural diagrams proving the solution is feasible?
4. Do we know with absolute certainty that the technology is fit for purpose?
5. Do we have the sign off of the technical team which is to implement the solution?

If we can answer yes to all of the above, then the project is an excellent candidate for a traditional sequential approach, however if the answer to just one of the above is no, then an iterative approach maybe more effective and less risky. If we don't know one of the above, then further research needs to be conducted.