Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Products don’t start out as perfectly secure, infinitely scalable, and unbreakably robust. Those are just targets we strive for to varying degrees depending on what the product needs to become in order to achieve its vision.

Page Tree
root@parent
startDepth1

On this page:

Table of Contents
minLevel1
maxLevel4
outlinefalse
stylenone
typelist
printabletrue

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)

    1. Outcome: establish feasibility and verify that a certain strategy could

  4. Pilot

  5. Extended pilots or Closed Alpha

  6. Open Alpha / Beta

  7. Live

  8. ExemplarPilot(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)

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

  10. 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)

  11. 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.

Exploration

  1. Qualitative and quantitative research providing evidence for there being an opportunity to solve a problem and provide a return on investment.

  2. You have done enough exploration to have confidence that you understand the problem enough to start work on a potential solution

  3. The minimum requirements for this phase are

Discovery

  1. get an understanding of what success looks like

  2. produce a hypothesis for something that could solve the problem

  3. The minimum requirements for this phase are

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. Requirement Categories

      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. Requirement Categories

      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. Requirement Categories

      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. Requirement Categories

      1. Usability

      2. Accessibiility

      3. security

      4. scalability

      5. uptime

      6. disaster recovery

      7. agility (low cost of change/devops)

Live

Enterprise

  1. The minimum requirements for this phase are:

    1. Requirement Categories

      1. Usability

      2. Accessibiility

      3. security

      4. scalability

      5. uptime

      6. disaster recovery

      7. agility (low cost of change/devops)

Exemplar

Refinement

  1. The minimum requirements for this phase are:

    1. Requirement Categories

      1. Usability

      2. Accessibiility

      3. security

      4. scalability

      5. uptime

      6. disaster recovery

      7. agility (low cost of change/devops)