Product Feature Requests

Document created by DMFezzaReed Employee on Oct 8, 2019Last modified by Robert Dell'Immagine on Oct 8, 2019
Version 9Show Document
  • View in full screen mode

What is a Feature Request?

A Feature Request is any suggestion for an enhancement to Qualys software. Feature Requests are not a contractual obligation for Qualys to develop the suggestion or to develop the request as submitted (use case vs implementation). All feature requests submitted will become the property of Qualys. Qualys may use this information for any Qualys business purposes, without restriction, including for product support and development.

What a Feature Request is Not?

Important Things to Know About Our Feature Request Process

  • Qualys strives to continually improve its products, including receiving feedback and feature requests from customers.
  • Requests that have broad applicability, solve multiple use cases, and are strategic to the company are given higher priority.
  • Requests with available workarounds are not operationally impacting, or visual/styling improvements will have lower priority.
  • Feature request development schedules may change at company discretion depending on new requests, other and changing priorities, engineering prerequisites, updated architecture requirements, or other reasons.
  • Not all requests will be implemented. Product Managers will provide an explanation for why we cannot implement a given request.
  • A Feature Request submission is not a contractual obligation for Qualys to develop that request, or to develop the request as submitted (use case vs implementation).

 

Submission Considerations and Recommendations

Sometimes potentially valuable cases do get closed when the Feature Request Use Case has not caught the attention of our team members.

 

If you feel that your suggestion is valuable, consider describing it in detail or outlining how this request might help you, and others, to meet a specific use case.

The content of a feature request is paramount to its acceptance.

 

We strongly recommend contacting your Technical Account Manager (TAM) for assistance preparing a feature request use case that includes:

  • Areas of Functionality: Product and Component, the Usability, Accuracy, Coverage, Management, Performance, API, Other.
  • Feature Request Use Case(s): The use case for the feature request. What is the current problem? What is the expectation? How will benefit your business?
  • Workarounds: Any attempted workarounds. Explain why the workaround is insufficient.
  • Examples: Consider attaching Reports (csv, pdf, xml), Image/Screen Captures (png, jpg, bmp), GIFs, etc. to illustrate the use case you wish to address.

 

Response Time Varies

  • Please set your expectations appropriately. All incoming feature request suggestions are reviewed by the Product Manager for the application/function referenced in the request.
  • Each suggestion must be assessed for its pervasiveness, and level of customer/market interest, before progressing to acceptance for further consideration.
  • Product Managers are very busy individuals. On a given day's list of priorities, with P1 being the highest; P5 the lowest, reviewing incoming suggestions is a P4.

 

Status Updates to Implementation

  • Status NEW: Product Manager is assessing the submission for its pervasiveness, and level of customer/market interest, as a severity/priority 4 (1 high - 5 low); no ETA at this time.
  • Status UNDER CONSIDERATION denotes the Product Manager's assessment of the content was found to have merit and there is sufficient interest to warrant maintaining the request.
  • Status INVESTIGATING FOR RELEASE indicates the Product Manager is partnering with engineering to perform a feasibility assessment; no ETA at this time.
  • Status PLANNED FOR RELEASE suggests the Product Manager is defining requirements; engineering is doing sizing and design; requires dependency with other modules that need to be resolved; potential for tentative ETA at this time.
    • The feature has been defined/refined in terms of the development scope and has been entered into the backlog for development LOE and release prioritization.
    • The suggestion will then be slotted in the roadmap for a targeted release;
      • IMPORTANT: The targeted release is subject to change based on QA cycle (potential findings) and/or development challenges.
  • Status COMMITTED FOR RELEASE indicates the suggestion has been slotted in the roadmap for a targeted release; handed off from engineering to QA; in QA; probable ETA at this time
    • Product Engineering has committed to developing the feature and it has been prioritized for release.
      • A committed status is not a guarantee of release.
        • IMPORTANT: The targeted release is subject to change based on QA cycle (potential findings) and/or development challenges.
  • Status RESOLVED/PENDING VERIFICATION means the suggestion has been fully developed, passed QA and released to production

 

The ETA for the above lifecycle is unique to each request.

  • If you feel you have a waited a reasonable amount of time for a response, but have not received one, please contact your Technical Account Manager (TAM) for an assessment and possible status update.
4 people found this helpful

Attachments

    Outcomes