/
Feature Development Process

Feature Development Process

Feature Development goes through the following stages

Ideation Process

  • Frequency

    • As required if the current Backlog is light

  • Process

    • Select KPI

      • Product Owner selects the KPI for which we are performing Feature Discovery from the KPIs that matter

    • Prepare Input Metrics Sheet

    • Prepare Ideas Impact Sheet

    • Review Ideas Impact Sheet

      • Product Owner and Product Managers rank each Feature idea in descending order of potential Impact

      • Product Owner selects which feature ideas should go into the Backlog

    • Addition to Backlog

Discovery Process

  • Why

    • A Feature must ideally go through Discovery before it is taken up for Spec

    • Building a feature requires investment from Product, Engineering, QA, Design, Devops, Support, Documentation, Program Management and many others. It is expensive.

    • Every new feature added also takes away from the simplicity of your product

    • Adding a feature is generally irreversible. Its expensive. Even if a small percentage of people use it, it makes it hard to retract. Most unused features end up hanging around the product for life

    • Hence adding features should not be taken lightly. There maybe features that do not need to go through the Discovery Track, but when someone has an unvalidated hypothesis / intuition on how a feature may have an impact on a KR, we must put it through the Discovery Track before we choose to build it

    • Discovery stage is intended to achieve the following outcomes

      • Validate the Impact this feature has on the selected KPI

      • Determine whether we should build a Feature. The outcome results in either

        • Discarding that Feature

        • Determining the minimum viable slice of the Feature that should be built

    • A good Discovery process will discard Features with low Impact and ensure only the top x that actually have an impact on the KPI make it through to Spec and Development

  • Deliverable

  • Process

  • Weekly check-ins

    • Each Project has weekly discovery check-ins amongst Product Owner, Product Managers and other relevant folks to

      • Move Discovery Features to Design

      • Discuss status, blockers, resolutions

Design Process

  • Deliverables

  • Process

    • Set Feature status in Jira to “In Design”

    • Fill out the Design Spec section of Feature Development Template

    • The above document along with the flows goes through multiple discussions with

      • Designers

      • Dev lead

      • Product Owner

      • Leadership

    • Review and sign-offs

      • Once the Design Template is ready, circulate amongst seniors and leadership for review

      • After sign-off, the feature then becomes ready for Dev

      • Note that Product teams should be N+3 sprints ahead of Development teams

    • Upon completion of Design stage set Feature status in Jira to “Ready for Dev”

  • Weekly check-ins

    • Each Project has weekly Design check-ins amongst Product Owner, Product Managers and other relevant folks to

      • Move Design features to In Dev

      • Discuss status, blockers, resolutions

Development Process

  • Deliverables

    • Live Feature

  • Process

    • Development occurs in the form of 2-4 week Sprints as determined by the Engineering team

    • Kick-off

      • Participants: Product Owner, Product Managers, Developers, QA, Designers

      • Timeline: 1 week prior to sprint start

      • Deliverable: Final list of “Dev Initiatives” that will make it into this Sprint

    • Set Feature status of the Feature in Jira from “Ready for Dev” to “In Dev”

    • Epic Creation

      • Create one or more Epics for the corresponding Feature and link them to the Feature

    • Task Creation

      • Break each “Epic” into multiple tasks linked to the Epic

        • Dev Tasks

          • Writing code for relevant components

        • Design Tasks

          • Building detailed final design artifact for each screen / flow

        • Copywriting Tasks

          • Providing final copy for each screen

        • QA Tasks

          • Tasks for Functional testing

        • Bug Tasks

          • Any Bugs that arise during QA

        • User Acceptance Testing Tasks

          • Task for PM and UX to check functionality, design and copy after QA sign off

    • Release

      • Release pipeline is maintained and published with all stakeholders upfront

      • Features that need translations are sent for translations

      • Sanity is performed to ensure the build is stable and there are no pending issues

      • Release may be multi-stage ie to alpha, beta and all users

      • Release notes are prepared and published

  • Create a Product Marketing Initiative if Relevant

    • Note that “Marketing Initiatives” are created with Category=Marketing and title “Marketing: <Feature name>”

  • Daily check-ins

    • Each dev sprint has daily check-ins amongst the developers, product managers and designers to discuss status of each Feature, blockers and resolutions

Post Release Process