Katherine Kostereva
More posts from Katherine Kostereva
The age-old adage of “doing more with less” is particularly critical advice for both startups and enterprises right now.
Venture funding has hit its lowest point in two years, which means startups must now focus on making hard decisions about how to utilize their limited budgets. Enterprises are likewise tightening their belts as customers feel the impact of inflation and prepare for an uncertain economy. What’s more, we are facing a global talent shortage that further puts pressure on an already constrained software developer pool.
No-code development tools could not have come at a better time. By democratizing the ability to develop software through visual, drag-and-drop tools, no-code enables a range of non-developers to start building software.
For a startup, this might mean the founder now can build their first minimum viable product (MVP) release themselves while bootstrapping the team. For enterprises, teams can build their own apps without having to depend upon the IT department.
How does one go about evolving a prototype into an MVP using no-code? Here are four practical steps you can take:
Embrace an everyday delivery approach
Traditional Agile methodologies for custom development have popularized breaking down larger releases into smaller releases that add features.
Depending on the flavor of Agile employed, how long each release will take to be ready will vary. The Scrum version of Agile typically defines shorter “sprints” of two to three weeks. However, not all builds developed in these sprints may be ready for release to end users, who will have to wait until the next full release is complete.
No-code is different: It enables delivery of features with small, quick, continual updates — what we will refer to as “everyday delivery.” This builds on concepts from Agile but does not force you into a strictly defined release duration. Instead, with no-code you can rapidly and continuously add features to the prototype and evolve it toward your MVP and release features when they are ready via smaller, incremental updates (perhaps daily).
One way to do this is through the Kanban Method, which is optimally suited for no-code development. Kanban embraces a continuous “push” delivery model, where teams release features as soon as they are ready, compared to Scrum, which organizes work in sprints and defined release trains.
When used together, Kanban and no-code let you update the prototype and release updates faster and more often, gather feedback from your stakeholders and end users, and respond quicker. Kanban can also be easier for non-developers to adopt — they can use it on top of existing workflows, systems and processes without disrupting what is already in place. Finally, Kanban also minimizes the need for development experience and specialist roles (e.g., Scrum master or product owner), which makes it easier and faster to adopt for non-developers.
Proper scoping and decomposition
The next step is to properly scope and decompose work items in your MVP release.
Ideally, the MVP release should be focused on as narrow a scope as possible — resist the temptation to finish everything in the prototype and try to completely deliver all the promised features in this initial release. It’s important to get the first release to users quickly and begin learning how they use the product and validate its value.
Think about the typical sales process employed in a large company. This is likely too broad a process scope for an MVP. So instead, take inventory of possible sales processes defined in the prototype and further decompose them as much as possible into smaller subprocesses such as lead management, opportunity management, enterprise sales forecasting, enterprise sales workflow, territory management, sales collaboration and performance management. This will help you triage and the prioritize scope of your MVP.
Decomposing processes to focus on a single subprocess, say territory management, will also help with overall management using the Kanban method, as you will have finer control and visibility over the work as it flows through the team. This also gives you more flexibility in choosing when to release.
Granular updates also let you push releases frequently and continuously to users and stakeholders for validation and are typically easier to consume by users as they lower the impact of changes.
Carefully manage and decouple dependencies
A closely related step is ensuring that you minimize the dependencies between work items.
It’s hard to maintain the high velocity of the everyday delivery approach if the scope of your features is broad and has dependencies on other features. It’s essential to decompose larger feature requests into the smallest use case possible to help reduce dependencies and increase flexibility so you can quickly and incrementally release new features and make changes.
If you are not the only one who develops the application, you should also consider dependencies on other components or features being developed by others. For example, if your territory management feature is ready for delivery but is coupled with other features in the overall sales process that are not done yet, the team must find a way to separate incomplete features so they can be delivered and focus on deploying what’s ready.
Decomposing each update into smaller and more loosely coupled use cases helps with conflict management — smaller and more frequent updates will also reduce conflicts across teams.
Invest in continuous deployment automation
The final step is to invest in automation.
Most no-code platforms build on continuous deployment approaches as part of their automation to let you move no-code applications through environments more quickly. When an operator wants to move an app to production, they will usually need nothing more than approval and a click of a button.
This lets you move no-code features quickly and seamlessly across environments and on demand.
One often overlooked example of deployment automation is the ability to do fast rollbacks if a change is not working as expected. Rollbacks can typically be addressed either by the deployment automation in the no-code platform (if it can undo or reverse deployments) or through a dedicated staging environment (mirroring the last production environment before a change was released).
This increases confidence to move quickly with the everyday delivery approach, as you know you can always return to an earlier configuration, if needed.
In conclusion
The American author, humorist and entrepreneur Mark Twain famously once said: “Continuous improvement is better than delayed perfection.”
In moving from prototype to MVP, it’s often tempting to focus on achieving perfection — but that is an unachievable goal. Instead of getting caught up trying to design the perfect and complete MVP release all at once, try to deliver value as quickly as possible and continuously improve your prototype based upon the user and real-world feedback.
Comment