RACI chart

Previously we discussed the various steps a product manger is involved in during the innovation and operation phases of a product lifecycle. One may wonder how one person could be capable of so many aspects of product development and management? The answer is they're not. Product mangers need to be a jack of all trades, they need familiarity in all aspects of the product process.

Facilitation: Product mangers, need a strong background in driving initiatives forward, they need to be comfortable speaking in front of senior management; this requires excellent public speaking capabilities along with organisational abilities and the ability to mediate multiple points of view and align a group along one objective. 

Design: Product managers must have a strong understanding of UX design, they need to be able to understand how research is conducted, that the right research is conducted, and that the right audience is being targeted. Product managers also need to often act as the middle man between engineering and design ensuring that designs are validated as feasible and optimal.

Engineering: Product managers must be able to engage with engineering teams, ensuring that engineering understands the designs as intended. Product managers also need to provide enough guidance to ensure that the product is not over or under engineered; factoring in budget and timelines.

Marketing: Product managers need to engage with marketing teams, for an internal initiative, it'll be change management, regardless, the Product manager must specify who the target audience is, what is the value proportion, that the marketing or change process aligns with the overall vision and mission of not just the product/service, but the organisation.

Project management: product managers often times need to work very closely with project managers or even take one many of those responsibilities themselves working cross functionally to ensure the product/service is delivered on time and on budget.

Customer support: Product managers need to be able to ensure that Customer support has everything they need to engage with customers confidently and effectively. 

Ideally product managers have a familiarity of all of the above, but will generally possess a proclivity towards the aspects which align with their background. There is no right or wrong, just which strengths are appropriate to which context.

The product mangers job at the end of the day is to guide the innovation and operation processes, while making sure that each contributor and stakeholder aligns to vision and mission of the product or service; with so many moving parts it's very simple lose track of who is responsible for what. Luckily we can borrow a simple artefact from project management known as the RACI chart.

Responsible: The individual or group who is/are responsible for the actual work of a deliverable, they are the ones doing the "work". 

Accountable: refers to the individual who leads those responsible, this individual must have the authority over those responsible and will be judged by the final output, for example the marketing strategy, their will most likely be a number of contributors, but only one senior who is able to identify what should be done, and what done looks like.

Consulted: refers to the individuals(s) who have expertise or will be impacted downstream and should be consulted throughout each process.

Informed: refers generally to stakeholders who want/need to be kept up to date with progress.

Throughout the innovation and operational processes of a product's lifespan, their can be dozens if not hundreds of tasks; a RACI chart allows us to keep track of who is/was responsible, accountable, consulted and informed throughout the process. Depending on the Product/Service this chart can span anywhere between one to dozens of pages.

A RACI chart could look something like this

The tasks and roles above are not important, it's the concept of clearly being able to understand which role is responsible, accountable, consulted, or informed regarding which task. A RACI chart will target the appropriate communications to the appropriate audience, ensuring that the right people have the information they need while minimising information overlaod. 

Product innovation

There are 8 steps which increase the likelihood that a product will successfully enter the market, though the order of the steps makes logical sense, in practice it is normal to move back and fourth between steps; a two steps forward, one step back sort of situation. This is due to the fact that as the product team moves from an idea through to a prototype they gain valuable insights into the market, the technology, the value and looping those insights back into previous decisions only makes sense. The primary objective is to launch a successful product, whatever pragmatic approach maximises that goal is only beneficial

Conception

Product innovation begins with initial conception, during this phase the initial idea or ideas are explored and shortlisted, the aim is to align business value with innovation. During this phase the goal is to identify business stakeholders, align on a single mission statement, and identify a potential market.

Validation

A business case needs to be created, its aim is to clearly articulate the value of the product, the market need, a competitive analysis if applicable, and a clear vision of how the product has the potential to generate value for the organisation. This business case is not a guarantee that the product will be a success, it is a sales pitch to leadership to show that the proposed product's value outweighs any opportunity cost.

Investigation

After the business case is validated, customer research needs to be conducts, how this is accomplished depends on the target audience and the organisational capabilities. The goal is to contrive a customer value proposition.

Design

Once the product manager understands what the value to both the business and market should be, the design process can proceed. This process generally follows the double diamond design thinking methodology, in short it's an iterative process which follows a divergent and convergent pattern of thinking; iterating over investigation, synthesis, exploration, design. this phase bleeds between the previous investigation and subsequent prototype phases.

Prototyping

After a rigorous design process, the product should be qualified before launch, a or multiple prototypes should be built and used to beta test the product with real customers, to get real feedback and qualify that the product will be adopted by the market.

Goto market

In parallel with the prototyping phase, a marketing strategy as well as a product roadmap need to be defined. The product roadmap lays out at a high level which epics/features will be developed and delivered, often times product rollouts are planned 2 to 5 iterations into the future. These iterations may not be 100% qualified, however they provide a broad brushstroke as to the direction of the product, the planned epics/feature for these iterations can, and should change as the organisation learns more from the market and their customers.

Build

Assuming the prototype phase went successfully it is time to produce the real thing, during this time as production capabilities are being ramped up, the product manger works on a launch plan, reviews the marketing strategy, focuses all their energy on the introduction of the product into the market.

Launch

It is important to remember though the product manager is responsible for all of the various plans and strategies throughout the innovation process, they are not the ones who actually produce all of theses artifacts. Product managers rely on change managers, marketing manager, logistics experts, designers, SMEs, etc; they are responsible for everything coming together.

Conclusion

In conclusion the steps above will not ensure success, but they will increase the likilihood of it. It is also important to keep in mind that regardless of how much capital has been spent, on product innovation, it is infinetly cheaper to fail before building and launching a product than after, always ask yourself does this realistically have a chance of success?

Product lifecycle

The product lifecycle is made up of four high level phases, during the operational life of a product it will move through these phases from market introduction through to product retirement. 

Introduction
This is the phase which the product first hits the market, during this phase the Product manager informs the market, makes the product available to its target audience, collects feedback from early adopter on how to potentially improve the product and iterates quickly and strategically.

Growth
During this phase the market begins to adopt the product and demand increases, potential competitors may also enter the market with similar products; the Product manager must step up 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 and market input and capture as much of the market share as possible.

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 sentiment changes or new disruptive 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 developing the subsiquent iteration to provide the marekt with the same value, however either leverging the new disruptive technology or adhering to new market sentiment.

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 product manager would see the initiative through from its inception all the way to its retirement, here we only focus on the operational lifecycle, in my next post I'll discuss at a high level how to conceive, validate, design, and launch a product.

All products will face an end-of-life market event, that is to say as the market changes, be it for socio-economical reasons or due to disruptive technology almost all products will face retirement. A savvy product manager will foresee this shift in the market before it happens, and begin a wind-down of the product while starting the innovation process for its replacement. 

Products are not valuable in themselves, their value extends to the service they provide. Often times as in the classic example of vinyl records, a-tracks, tapes, music CDs, Digital music players, and now streaming services the demand for the service was always the same, however the mechanism which the market consumes the service shifts as new technology emerges.

Another example is the horse drawn buggy, to the combustion engine, and now electric car, the service the market demands has always stayed the same, however the medium has changed, the difference between these two examples, is that the catalyst for the electric car is arguably not technology. The number one driver is consumer concern over the impact of carbon emissions, the technology just makes the transition feasible; without the driver, despite the technology existing the product would fail.

The above is a high level abstraction, the four phases are far more involved and iterative in nature. As the product moves through its phases the rate of innovation slows and the source of primary insights shifts, though one should never ignore any insights regardless of their source, one should keep in mind the Sigmund Freud's theory that the conscious and unconscious mind imply that what people think, say, and do can diverge due to psychological conflicts and repressions. Or more succinctly:

What people think they do

What people say they do 

What people actually do

are three distinct things

For this reason as the product matures, we begin to rely more heavily on data and analytics, rather than interviews and surveys. That is not to say that those insights are not valuable, however they should be validated with data once it is available. The reason this data is more valuable in the growth and maturity phases, is due to the fact that often times when analysing early adopters one will find that their is only one or two distinct personas, as the product matures and adoption grows; we gain more insights from various personas providing the evidence to cast a wider net.

In the early introduction phase iterations will generally be rapid in nature, what "rapid" means depends on the industry, in software this could mean monthly if not weekly, however in the transportation industry this could mean annually. During this phase it's best to gain insights from early adopters, these insights can propel your product into an exponential growth phase, or they could result in the death of your product. It is important during the introduction phase to focus on aligning iterations to the value proposition. There will be a lot of early adopter feedback, however it is important to qualify this input with long term vision and strategy while maintaining early adopter enthusiasm.

Ideally the product will gain traction and transition to an exponential growth phase, this phase is often the result of strong marketing and early adopter satisfaction. During this phase one should focus on market analysis, look for customers you want and understand how your product can fill the need(s) they have. Iterations will slow down, again depending on the industry, however the goal will be to capture as much market share as possible without frustrating existing customers with changes.

Over time your customer base will grow, competitors will introduce their own products which will solve the same customer problem. During this maturity phase the market becomes saturated, there are no more new "virgin" customers; during this phase the product manager must walk the tightrope of keeping existing customers satisfied, while trying to entice the remaining market to switch to their product. During this phase one should rely more heavily on analytics, how are customers using the product, how can you improve engagement, how can you offer more value than your competitors. During the maturity phase enhancements may be annual and they should be evidence-driven and focused on maintaining customers, while looking to entice competitor's clients to switch.

Finally the product will eventually enter the decline phase, this phase can catch even experienced product managers off guard, most likely a disruptive technology emerges and a new product enters the market which provides the same value proposition, but faster, better, cheaper or any other reason which causes the market to shift to the alternative. Ideally the product manager foresaw this disruptive technology or shift in market sentiment and has already been working on transitioning their existing customers to the next iteration leveraging the new disruptive technology or adhering to market sentiment. Enhancements will be strategic in nature, aimed at transitioning existing customers to the next iteration of the product.

Conclusion

The operational product lifecycle is a minefield, initially it focuses on rapid iteration and entering the growth phase as soon as possible and ideally before competitors. Once the product reaches maturity and the market is saturated, the aim is to maintain customers, while enticing new ones to switch to your product. Finally it is essential to be prepared for an end-of-life market event and have a transition strategy to ride the next wave of innovation or market sentiment. In the ideal world it is your organisation that provides the innovation to disrupt the market.

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.