Stage 6
Feedback Loop

When it comes to being successful in business, the impact of collecting (and responding to) customer feedback cannot be underestimated. Continuous focus on listening to your customer and responding to their needs will drive higher levels of customer satisfaction. The same is also true for being successful with your no-code application — your ability to listen (and respond) to quality feedback from your users and stakeholders will significantly improve your odds of exceeding expectations.

Now, in traditional software development, user feedback is typically part of a user acceptance test (UAT), which comes at the very late stages of the development lifecycle. This classic approach to UAT has some typical challenges:

• It delays user feedback until too late in the cycle, when it can be expensive to address. There is always pressure on the need to “go live,” resulting in user feedback being ignored or deferred.

• UAT is always rushed and time-compressed. If there are delays in finishing the software, it may delay turning software over to UAT, but there’s still pressure imposed on the business function to release the software, resulting in either overwork or cut corners — or usually both.

• If there are major alignment issues discovered late during UAT, this can sometimes derail the project. You create a no-win situation where it’s impossible to go live (because of misalignment), and you have no other option but to go back to requirements or design activities to restore the project. This results in a tremendous amount of wasted time and effort.

Rather than delaying feedback to the end, no-code allows you to take advantage of a more continuous feedback model (as shown in the following figure). Instead of feedback only happening at one point in time, we collect constant interactions and approvals by the stakeholder to ensure alignment throughout the development process. This may happen as often as a few times a day! So, this stage actually runs concurrently with the prior “Prototype-to-MVP” stage.

We’ll briefly touch on each of these steps and provide guidance on performing these as effectively and efficiently as possible.

Step #1 Select and engage stakeholders

One important consideration is selecting both the most effective and also the right number of stakeholders to include in the feedback process. While more feedback is always good, identifying the wrong stakeholders (those who lack the right domain knowledge or perhaps are not empowered to make decisions) can waste a lot of the team’s time. Also, the complexity of reconciling user feedback increases geometrically when there are more “cooks in the kitchen.” So, try to avoid having extended teams of stakeholders to define and approve the scope as this usually leads to a more complicated process and an extended timeline.

Therefore, it’s recommended to minimize the number of stakeholders involved in the MVP. Ideally, you’d nominate a single stakeholder/decision-maker who would represent the user population. This will streamline the decisions and prioritization of scope during both the initial MVP and also during the ongoing feedback prioritization. The stakeholder you select should have a good understanding of the business process and also have sufficient authority to make decisions related to the functionality. Finally, while the stakeholder does not need to be deeply technical, they should have an understanding of technology and its ability to impact the business.

Note that while you may limit the number of official stakeholders, it is highly recommended to include users directly on the no-code development team. This provides a way to properly embed a lot of practical and operational knowledge of the business function into the no-code development itself, ultimately improving quality and increasing the odds of better alignment with the no-code stakeholder.

Steps #2 and 3 Build and review micro use cases

As discussed in the last chapter, building the no-code app can be done highly incrementally as you add new micro use cases into the application. This allows you to “work in” review sessions throughout development. Reviews with your no-code stakeholder to demo the current version of the prototype can be performed on a completed micro use case without a need to wait for either MVP or sprint completion, which is the case for Scrum. As soon as the use case/features are completed to a point that they can be demonstrated, you can start to collect feedback in parallel with continuing development in other areas. Generally, you should plan for feedback sessions at least a few times per week to keep up with the needed pace of no-code development. The feedback session should focus on reviewing the prototype and discussing business requirements for mini use cases.

We also previously discussed the use of the Kanban Method to manage the building of new micro use cases. In addition to helping organize and structure the building process, the Kanban Method also provides benefits for continuous feedback. The Kanban Method is all about promoting transparency, encouraging feedback, and holding regular review meetings, making it ideal for Feedback Loop activities since your stakeholder will have full visibility of the work being reviewed and where it fits within the broader MVP scope.

Step #4 Triage Go-Live scope

The success of the Feedback Loop stage lies in constant collaboration between the no-code team and stakeholders. It’s possible to collect feedback from the user and tweak the current no-code app almost immediately with these capabilities to gain alignment and progress with the development.

That said, as you progress, it’s also essential to stay focused on the MVP and not veer too far off track. Prioritize any new requests for capabilities that arise during the feedback sessions with the same approach you used to define the MVP. If something is critical to the MVP and can be accommodated inline, then it’s best to address it immediately. However, all requirements that have not been included in the MVP should be placed into the post-MVP improvement backlog that will be reviewed and processed in the Incremental Improvement stage.

Step #5 Address feedback

The process of collecting and addressing feedback doesn’t stop at the initial release. You’ll continue to address feedback that you receive from end users in production and follow a similar process for responding to it. This will be discussed more in the Feedback Collection stage (in Chapter 17).

There are many benefits of this continuous feedback loop model — let’s briefly review a few key perks:

• It enables addressing problems more quickly. If you identify missed requirements or incorrect use cases using this approach, the no-code team can focus on resolving issues while development is still underway. This reduces the risk that problems will continue to proliferate and snowball, and you’ll be better positioned to avoid negative downstream effects.

• Improved (re)alignment with the business process. If you’ve done a good job with the earlier Business Use Case stage by documenting the core business vision and success factors, then you’re off to a good start as it relates to alignment with the target state process. However, even with this alignment, it’s still possible to “drift” as the project moves into greater complexity and detail. You may find that you’re not completely addressing the highest priority use cases in the way that was intended. To ensure you’re delivering on the needs and expectations of the business function, you must adapt and realign your understanding of the business priorities and scope as you go, which requires collecting continuous feedback and making course corrections.

• Getting frequent feedback encourages engagement. You want your no-code stakeholder (and the business function more broadly) to be deeply committed to the project. It’s essential they feel a part of the project team, even though they may not be in the development activity itself. Getting frequent feedback from your stakeholder — and genuinely incorporating it into your daily changes — strengthens communication and collaboration in both directions. It also demonstrates how much the no-code team values their input in the project delivery.