Measuring Product Maturity

On this page:

Introduction

Product maturity requirements should scale depending on the phase of the product’s evolution. While you may have a similar set of factors that you can use to evaluate a product at each phase, the level that it should be required to achieve should reflect the outcomes needing to be achieved in that phase of the product’s lifecycle.

Example: Let’s start simple with a proposed evolutionary progression of an API assuming the following phases

Phases

1. Exploration | (Outcome: To learn what the problem is)

2. Discovery | (Outcome: To get an understanding of what success looks like and produce a hypothesis for something that could solve the problem)

3. Proof of Concept | (Outcome: To verify for a given hypothesis that a solution is feasible)

4. Pilot(s) aka Alpha | (Outcome: To verify there is demand for a solution and verify that is solves the pilot user group’s problem - Invite only: One first, then two more)

5. Beta (Outcome: To learn whether a solution will scale and continue to be performant and secure - Open to all, with disclaimers)

6. Enterprise (Outcome: to be live without disclaimers or core features that are experimental with a product and teams that account for high volumes and can tolerate high risk initiatives. To demonstrate that the service can operate at this level and still be adaptable, configurable, and cost effective)

7. Refinement (Outcome: To demonstrate system health and service metrics that show correlation and causality to valuable outcomes and indicate preference for your service specific to certain use cases and user groups) => includes retirement of features that don’t fit with your solution and integration with other products that provide that feature with better outcomes.

Proof of Concept

1. at least one valuable end point deployed such that you can confirm that a product outcome is feasible.

2. you have done enough work to get approval to get a real user to try using it

3. The minimum requirements for this phase are

   1. Usability

   2. Accessibility

   3. Security

   4. Scalability to handle demand of new users or increased server load

   5. Uptime, service availability and performance

   6. Disaster recovery

   7. Agility (low cost of change/devops)

Pilot

1. with a single use case you invite one user group to use the product for a specified period of time with the possibility of discontinuing it

2. The minimum requirements for this phase are

   1. Usability

   2. Accessibiility

   3. security

   4. scalability

   5. uptime

   6. disaster recovery

   7. agility (low cost of change/devops)

Extended Pilot or Closed Alpha

1. the number of use cases is extended to more than one, but still on an invite only basis and still with the possibility of discontinuing it

2. The minimum requirements for this phase are

   1. Usability

   2. Accessibiility

   3. security

   4. scalability

   5. uptime

   6. disaster recovery

   7. agility (low cost of change/devops)

Open Alpha or Beta

1. With disclaimers the product is determined to be something to offer and a level of committment is made to support, maintain, and continuously improve the product

2. Use of the product is made available to start using without invitations

3. The formation of collaboration communities emerge to add to and improve the product for a growing user base

4. The minimum requirements for this phase are

   1. Usability

   2. Accessibiility

   3. security

   4. scalability

   5. uptime

   6. disaster recovery

   7. agility (low cost of change/devops)

Live

1. The minimum requirements for this phase are

   1. Usability

   2. Accessibiility

   3. security

   4. scalability

   5. uptime

   6. disaster recovery

   7. agility (low cost of change/devops)

Exemplar

1. The minimum requirements for this phase are

   1. Usability

   2. Accessibiility

   3. security

   4. scalability

   5. uptime

   6. disaster recovery

   7. agility (low cost of change/devops)