Stage 5
Prototype-to-MVP

What is included in the no-code feature development? Similar to before — during the prototyping phase — it will typically focus on these key areas:

UX/UI

The basic UX will have been established by the prototype but will now be extended by adding individual features/micro use cases. This will add more depth and completeness (by adding forms or screens needed to complete a full process) and desired usability enhancements (e.g., streamlining the user flow throughout the application by combining steps or automating the population of fields). It will also add additional business rules and validation logic needed for the MVP. Finally, the UX will also likely undergo some form of brand/UX review and may require updates to ensure consistency with overall corporate standards. Also, during the earlier prototype stage, we mentioned that data models should not be in focus. However, at this stage, it’s time to establish the right data structure and the necessary dependencies between the objects.

Workflows and business logic

You will extend the business processes (both human and system processes) that were defined in your prototype by adding more detail around subprocesses and tasks. This will also typically introduce more nuances around “edge” conditions and process variations that might be suggested by different departments or business units. Error conditions must also be anticipated to handle cases where there are failures or process exceptions. Allow these to be handled gracefully.

Integrations

During prototyping, the internal systems that needed to be integrated with the no-code app are often “stubbed” for simplicity but, in this phase, the actual integrations will be introduced. If data is accessible in systems with preexisting connectors or modern APIs, this may be simply a no-code configuration. Often, however, this may require some participation by software engineers as part of either a fusion team or perhaps sourced through a Center of Excellence.

Dashboards and analytics

At this point, you need to extend the dashboards and reports you’ve built in the prototype so that they include real data and cover key aspects that are needed to analyze the performance of the business use case. Keep your focus on adding key dashboards with defined success criteria to the MVP as this helps streamline the adoption of the app, specifically by the leadership team.

Keep in mind that while the no-code tools will be used to define the core of the no-code application, they may be integrated with other components of the solution that you identified during the Options Analysis stage (e.g., with either packaged application functionality or with custom-developed components). This will introduce the need to use other development tools as part of a fusion team approach. However, always remember that the goal is to utilize no-code capabilities wherever it’s possible. Professional software development tools should be used only in cases when no-code development cannot be applied.

Kanban progress tracking

The ability to break down larger functionality into a stream of small features/micro use cases is powerful but, to be successful, it requires a deliberate approach to manage the flow of work effectively. We recommend a Kanban approach, which we believe is optimally suited for no-code development. Kanban is one of the common flavors of modern Agile software development, but its origins trace back to advances in lean manufacturing pioneered by Toyota in the late 1940s. It is a “just-in-time” approach to managing complex workflows. There are a lot of primers on Kanban available for review. We don’t want to spend time duplicating these guides, but we do want to make sure you understand one of Kanban’s core practices: The use of visual boards that breakdown work into a set of “cards” and “columns” (e.g., requested, in-progress, done). This is a highly visual approach to managing and tracking work items that allows the development team to pull work from a defined backlog (to-do list) and easily track and communicate updates. Kanban also provides both the development team and key business stakeholders with visibility into the scope and progress at any time, which facilitates collaboration and discussion about priorities.

Many software development teams may be familiar with Scrum (a type of Agile methodology). However, we recommend Kanban over Scrum for no-code development for the following reasons:

• Kanban builds a continuous “push” delivery model where teams release value as soon as they are ready, while Scrum organizes work in Sprints and defined Release Trains.

• Kanban also offers the flexibility to use the method on top of existing workflows, systems, and processes without disrupting what is already in place. Scrum can require adopting a nontrivial number of new systems and processes, which can be overwhelming for a business-led no-code development.

• Finally, Kanban minimizes the need for practical experience and specialist roles (e.g., Scrum master, product owner), which also makes it easier and faster to adopt by business teams.

Software development cycles (If needed for a fusion team model)

We keep emphasizing that you should be focusing on using no-code tools to fully exploit the power of the platform. Using no-code tools wherever possible drives greater productivity and lowers the total cost of support and maintenance. You’ll want to revert to custom development only when you have specific needs that call for the fusion team model. Don’t forget, the Application Matrix will have identified your appropriate delivery mode type. You may have included software engineers on your team (as part of a fusion team delivery model) or you may seek software engineer support from a No-code CoE. Depending on the size of the custom software components, this may dictate some of the processes that the software engineers may follow. For small development scenarios, it may be easiest to simply have them join the cadence of the no-code team and use the Kanban Method outlined earlier. For larger software development projects, the software engineers may identify the need to follow other traditional software development methods, such as Scrum, to manage their work before it gets integrated into the no-code app.

Scope and change management

As you further build MVP features, it’s common to continue to elaborate on lower levels of depth of use cases and identify additional requirements (based upon the feedback techniques that we’ll discuss in the next chapter). However, while it’s good to be responsive and agile, you must also be disciplined throughout this process of managing scope and applying change management practices. Clearly identify and track new feature requests as they are identified and maintain a focus on deciding whether they are in for the MVP.

Here are suggested criteria for deciding which features should be included in the MVP:

• Timeline. In the prior stage, you have established the timeline for the MVP and allocated resources accordingly. It’s recommended to adopt a timeboxed approach for hitting this date. As you identify and elaborate scope items that could possibly exceed an expected MVP timeframe, the no-code team should reprioritize the defined scope and target fewer features and shorter time-to-market.

• Business value. The end users should be able to start using the MVP capabilities and receive the expected business value as outlined by the business use case. Any newly identified features that are not critical to supporting these business outcomes should be deferred to the backlog for future consideration.

• Crystal clarity of the use case. The ability to execute is important, and the MVP should include only those capabilities that are fully aligned, clarified, and don’t require additional research and approval. Vague and not fully confirmed requirements should be taken out of scope and deferred to the backlog until they are clarified or matured.

The most important criterion in the no-code development process is “aggressive” decision-making and prioritization processes during the MVP scope. If wrong decisions are made or incorrect prioritization is allowed, the MVP release timeline could possibly be extended to months, dramatically increasing opportunity cost. When you are working on the scope, it’s critical to focus on the capabilities that can be released within days or weeks to deliver value to the business. So, while analyzing each feature, the no-code team should be asking themselves the following question: Can the business get value without it?

If the answer is “yes,” then consider it out of the scope for the MVP release and move it into the backlog for later consideration. The team should also focus first on features that are easy to implement relative to the business value they provide. Prioritize features that are low-cost to implement and provide high business value.