Stage 10
Incremental Improvements

It’s tempting to focus on achieving perfection all at once — but that is an unachievable goal. Instead of trying to address all requirements, expectations, and suggestions, it’s better to strive to continuously improve daily based on real-world feedback. This allows you to make progress toward your goal while also continuously learning and adapting along the way. If you’ve done a good job collecting recommendations in the previous stage, you now have a mountain of input from your stakeholders, users, and the application itself (system data). You’ve prioritized it carefully and know the most essential items to tackle first to deliver enhancements to your app.

Consider the example of a young plant growing in a garden. If you only examined the plant every few weeks (or perhaps months), you would notice big differences. It may appear to be an entirely different plant each time you looked at it. You might think the growth was happening in big spurts. However, in reality, the plant grows every day — it’s constantly taking in sunlight and nutrients from the soil and growing in small amounts (usually imperceptible to the eye). It never remains static. The plant is adapting to its environment and constantly growing and expanding in response to its surroundings.

Like a living organism, your no-code app also will be more successful if it takes continual, rapid steps to adapt to the needs of the business function. Using the incremental improvements philosophy can also make it possible to significantly exceed the expectations of your stakeholders because you will be able to respond to their requests continuously and more rapidly.

Step #1 Analyze and decompose use cases

You’ve set the groundwork for this at the Feedback Collection stage. However, as you gather more feedback across various channels, the detail and completeness of feedback become essential — it’s important to analyze it to ensure users are sufficiently documenting their responses and experiences in a way that is clear and reproducible. You’ll want to tie any recommendations or decisions back to very specific and observable feedback and data, not just some general perceptions.

Just as in prior stages, it’s also very important to fully decompose the recommended improvements into micro use cases. It will help minimize the dependencies across work items and allow the micro use cases to be worked on and released independently.

Step #2 Prioritize and approve micro use cases

Prioritization of the feedback is also super important at this step. It’s expected that you have received a lot of input, and it’s vital to organize the right decision-making process based on the value of capabilities. The easiest way to test your prioritization accuracy is to check if the selected micro use cases allow you to achieve the application’s business goals (and ideally specific KPIs you’ve identified during the Business Use Case stage). Also, while you have a backlog of items based on your prioritization from the last phase, it’s important to understand that the user feedback you’re receiving from the live app will likely give you new and perhaps unexpected learnings. So, you must maintain an open perspective on the backlog as you may decide to change priorities.

Finally, in your haste to act on feedback, don’t forget to have the no-code stakeholder authorize key changes before you move any further. Not all feedback is equally important in priority to the business function, so it’s essential to review it with the no-code stakeholder. Just as your no-code stakeholder helped you prioritize the initial MVP release, they also need to help with the prioritization and approval of the ongoing enhancements.

Step #3 Review design considerations

Sometimes changes in the original no-code app design may be necessary after the first MVP is released. That’s OK! Needs may evolve and change. Just make sure you think through the implications those changes may have on the design. This is especially true with more significant changes to the process or data models — those are areas that may have ripple effects across the application.

As the team moves through the process, you may encounter new requirements that can trigger returning to the Options Analysis stage and reviewing assumptions. For example, to satisfy the new requirements, you may need to extend your app with marketplace add-ons or connectors. These should be managed carefully because introducing new options into a production app may result in additional costsor other impacts.

Step #4 Build/test enhancements

After you have prioritized and approved a set of items to address from the backlog, the next step in the incremental improvement cycle is to begin using the no-code tools to build these enhancements. The Kanban Method can continue to be used as a framework for managing work items post-release, as it provides transparency to stakeholders about ongoing progress.

While this step has many similarities to the Prototype-to-MVP stage, here are some additional tips and practices to keep in mind:

• Don’t forget to transfer all items you parked during the Go-Live Phase into a unified backlog with all the requirements, including the new ones. You’ve been managing the scope of MVP carefully up until now, so you have been building a lot of backlog items for the future —don’t lose these requests! It will encourage user engagement (and more feedback) when they see the feedback that they shared during the initial MVP addressed promptly post Go-Live.

• It’s important that new changes — even small ones — do not break existing capabilities within the app. Make sure your software testing approach addresses new features and revalidates end-to-end scenarios that test existing end user features and user journeys already delivered in the no-code app. This is important to prevent unwanted regressions in features or unexpected changes to app behavior.

• Automation of API testing may also be worth considering if there is a risk of the other applications changing unexpectedly. Those changes could result in significant impact and downtime if they occur while your no-code app is in production. While API automation requires effort, this can also be a worthwhile investment to catch and prevent software defects in no-code integrations (especially for integrations that may be used in mission-critical apps or across multiple apps).

Step #5 Review governance checks

New requirements may influence and change the application’s complexity level, which should trigger relevant actions around governance checks as per the Application Matrix. The new requirements shall be analyzed using governance complexity questions. Please note that new governance checklists may need to be applied. For example, the additional functionality for capturing credit card data for a customer case management app may trigger a need to undergo PCI DSS compliance. Make sure you proactively review and assess if the no-code backlog contains items that may result in new external or internal compliance verifications:

• The roles-based access policies for your no-code app will need to be reviewed periodically to ensure they are appropriately enforced and controlled. It’s not uncommon for an app to start with simple user access permissions because the initial MVP functionality may be made available to all users at the start. However, as more specific features are added — especially to address power user requests — it may be decided that some features should be restricted, which may require additional logic and rules to be enforced within the app. As always, you need to be careful with access rights to sensitive data including the ones that might be available for external users outside your organization.

• New security vulnerabilities may be created if you add new integrations with additional systems or expose new user interfaces to new user types (e.g., a self-service portal to new customers or business partners). In general, you should periodically review the backlog of planned enhancements with your security team to proactively identify areas that may require new approvals.

• Data governance checks are still vital to review how sensitive corporate data is managed and secured. As you continue to evolve the no-code app and add new features, it’s not uncommon to begin collecting new types of data, which may trigger new data governance requirements.

There is a balance to strike here. You need to ensure that appropriate quality and governance checks are applied without letting the speed of responsiveness grind to a halt!