Skip to main content
Feature request development flow explained
Mewis Koeman avatar
Written by Mewis Koeman
Updated over 10 months ago

In this article we explain how we process the recommendations, suggestions and feature requests that we receiver from our valued users.

A challenging aspect when delivering a standard solution to a broad audience is finding a satisfying way to deal with user feedback. We acknowledge the fact that user feedback is an essential element in ensuring a good fit between the product and our target audience. We do however also consider it to be our obligation to make sure we focus on those areas that matter to the community as a whole and not get lost in dealing with a continuous flow of individual needs.

Product suggestions vs Custom development requests
First of all it's important to clarify for all parties how the feedback should be treated. Is the user willing to contribute to the (research) costs related to the requested functionality? If so, project initiation will be started to deliver a fixed price quotation for the feasibility study.

Option 1: Feedback is treated as product suggestion

  • The user is not willing to contribute to the development costs related to the feedback.

  • Costs & Planning: No planning. Suggestions will be discussed periodically within the team but no feedback will be given to the submitter about the outcome (accepted/rejected) or possible planning. Submitting product suggestions is free.

Option 2: Feedback should be treated as custom development request

  • The user is willing to contribute to the costs related to further investigating the feedback.

  • Starts with a short customer-paid Project Specification in which:

    • The team translates the customer's feedback to a level of specification that can serve as the basis for an accurate estimate.

    • Product Owner decides if custom development has the right product fit. If so, a funding proposal is included, in which initial investment and possible Full Return on Investment options are outlined.

    • Time spent on specification is to be paid by the customer. Fixed price based on initial estimate for this first phase.

Full Return on Investment arrangement
This arrangement is set up for situations where the team decided in the Feasibility Study that the requested functionality could be a valuable addition to the standard product.

The basis of this arrangement is that the requestor (customer) pre-funds the development costs related to the requested functionality but that the full investment will be discounted with future subscription invoices.

Example:
A taxi company is using our passenger app with a maintenance fee of €100/month. This customer has now submitted a feature request for which costs were estimated at €1200,-. The product owner decided in the feasibility study that it would be good fit with the standard product.

The taxi company now funds the cost related to the feature request by making a €1200 pre-payment. For the coming 12 months this pre-payment will be fully discounted with the monthly maintenance fee.

Result: The customer gets the passenger app including the requested functionality without any extra costs being charged in the long term. After 12 months the costs would be exactly the same (€1200 upfront equals 12x€100 monthly fee).

  • Costs can only be discounted with monthly fees, no hourly discounting of setup fees.

  • Extra kickback arrangements may be proposed to speed up the return on investment time.

Custom development request step 1: Project initiation

This phase starts when the customer has decided that they are willing to contribute to the development costs related to the feedback.

  • YourDriverApp Product Owner does a first scan of the feasibility based on the requests as described by the customer:

    • Is custom development of the standard product likely enough to justify the investment in a research phase?

    • Is custom development of a fully custom product possible for the feedback?

  • The YourDriverApp team makes a fixed price estimate on the related research costs based on the feedback.

A quotation for the Project Specification (not the actual development!) is sent to the customer.

Custom development request step 2: Project specification

This phase starts after the customer has accepted the quotation sent in step 1.

The YourDriverApp team translates the customer's feedback to a level of specification that can serve as the basis for a final proposal for the delivery of the requested functionality.

Deliverables:

  • Document with a description and basic design of the requested features.

  • Options for custom development on standard product vs custom product are outlined. If the YourDriverApp Product Owner decides that there is not enough fit between the product and the customer's requirement, custom development on a fully custom product is proposed.

  • A funding proposal is made in which initial investment and possible payback options are outlined.

A proposal and planning of forecasted delivery date is sent to the customer


Custom development request Step 3: Development and Go Live

This phase starts after the customer accepts the quotation for the actual development costs.

Deliverables: Delivery of the functionality according to specifications.

If you have a suggestion or product request, please proceed here!

Did this answer your question?