Share
PoCs/MVPs and OutSystems, why is it a perfect marriage?
MVPs and PoCs (I will call them MVP just to be shorter from now on) are pretty well-known acronyms in the technology area, and it wouldn't be different when talking about the OutSystems environment.
OutSystems brings those two little concepts to another level by leveraging the speed of this process with no need to leave quality and security aside.
In this article, we are gonna talk a bit more about that and many other topics that make OutSystems, the perfect tool for your prototyping or validation phase.
A good MVP always starts with a good team. The selection of the team is hugely important for this process.
Always choose the most experienced and diverse profiles that you have available. MVPs are the first impression, and I'd even say that is the impression that stays.
Let's talk about what would be, in my opinion, a good recommended team for an MVP development process.
Business Analyst
Business Analyst or a senior developer that can clearly connect with the client to better understand the requirements and forward it in a good and brief way to the development team.
Front End Developer
A Front end developer or a developer that has great JavaScript, HTML, CSS knowledge.
It's known that a big part of the OutSystems community doesn't have deep knowledge of JavaScript, and it's not their fault, in the end, they are OutSystems developers.
But in the case of an MVP, someone that is very experienced in solving front-end challenges might be the breaking point to get the "WOW factor" from a client.
On the left, is a great and customized OutSystems interface. On the right, is a standard OutSystems application. Not bad, but which one would your customers prefer?!
Of course that some MVPs are so simple that they might not encounter any challenges or huge front-end issues to solve. But most of the MVPs that I have joined had many and many challenges that, without someone with deep front-end knowledge, we would be able to succeed.
Use cases like adding something very specific to graphs, usage of JavaScript plugins, integrations using Cordova plugins, transforming a Photoshop prototype into the layout of the application (Pixel Perfect) and many others are the perfect example of why a front-end experience resource is so important for this phase.
Developers
The main workers in the development phase are always the developers. On an MVP, the suggestion would be to keep the team as small as possible to avoid/reduce:
- Communication gaps
- Conflicts on the server because of concurrent publishing
- Time spent on merges
An MVP as the name says is the minimum needed to deliver a good perception of value that can prove that a concept/idea would work. Based on that, an MVP development team shouldn't have a team with more than 2 developers,.
Tech Lead
Last but not least, the tech lead is a very significant piece. This resource will be responsible for enabling the success of the development team, by making sure the complexity gets reduced and taking over the responsibility of the technical challenges or questions.
During the whole process, questions will be raised and those might be questions that have never popped up before, so a mix of experience and leadership can make a good difference between success and failure.
Sales and Management
The sales and management team should be around to make sure they are connecting with the customer somehow, there are always possibilities to generate new opportunities.
In summary, we would have a maximum team of 5 people building the MVP: 1 BA, 1 FE, 2 Devs, and 1 TL.
The business analyst and the front-end would be working on some stages of the building phase and not in all of them, so they are not needed full time in most of the cases unless there are huge amounts of business rules or front-end challenges.
OutSystems
From the technical side of things, OutSystems is probably one of the best solutions out there to help people leverage their ideas into a prototype/MVP/PoC.
Let's take a look at some benefits of building an MVP in the OutSystems platform.
Production Platform
OutSystems Platform isn't(only) for prototyping, but as it delivers a lot of benefits and speed to the process, it can be used to prototype applications and create minimum viable products in a record time.
As the platform aims for delivering production-ready applications, the prototype can easily become a healthy and stable application in the production environment.
So instead of having a tool to build prototypes and another one to build the application, the main benefit here is to have one single tool for both tasks also reducing the effort required during conversions from the prototype to the production version of it.
Accelerators
A huge number of accelerators are present on the daily basis of any OutSystems developers, and many of them can be used to accelerate the building of the MVP, here are some samples of it:
https://success.outsystems.com/Documentation/11/Developing_an_Application/Design_UI/Accelerators
Service Studio Tips and Tricks
Basics Dark theme Would you like to know more?success.outsystems.com
Those are only some examples of little things that the platform can do by itself, or at least remove the complexity of some of those tasks. During a building phase of an MVP every second counts and if we can avoid spending a second on one thing, we can, for sure, spend this second on something more important or complex.
Talking specifically about a PoC, the idea is always to; deliver the most aggregated value to the client with the least effort (time consumed) from the team, meaning that it is a project that should not last for more than one or two weeks of development in the case of a PoC.
In my humble opinion, any PoC that takes more than a week, starts to become just a normal project as it is going to be handled in the same way.
A PoC should be handled in a more agile way. And this means that items that are not that significant, or deliver less value to the client, those items might get postponed till the next phase.
The first draft of a project, MVP, is usually the first impression that your client is going to have about your team. This is the main reason why it shouldn't be handled like a normal development project, and here are a few tips on how differently you should act in front of an MVP development process:
- Make sure you have someone from the client always available to answer any business questions, MVP is a short sprint project, so the longer you take to get answers, the project starts to get riskier.
- As the MVP is the first point of contact with your new client or department, blockers (such as permissions, tunnels, VPNs, and others) might occur more frequently, so communication is the keyword here. Sometimes not only with business but also with other areas, a very common scenario is the need to communicate with the infrastructure team.
- Other than the communication with the client, your internal communication should be also fluid, avoiding long and unnecessary meetings, and making sure the process is running smoothly.
- Even though you have probably selected your best team, make sure you have other profiles available for some help/clarifications if needed, such as UI/UX, JavaScript, .NET, and a few others.
So by combining both agile project methodology and an agile development platform you are making sure your team is as efficient as you can without having to care about the heavy coding as the platform does a lot of daily basis stuff on the developer's behalf.
Give OutSystems a try, and you will probably never get back to traditional programming languages while building your MVPs and making sure they are promotable to production.
Here are a few tips that you should follow while building your OutSystems MVPs:
- Be flexible, the client might ask for something different from what was planned after he sees something more feasible. Sometimes clients don't know what they want, which is fine, our duty as consultants is to guide them through the best solution.
- Put something in front of your client as soon as possible, this can avoid you building up something for days or weeks that is not what the client wants, as per the above statement as well.
- Try to reduce the iteration pace at least for the first couple of features to be built, this will help you in putting something in front of the stakeholders sooner than if you need to complete a full sprint to have a set of features developed.