Product analytics

Product analytics is the act of capturing and analysing how users are interacting with a digital product or service. A product analytics tool is a type of software that captures and exposes usage patterns and insights for a digital products such as web or mobile applications. Beyond capturing simply tracking and collecting data about product usage, the real value that an analytics tool provides is the in ability to data mine this data. At a high level there a three ways to comprehend product usage through data:

Trends
Graph engagements with certain features or pages and compare it against other parts of the product over time.

Funnels
Track the levels of drop-off at each step across a specific subset of features and pages.

Paths
View all journeys that users take, either leading up to or following a specific interaction, as well as a measure of how common or uncommon the next step is.

What product analytics is not:

• Web analytics: whose aim is the collection, analysis reporting of website data in order to improve the web user user experience.
• Marketing analytics: the process of leveraging data to evaluate the effectiveness of marketing campaigns and strategies
• Business intelligence data: is the act of brining together all of an organisation data in order to generate business insights.

Before collecting analytics, the Product manager must identify which analytics to capture, to get started the product manger can ask themselves the following questions:

• How can we ensure that our users are successful with our products?
• What's blocking users from getting value form our products?
• How can we add value to the product that users are willing to pay for?
• Are we building products and features that users want and need?

In the past product manager answered the above questions through a combination of asking questions and intuition, today with product analytics these answers can be found in data, the question is what data, how to collect it, and where to analyse it. Product analytics aims to support intuition with evidence based decision making. Product analytics doesn't replace qualitative data, it augments it with quantitative facts. Helping maximise valued on product decision making.

Quantitative data can tell you what a user did, Quantitative data tells you why they did it. The combination of the two are what a product manager needs to make informed decisions from.

Product analytics tools generally capture two high level types of data:

• Events: any user action in software applications
• Clicks
• Slides
• Gestures
• Play commands
• Downloads
• Text field input

• Event properties: the specific attributes of the tracked interactions.
• Device
• software version
• custom attributes

Tracking and reporting

At it's heart product analytics boils down to tracking metrics and providing visibility of tracked metrics. These metrics need to be tracked at the individual user level as well as the segment level, that is to say for B2B businesses, the individual interactions are important however it's essential to ensure that the organisation you are serving is finding the value they are paying for.

Key product analytics definitions:

• Acquisition: refers to the process of gaining new users of your product. Teams can use product analytics to track acquisition via metrics like new user signups and logins.
• Cohort: a subset of your user base. Cohorts typically have a time component to them, for example your August Cohort of new users. There are also behavioural cohorts, which are essentially the same thing as segments.
• Engagement: this tracks how users interact with an application at the most granular level. You can measure Product engagement with a variety of metrics, for example using Adoption, Stickiness, and time spent in-app.
• Event: An action a user takes within a software product. Some generic examples of events are: Share Dashboard, Select Option, Change View, and Enter New User.
• Funnel analysis: a measurement of how customers move through a defined series of steps in your application. This helps provide clarity as to where users drop off when following these steps, and where they go from that drop-off point.
• Growth: a measure of the net effect of your user acquisition and retention efforts. A product and company achieves growth by adding new customer accounts or by increasing usage within existing customer accounts (or ideally, both).
• Lagging indicators: metrics that you want to move for the health of the business , but may be harder to see results in a short timeframe.
• Leading indicators: metrics that are measurable in a  shorter timeframe, and have a high probability of affecting your lagging indicators.
• Metrics: are a standard of measurement by which efficiency, performance, progress, or quality of a plan, process or product can be assessed.
• Path analysis: a visualisation of what users are doing before or after using a specific page or feature in your application, shown as the sequence of actions that users took before or after the target event.
• Product adoption: also referred to as activation, this measures when users understand your product’s value and perform certain actions, for example engaging with key features and moving through account setup workflows.
• Retention: the percent of users or customer accounts still using your product after they initially install or start using it. Another way to understand if users are continuously engaging with your product is with Stickiness, which measures how many users return to the product on a regular basis.
• Segment: A subset of users that share a common characteristic, or multiple common characteristics. 

Product analytics strategy

Track everything is not a valid strategy, before you decide what to track you must decide what you want to know. Start with an objective, then work your way back to the granular data that you need to collect. Once you understand what you want to know, identify what you information you need to gain insights to your objective, then identify the metrics you need to gain those insights. Some common strategic goals could be:

• Understand user: in order to build the right products and features
• Reduce friction: simplify the use of a product or feature by optimising it to usage patterns
• Increase revenue:  leverage analytics to identify opportunities for customer expansion or comprehend granular ROI per feature.
• Drive innovation: Gain insights in the direction you should take your product based on usage.

The take away is to identify specific objectives, and then work your way backwards to the data you need to support those objectives. 

Metrics

Metrics are the evidence we use to gauge the quality of our product from various dimensions:

Baseline usage

• How many active users do I have today, and in the last week and month?
• How do users get around my product? (what's the user journey map)
• Which features do users engage with the most?
• Are users finding important features of the product quickly and easily?

Adoption

• Is usage of key features increasing or decreasing?
• Which features and pages are users having challenges with?
• Which features do users ignore?

Retention

• How frequently are active users coming back? (understand usage cadence by segment)
• How many users continue using my within the first months?
• How many users who interact with a key feature come back?

Performance

• How quickly is data served to the user?
• How many bugs does our product have?

Value

• How many paying customers do we retain per billing cycle?
• At what rate are we loosing paying customers?
• At what rate are we gaining new customers?

Though there can be dozens of metrics and supporting dimensions which we could capture, there are three primary metrics that all organisations are going to want to understand.

Business outcomes
Represents how your product impacts key business and financial outcomes in both the short and long term.

Product usage
reflect how users behave inside your product, which features are most used or suffer from friction

Product quality 
measure how well does your product technically work, response time, bugs per feature, and so on.

There are Lagging and Leading indicates, lagging indicators measure past performance, they inform you how your product was doing in the past. Lagging indicators are those which you want to move for the health of the organisation, they are difficult to understand in the short term. Leading indicators on the other hand can be measured in a shorter time frame and have a high probability of influencing your lagging indicators. Leading indicators inform you of future performance.

Not only is it not valuable to measure everything, it's also not feasible, this is why as a product manage you must strategically choose the metrics that will provide you with valuable insights. The SMART framework is an excellent rubric to help focus on the metrics that matter most to the organisation.

• Specific: Choose an object with a numeric goal in mind
• Measurable: Ensure that your metric is quantitative in nature
• Actionable: Ensure that each metric can lead to an action
• Relevant: Your metrics should tie back into your objectives
• Timely: A balance of leading and lagging indicators, measure progress over time & understand performance.

For example 

Goal
Upsell freemium users to premium accounts

Strategy
Target heavy users with in-app discounts to incentivise upgrade

Product outcome
Users receive in-app notifications of limited time preferred pricing

Metrics
Track between regular upgrade patterns vs incentivised patterns

Identifying metrics frameworks

OKRs (Objectives and key results)

Is a goal-setting framework utilised by organisations to align teams and individuals with overarching objectives and measure progress effectively. Objectives are high-level, inspirational goals, while Key Results are specific, measurable metrics that define success. 

KPI's (key performance indicators)

Key Performance Indicators (KPIs) are quantifiable metrics used by digital organisations to evaluate and measure various aspects of their performance and success over a period of time. These metrics provide valuable insights into how well the organisation is meeting its goals and can help inform decision-making and strategy.

One metric that matters

(OMTM) is a strategy in which an organisations or team identifies a single key performance indicator (KPI) that is most closely aligned with its primary objective or core goal, and focuses intensely on tracking and optimising that particular metric. 

North star metric

The "North Star Metric That Matters" concept is a strategic approach in which an organisation or team identifies a single, central metric that represents the core value it delivers to its users and aligns all efforts and objectives around optimising that metric over a period of time. Unlike (OMTM) the North star metric is composed of numerous sub-metrics, much like the customer health value.

Check metrics (balance metrics)

Ensure that you are not focusing too much on a particular metric. Check metrics can be thought of a sanity check to ensure that your primary metrics are not obfuscating an underlying issue your product may be suffering from.

Mapping your North star metric

1. Start with mapping your product's vision, what is it's future direction
2. Define what you'r products immediate goals & priorities are?
3. Identify a North Star metric which you can use to measure the core value of your product.
4. Identify how is the North star metric is calculated, what underlying data and what proportions do you they represent.
5. How does your North Star align with your immediate goals & priorities. 
6. List two to five leading indicators that you can track that are likely to cause movement in your North star.
7. Identify any potential consequences of strengthening your north star metric which may be in conflict with your long term vision.
8. Leverage check metrics to observe potential consequences of increasing your North star metric.

Product analytics hierarchy of needs

This is a simple step-by-step hierarchy, to get the right data, properly analyse it then leverage it to bring real change to your organisations decision making and product development processes.

Collect data

this is the last thing you define when establishing a data strategy, but the first thing you need to your hierarchy. Raw data is the foundation of Data analytics. In the Data analytics context data comes in two related forms:

• Data about the people who use the product
• Visitors
• Accounts
• Segments
• User metadata
• Data about how they use the product
• Events
• page loads
• Clicks 
• Feature usage

Refine data into metrics

The second step is to transform your raw data into more meaningful metrics:

• Breadth: A measure of how many total users you have, as well as how many users you have per account.
• Depth: How much of the product your customers are using specifically how many key features of the product They're utilising.
• Frequency: How often are users log into your product in a given time frame.

What is meaningful metrics is context specific to the organisation as well as the product, generally it is recommended to leverage a smaller number of clear metrics that are easily measured and align to the teams you work with around a central impactful objective.

Build metrics into reports

Build reports from your metrics, establish tables and graphs that describe or compare user behaviour over time:

• Track how metrics fluctuate over time
• Identify areas of improvement

Paths: visualisations of what users are doing before or after using a specific page or feature in your application, shown as the sequence of actions that users took before or after the target event.

Funnels: a measurement of how customers move through a defined series of steps in your application. This helps provide clarity as to where users drop off when following these steps, and where they go from that drop-off point.

Retention: are people using the product over time, are they coming back to the product

Take action

Now that your metics are visible through reports you can turn information into action based on tangle data, you are now able to make evidence based decisions.

In order to champion action throughout the organisation the product manage must steel themselves with various weapons to champion change through action.

Tool #1 Analysis

• Review the data you have
• Question the results
• Formulate hypothesis
• Validate your hypothesis.

Tool #2 Share

• open you data
• share your insights,
• leverage a organisational facing dashboard

Tool #3 Storytelling

• Data & insights benefit from a story, what are they saying?
• Share insights in a slide deck
• Contextual information
• Logic
• User quotes 
• Supplemental data

At the end of the day Reports are good, but if you do not take action on the insights gained from them they are of limited value.

Data actualisation

Data actualisation is less of a step and more of a state of being, it is the result of hard work and advocacy. Once your organisation has reached this level they are truly a data informed organisation which leverages:

• Accurate, clean and actionable date
• Ability to ask and answer progressively more difficult questions.
• You'll only use intuition as a starting point, and will be able to validate with metrics

Product-led Growth (PLG)

Product-led growth (PLG) is a strategy in which companies rely on their product to attract and keep customers, rather than focusing heavily on marketing and sales efforts. In a PLG approach, the product is designed to be user-friendly from the start, often allowing people to try it for free or with minimal commitment. Companies also encourage users to invite others to use the product, which can create a chain reaction. They use data and feedback to make the product better over time. As users see value in the product, they might upgrade to paid versions. This approach allows companies to grow efficiently and serve more customers. 

Some key aspects of product-led growth:

• Self-Service Onboarding: PLG products offer a seamless and user-friendly onboarding process, allowing users to sign up and get started with minimal friction. They provide clear value from the start, and encourage users to explore the product.
  
  
• Freemium: PLG companies tend to offer freemium models or free trials, allowing users to experience the product's core features without an upfront financial commitment. This encourages adoption and helps users understand the product's value.
  
  
• Viral Loops: PLG's often incorporate viral marketing tactics, where users are encouraged to invite others to join the platform. This can be through referral programs, sharing features, or collaboration tools.
  
  
• Data-Driven Iteration: PLG companies rely on data and user feedback to continuously improve the product. They make data-driven decisions to enhance user experience, add features, and address pain points.
  
  
• User-Centric: The focus is on delivering value to the end-users. User feedback and needs guide, but do not drive product development and feature prioritisation.
  
  
• Customer Success and Upselling: Successful PLG companies ensure that users have a great experience and receive ongoing support through in-product messaging, chat support, and helpful documentation. As users understand the value of the product, they are more likely to upgrade to premium or paid plans.
  
  
• Low Touch Sales: In PLG, sales teams have a lower-touch role, as many customers are already familiar with the product by the time they consider purchasing.
  
  
• Scalability: PLG allows companies to scale efficiently, as the product itself plays a significant role in acquiring and retaining users. As more users join, generally the cloud infrastructure is expanded in accordance.

In a product-led growth organisation, the goal is to have an almost human free customer acquisition model, where the product itself makes it as simple as possible for users to use, signup, share, and upgrade to a premium version.

In a Product-led organisation the product is at the core of the offering, the entire organisation revolves around the product and thinks about how they can leverage the product in different ways. The product isn't just part of the overall customer experience, it is central to how every function within the organisation performs their roles.

Six characteristics of product led organisations:

1. Align each function around the product: instead of the product being the sole responsibility of the product & engineering teams, the product is central to each department, employees are empowered via the product to better engage with the customers.
• Customer success team: may build in-app onboarding process 
• Marketing: may leverage in-app message to drive up-sale & cross-sale opportunities 
  
  
2. Make decision with data over gut feel: instead of solely relying on intuition, product-led organisations leverage in-app data to make evidence backed decisions.
• Leverage data to sunset unused features
• Leverage data to identify and smooth out friction
  
  
3. Use the product as a marketing channel: leverage in-app messaging to communicate with the user base, segmented and targeted user engagement. 
   
   
4. Amazing onboarding: create a seamless and delightful onboarding experience, their product is simple and intuitive to use. 
• Onboarding is tailored to each user segment
  
  
5. Empower users: to solve their own problems, they provide readily available, context specific support information, allowing users to quickly resolve their own issues without the need to reach out to customer support.
   
   
6. Collect & user customer feedback: leverage user feedback to drive innovation and product direction, user in-app surveys and polls to collect data to make informed iteration decisions.

Jobs to be done framework

The Jobs to Be Done framework is a concept used to better understand and address the underlying motivations and needs of users. Its focus is on the 'job' the user is aiming to accomplish, rather than the product itself. This job could be a specific task, goal, or problem. Customers 'hire' products or services that they believe will help them get the job done more effectively. There are two types of jobs which users hire products to complete, they are functional and emotional Jobs:

• Functional jobs: refer to the practical tasks or goals a customer wants to achieve.
  
• Emotional jobs: refer to the psychological or social needs associated with the job.
  

This framework ties directly into the Product-led organisation by focusing on what the user is aiming to achieve, and providing them the tools to do so. The jobs to be done framework breaks jobs down into functional and emotional aspects, then it continues to break the emotional aspects down to personal and social dimensions.

• Functional: aspects are the basic utility of what the job delivers, the thing that get's accomplished
• Emotional: aspects are the emotions the user feels as they complete the job
• Personal: dimensions refer to how the user feels about the job
• Social: dimensions refer to how users feel other's perceive them about competing the job

Data driven decisions

Whether one refers to it as data driven decisions making, evidence based decisions or just rational, making decisions that are reinforced with data is at the heart of a Product-led organisation. The aim is to eliminate the ambiguity of the 'Gut feeling' and embrace the 'scientific method' to make a hypothesis, test it, and leverage real data to make an informed decision. Some questions the product manager can ask themselves are:

• How sticky is my product?
• Is my feature adoption rate what it should be?
• Are my customers using enough of my product?
• Am I building what my customers want? or what I think they want?

The answer to these questions can be found in real life analytics of the digital product or service. It may be difficult to choose which data points to collect and investigate, this is why it is a good practice to first decide what you want to know then choose the data that will provide you with the information, rather than looking at all the data and trying to decipher what it means

There are three main categories of KPI's to track inside a product:

Business outcomes Customer retention, key business financial metrics, is it selling?

Product usage How is the product being used by users, which features, and when?

Product quality How well does the product technically work, downtime?

Though there could be 100s of various KPI's a product-led organisation may want to keep track of, here are the top 10 KPI's that for certain any organisation will want to know

1. Net revenue retention (NRR): how much revenue is my product retaining from existing customers?
2. Adoption: Are users adopting my product and the key features within it?
3. Stickiness: do users keep coming back to my product?
4. Growth: Is my product acquiring and retaining new users faster than existing users are abandoning it?
5. Product engagement score (PES): how are users engaging with the product overall?
6. Retention: Are users building enduring habits inside the product?
7. Time to value: How long does it take for users to find value in my product?
8. Net promoter score (NPS): are users and customers happy with the product?
9. Top feature requests: what do users want form my product?
10. Product performance: from a technical perspective how well does the product operate?

Continuous delivering 

It is now common place for software as a service (SaaS) companies to continuously deliver functionality, rather than having annual or quarterly releases, it is not uncommon for organisations to release small features weekly and gauge adoption. In SaaS models it is not uncommon for customers to maintain monthly subscriptions, this provides organisations with smaller but more steady revenue streams rather than huge cash influxes once every version.

However this creates much more opportunity for customer churn (the loss of customers or subscribers), Product managers must be ever more vigilant of not just overall product value, but also of granular feature value. Each feature a customer is paying for but not using represents a missed opportunity and lowers perceived value of the product. It is important for product managers to either course correct an inactive feature or consider sunsetting them. Each unused feature costs the organisation money, but does not provide value to the customer.

Communication of new features can prove to be a delicate tightrope, continuous delivery models provide feature updates on a daily or even hourly basis, though these could be summed up in one weekly or monthly or quarterly communication. An effective alternative to indirect communication from out of product channels would be to bring feature communications inside the product; to create informative nudges, educating users by segment of new or upgraded features.

Some considerations to make when forming feature communications:

Consideration #1
Relevance: tailor your communication to the appropriate users

Consideration #2
Desired action: align your announcement to the desired action

Designing a launch plan that accelerates adoption

1. Determine what a successful launch looks like
2. Determine how you will communicate the launch
3. how will you engage customers around the launch

Once a feature is launched there are 3 dimensions to track to gauge how successful of a feature/launch it was:

1. Breadth of adoption: how widely has the feature been adopted by the targeted segment(s)
2. Time to adopt: how long does it take users to begin using a feature.
3. Duration of adoption: how long do users continue to engage with the new feature.

Finally ensure that you provide a mechanism to collect qualitative feedback from users regarding new features. A proactive method to bring user qualitative feedback into future iterations is to listen to the customers voice from your current offerings in order to learn from what you are doing right as well as wrong from the customers perspective. Customer feedback should inform your roadmap, not drive it. An excellent way to validate the importance of feedback is to create a "Product feedback policy", in essence a document which explains how to submit feedback, how often it's reviewed, and how updates are communicated back. This policy signals to internal teams the value of customer feedback, while signalling to customers that their opinions and voices matter to the organisation.

Follow these steps to create a feedback policy:

1. Signal the value of feedback, internally as well as externally
2. Define how can can customers provide their feedback
3. Create a transparent review process
4. Communicate back to customers
5. Get your teams on board

Product operations

Product operations partners and works with the Product, Engineering and Customer success teams in order to:

• Tighten product feedback loops: collect, validate and leverage customer feedback.
• Systematise product development and launches: Leverage defined processes with data driven decision making to create predictable and controlled feature development cycles
• Scale product knowledge across the organisation: encourage cross functional teams, and holistic ownership of the product.

Prod ops focuses on:

• Wrangling data in support of better product decisions
• Managing release schedules and go-to-market readiness
• Coordinating internal and external launches and communications
• Orchestrating the right messages and experiences inside the product

In-app Onboarding

Is the process of helping new users become proficient in your product by leveraging the product itself as an introductory enablement channel, converting a freemium user to a paying customer. Guiding the user to the value they are looking for (the aha moment), drastically increases the chance of that user returning/upgrading to a premium account. There are numerous methods to help users find their way within an application:

Walkthroughs: are guided in-app dialogues which 'walk' users through all the features which they can utilise, the key is to design these onboarding walkthroughs with the following in mind:

• Sell the value of the feature: convince the user it's worth their valuable time
• Link features together: demonstrate to users the synergetic value of the product as a whole
• Help users "learn by doing": inviting users to take actions along the way of the walkthrough 

Tooltips: provide in app points of interest or information, letting user's know of specific granular functionality. These are the most common and often times most valuable to all users, they can provide information of new features or act as a reminder of existing features.

Modals: break the user's flow and should only be used sparingly to inform of the user absolute must know information.

Landing pad: these can be thought of as full screen modal, and should only be used appropriately, generally to nudge the user into one of several options, in situations where they should or must choose.

Blank slates: are referred to as pages in which user creates content, these can prove to be intimidating to users and should be managed via tooltips or some other onboarding mechanism.

Knowledge base: a repository of anything a user may want to know about the product, this information can be disseminated via a dedicated knowledge base, tooltips, modals, etc.

Email: the most appropriate out-of app modality to engage with customers, especially before or after usage.

Products must sell themselves

Consumers in today's market are less tolerant of being told why a product or service is great, and have an expectation of being shown.  Customers no longer respond to flashy advertisements, but want to experience a product before the pay for it. They want absolute assurance, that what they are paying for is worth their time and money. In product-led organisations; marketing partners closely with the product as well as sales departments to provide customers with the opportunity to experiment with most, if not all of the product's features, however with some incentive to upgrade to a premium account. This is known as the 'freemium' model, in essence the customer can try before they buy.

Leveraging in-app messaging, customer health and sentiment data, the sales department can identify leads and directly target them through the application as well as other channels, in essence letting the product sell itself, by identifying freemium users who are good candidates for up-selling or cross-selling. It is the difference between marketing qualified leads vs product-qualified leads.

Marketing-qualified lead (MQL)
Leads which the marketing team deems adequately qualified for the sales cycle

Product-qualified leads (PQL) 
Users who are not yet paying customers but have gained value from the product

MQLs are are leads who could potentially find value with the product, whereas PQLs have already experienced some value from the product; PQLs are far more likely to be upsold to premium accounts, due to the fact that they are already familiar with the product and have first hand knowledge of some of its value. This greatly product experience greatly simplifies the sales team's job to sell the PQL on the remaining value proposition. Finally because PQLs are already familiar with the product, they are a much sounder investment, from a sales as well as support perspective.

Best practices for freemium strategies:

1. Set usage limits and set expectations up front (don't give too much away for free)
2. Monitor heavy usage to target your upsell (target users who frequently use your product)
3. Create valuable premium features (ensure that user's are aware of the premium features)
4. Show results (inform users of added premium value)

Leverage in-app data to gain social proof

Using in-app metrics can help an organisation identify users who are poised to provide high value social proof in the form of: reviews or/and customer testimonials. Once these users are identified the product can solicit these reviews or testimonials through modals or some other in-app mechanism.

The cost of new customers is high

This is why it is extremely important to retain existing customers, by leveraging in-app data you can identify customer at risk of churn and deploy mitigation measures in order to retain them.

• In-app metrics can identify which usage pattern lead to account growth and renewals: this will allow your design team to create experiences that nudge users toward thees positive usage patterns, in which not only do customers maximise their value, but also stay with the product.
• Measuring retention over time see if onboarding is yielding temporary changes in user behaviour or habits that stick: by identifying if your product becomes a consistent part of your users day or week you can accurately predict if you will retain or lose that customer. 
• At a more granular level, you can leverage in-app metrics to identify which features are being heavily used, and which are not: this will inform you which features are sticky vs one's which your users may not be gaining any value from. 

From your metrics you can create a customer health score and segment customers into three groups: 

• Unhealthy: customer which may already be lost, the cost of retaining them may not be worth it
• Healthy: customers who are the best candidates for cross-selling
• Neutral: customers with the potential to not only become advocates, but move into healthy status.

Establishing this "health score" is no easy feat, it takes a lot of analysis and understanding of unique data points and weighing those points to best represent the customers health score. Once you have established these "health scores" you can:

• Use data to better inform interactions with customers.
• Automate in-app interactions: nudge low-usage customers to high value features.
• Land & expand: help existing users do more inside the product.

To create a customer health score:

1. Star by capturing every metric that may provide insight into a customer's health score
2. Group those metrics into categories that make sense, these categories may be deduced from the actual metrics you identify, however some potential groupings could be:
• Product adoption
• Sentiment
• Support experience
• Purchasing behaviour
3. Prioritise the features by time frame 
• Choose 3 to 4 features that you could incorporate into your score in the short term.
• Repeat for medium and long term features, create a roadmap of product features and how the metrics inform a customers health score.
4. Associate metric groupings to features and provide weights
• Product adoption (30%)
• Sentiment (10%)
• support experience (20%)
• Purchasing behaviour (40%)
5. Create an action plan for customer health status:
   
• Healthy customer: Ask them to speak at an even or provide a referral
• Neutral customer: Nudge them to more value-added features, try to convert them based on what health grouping is holding them back.
• Unhealthy customer: Offer a coaching session or target them with content to help them gain more value from your product or service.

Product management lifecycle

The product management lifecycle is how product managers conceptualise, build, launch and iterate on software products. It is a tried and tested high level framework for how great products are built or improved, it can viewed as a map to help guide product teams to a successful, value added product.

Define a business objective

The product management lifecycle begins with defining a clear business objective: Defining a business outcome from the onset anchors the product, the team, the stakeholders to a particular value added target; it allows the product manager to ask the question "does this benefit our objective?" if the answer is no, then it's not needed.

Some potential business objective could be:

• Increase retention: what features & functions will provide value to users
• Reduce costs: improve UX to decrease the burden on the companies support team.
• Gain market share: Improve existing functionality or create new industry leading capabilities.
• Digital transformation: transition a legacy paper system to a digital one, reduce user error, etc

Discover phase

During the discovery phase, the aim is to uncover the pain points of both your customers and the larger market; this phase is all about understanding the problems and challenges faced by your users and potential users, what do they want and need, what is stopping them. Here you can begin to identify potential solutions, however you will not settle on one until the validation phase. It is common to leverage the double diamond design thinking approach for the discovery phase.

The discovery phase is as much art as it is science, this is where the bulk of the solution forming is done. During this phase research is preformed, interviews are conducted, experiments are preformed. It is here that one or more potential solutions are designed. During the discovery phase there are three main research aspects, focused discovery (what the product is suppose to do), data-driven discover (what the evidence says people are doing); UX research: (what people think, say and actually do).  

• Focused discover: Be as focused as possible during discovery, specifically on the issues that are preventing the business outcome. 

• Why does the business want this feature/product?
• What is the goal the features/product aims accomplish?
• Is the solution the right way to solve the problem?
• What customer feedback has already been received?
• What job (jobs framework) is the customer trying to get done?
• What customer personas/segments are we targeting?
• What problems do users encounter in the product?
• Are users doing what we expect in the product? if not, why?
• What do power users do differently?

• Data-driven discovery: Leverage the knowledge internal teams posses, Product data usage, and direct customer feedback

• What does the workflow of our core users look like?
• What do our successfully retained users do in the product?
• Where do users we don't retain drop out of the product?
• What are customers actually trying to accomplish?
• What features do retained customers engage with the most?
• Do you see usage patters in the rest of your user base?
• Where did users who churned drop out of workflows?

• User research: Also referred to as exploratory research, product managers usually conduct this during the discovery phase to get the lay of the land and gain a contextual understanding of their users.

• User interviews: 1on1 interviews where you can ask open ended questions.
• User surveys: collect input from a large group at once
• Card sorting: shows how users categorise and organise information
• Observation: watching user's interact with the product or service.

Validation phase

During the validation phase the objective is to choose the right solution(s) to move forward with, this is accomplished by collecting data and leveraging it to make an informed decision. The knowledge gained from discovery phase feeds directly into the validation phase, here you can validate one of your preliminary solutions, or come up with a completely new one. The import thing is to make an informed decision as to which solution(s) to pursue. One of the most important answers that you will find during the validation phase, is the why we are pursuing one solution over another. Some questions you may ask yourself are:

• What outcomes are resonating most with customers?
• How can we best solve for our customers' pain?
• What don't we know about customers' workflows that may help in building the solution?
• How do we curate a diverse set of customers for interviews? 
• What pain is so deep that customers would pay for a solution?

The validation phase provides the product manager with the needed information to:

• Priorities which solutions to build
• Manage stakeholders better, by reinforcing decisions with evidence
• Invest in the most value added resources and features

Experimentation & Testing

During the Validation phase, once a solution is selected, the project manager should run some experiments in order to test their decisions: 

Evaluative testing: (if you do not have an existing product)

• Prototype testing: Upfront testing executed before building anything
• Fake door test: inviting customers to use a feature that isn't created/released yet to see gauge level of interest
• Man behind the curtain testing: An orchestrated solution that does not actually exists, (an agent posing as a chatbot)

Live experimentation: (if you have an existing product)

• Putting things into the product to see how they work
• Making functionality available tow a small subset of your user base before going into a deeper build
• A/B testing: putting out two versions of a feature and seeing which performs better. 

There are three main rules to experimentation:

1. Choose the right experiment, decide what you want to learn, then leverage the appropriate experiment to gain those insights
2. Choose your audience, ensure that the user's taking part in your experiment have an interest in what you are building.
3. Use the data you've gained to make an informed and justifiable decision, whether to pivot or not

Build phase

During the build phase, the product manager must partner with engineers and product designers to ensure that the validated solution comes to life as intended; think of these three as the holy trinity of product development, only when the product manger can work openly and cohesively with the design and engineering teams, can the solution reach its full potential.

up to this point the defined solution is an idea, a theoretical solution to a problem. Now it's the product managers job to ensure that the implemented solution correctly aligns to the defined solution; keep in mind that feasibility may become an issue, your solution may have technical constraints and my require a pivot. This is why a close relationship with both the designers and engineers is essential. During this phase you will share and rationalise your product roadmap.

There are three main delivery models which Product designers must be familiar with with:

• Waterfall: generally the waterfall model has five main stages: Analysis, design, development, testing, support. In this model the product moves through each phase once, this model relies heavily on analysis and design as well as accurate estimation.
• Agile: a more common iterative approach in which teams work in sprints, time boxed iterations in which the team commits to a particular set of user stories to deliver, which are then validated at the end of each sprint. Between sprints the product owner decides whether to continue or not.
• Continuous: a modern approach in which multiple features can be worked on simultaneously and as a feature is completed it is tested then released, sometimes multiple times a day.

The main responsibility of a product manager is to create and enforce the Product requirements document or PRD. This document captures and communicates:

• Key project information: stakeholders, key personal, timeline, current state
• The objective: The overall aim of the product, the value proposition for the stakeholders as well as the value propositions for the users. It clarifies the problem(s) we are aiming to solve.
• Assumptions: include any assumptions which had to be made (technical, business or user), and why they could not have been validated through experimentation or data.
• User stories: include any key information from discovery or interviews from users/stakeholders
• Designs: Any prototype testing that was conducted, High fidelity screens, visual assets which describe the proposed solution.

Launch phase

During the launch phase the Product manager must create a launch plan to make ensure that customers adopt and continue using new functionality. Here the product manager must work closely with Marketing, Sales and Customer success teams to build a go to market plan that is scaled to the size and importance of the release. Some questions to consider for the launch phase

• How to ensure that users know about the new feature or product
• How to foster internal readiness within the organisation
• How to educate users about the value of the new feature or product
• How to encourage adoption of the new feature or product

When launching a release there are three main considerations the product manager must take into account.

The three main considerations when coming up with a launch plan are:

1. What is the size of the release? is it a new product that requires a full PR campaign or is it a small feature release that can be communicate in product.
2. Who is the target audience, is it the entire user base or a segment or multiple segments. what are the characteristics of the target audience.
3. What is the desired action, what is the goal of the launch campaign, is to inform users, to encourage a particular action. Be sure to indicate a clear call to action.

Incremental launch tactics

Now a days, digital products are rarely released, but more often are trickled out, small MVPs are released sometimes to a wide audience, and sometimes to a small subset of users, here are a few incremental launch tactics 

Evaluation phase

During the evaluation phase the product manger leverage quantitative as well as qualitative data to evaluate the success of a launch, and use the insights gained for future lifecycles. Quantitative data tells you what happened whereas qualitative data provides the context as to why it happened, both are important to learn from and improve future product management cycles.

Quantitative metrics to evaluate a feature launch

Three useful analytics tools to support the above quantitative metrics are:

• Paths: help you discover what users are doing before or after using a specific page or feature.
• Funnels: the measurement of how users move through a defined series of steps
• Session replay: Enables you to record and visually replay a user's session in the product.

Qualitative metrics to evaluate a new product or feature

Three useful channels to observe in order to support the above qualitative data are:

• Customer support channels: Identify common themes and recurring problems
• Social media: monitor for users' feedback and opinions
• Customer sentiment: Examine Net promoter Score (NPS) before and after a launch

Iteration phase

During the Iteration phase the product  manager reflects on what was built and how it can be improved, and append/updates the product roadmap accordingly:

• How can we improve the product experience?
• Do we need to tweak our goals or focus?
• Should we double down on what's really working?
• Are R&D teams working on the right projects?
• Is this moving us closer to our business goal?

Product management

Before we dive into product management, let's first discuss the difference between Project and Product mangers. Product managers are responsible for the overall product strategy and its long-term success, whereas project managers are responsible for the successful execution of specific projects. 

In essence product managers focus on the big picture of a particular product or service, whereas project managers focus on the details of project execution, they are more concerned about budget, time and resources. Project managers are connected to phases of product development, keeping them on time and on budget, whereas Product managers are connected to the lifespan of the product itself. A product will most likely see multiple project managers, whereas it will ideally only have one product manager for it's life cycle.

As you can see if a product has multiple phases; each phase can have a different project manager, however each product or service should have only one Product manger.

Product management is an ever evolving field, it started as a feature factory model, which was more of a reactive approach to product development; it has now evolved into a outcome driven mode.

Feature factory model

• Can't measure the impact of their work
• Have frequent failures
• See poor product and Feature adoption
• Lack strategic focus
• Have unhappy customers

Outcomes driven model

• Can articulate how their work impacts the business
• Have fewer failures
• See strong adoption
• Clear focus and an exiting vision
• Have happy customers

We've gone from reacting to feature requests to planning and foreseeing them, product management is no longer about designing a feature upgrade, but having a planned roadmap of features, which are designed before they are requested.

The product manager's responsibilities

1. Setting the products mission and vision (product strategy)
2. Aligning stakeholders around the product vision
3. Shipping great software that delights users
4. Understanding customers and their problems
5. Understanding the business goals and define what success looks like
6. Prioritising the backlog of features
7. keeping up with industry trends and competitors

Theses are broad and non exhaustive responsibilities; the role of the product manager is to live and breath the product; to understand what the business value is to the stakeholders is, as well as what is the value proposition to the users is, and how those two support each other. 

Depending on the organisation there can be multiple types of different product managers, each specialising in a specific domain.

Product managers have 5 high level capabilities that drive their success:

1. Businessmen: they understand the value proposition of the product, they understand how the product will benefit the organisation's financials.
2. Leaders: the can inspire and communicate to their teams as well as stakeholders, they can rally developers, designers, data scientist, etc behind one common vision.
3. Scientific: they make evidence based, data driven decisions, they don't make gut decisions or guesses as to what customers want or need.
4. Goal oriented: focus on outcomes, tie features to business value
5. Responsible: they do not allow technical or design debt to accumulate, they balance trajectory with maintenance.