Versions Compared

Old Version 3

changes.mady.by.user Matthew Hall

Saved on

compared with

New Version 4

changes.mady.by.user Matthew Hall

Saved on

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. Proof of Concept

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

  2. Pilot

  3. Extended pilots or Closed Alpha

  4. Open Alpha / Beta

  5. Live

  6. Exemplar

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

...

    1. Accessibility

...

    1. Security

...

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

...

    1. Uptime, service availability and performance

...

    1. Disaster recovery

...

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