Before we start

Please note that the article below contains a description of how to improve the process of verifying a project idea and maximize the chance of successful release.

The information provided in this article does not constitute legal advice. All presented content and information are for general informational purposes only. Additionally, the content of contracts or legal provisions largely depends on the countries in which the application operates or stored data.

Introduction

In the current reality, where various markets are saturated with both superior and inferior IT products, it’s important to meet the end-customer’s expectations or solve a specific problem.

There are factors galore involved in reaching this goal, so achieving it may prove difficult. Nonetheless, there are several important steps to consider, starting from the requirements through technical solutions to feedback collected from customers.

How does everything start? 

With an idea, we can move to the next chapter…

I’ve tricked you! Though only slightly, because indeed, the idea is VERY important and should ultimately make the consumer’s life easier.

However, it must be verified, preferably at the earliest possible stage, for three reasons.

First and foremost, it avoids unnecessary costs by verifying a potential idea. Nobody likes to waste money (at least we at Makimo don’t) if it turns out that the idea is misguided, doesn’t solve any problem or requires adjustments to meet the final expectations. The method of such verification depends on the financial resources available, but in my experience, even a low budget allows for guerilla UX and design thinking research, a field study, a simple survey, or a conversation with a potential end-user.

Second, confirming the idea will allow you to define the scope of work, meaning clearly defining the problem to be solved, identifying its strong and weak points, threats and opportunities, as well as  the project stakeholders along with the target audience.

Third, it will be possible to obtain a potential measure of our product’s success, in other words, whether the product will gain approval and eventually generate revenue. 

Defining requirements

Regardless of whether you’re a management person, designer, developer, software architect, or someone completely unrelated to the IT industry, it’s necessary to define requirements, jobs to be done, and user stories. The clearer they are, the better for everyone.

When they are unclear, it can lead to the development of the application in a direction other than intended. Developers may, unintentionally, due to misunderstanding of a particular functionality, design it in their own way or overlook a key rule or limitation.

How, then, can information be clearly communicated between the people with the idea and the development team to avoid the risk described above?

Completed projects have taught me that this step should be differentiated in the context of startups and mature processes or systems.

In the first scenario, I do not believe that there is a one-fits-all solution that would work in every case, as the diversity of such institutions is too great. I would definitely recommend paper-documentation with a description of the idea supported by UML diagrams. The development team would certainly be pleased with such a type of presentation. I emphasize that this method is about substantive communication, not legal protection.

In the second scenario, we have a domain expert on-board, that is a person who is greatly familiarized with the process. In this case, I can venture to say that there is a certain method that will work for the vast majority of cases, and will certainly support the process.

Still, both instances require a thorough understanding of the problem space as well as the business and user perspectives, and sharing the findings using different tools. Most people are visual learners, so colors and concise information work well. Therefore, one could create something like a map with tasks, rules, and conditions that would be relevant to a particular application.

This is where EventStorming comes in, which is “the smartest approach to collaboration beyond silo boundaries,” essentially nothing more than writing down system requirements on sticky notes. I encourage you to familiarize yourself with this technique and to create an “application map,” especially when faced with the task of programming complex business logic where domain knowledge is required.

Once it’s done, there is a need to document findings, and then various maps and diagrams (e.g. empathy map, service blueprint, stakeholder map, user persona), ideally fostering collaboration on the project requirements from day one across the entire product team. There are a few ways of doing this, but most typical IT solutions  are either to create a backlog or prepare a kind of paper documentation.

Creating software 

This is the earliest step enjoyed mostly by everyone, from the investor who begins to realize their goal, to the developers who have a green field and a chance to shine, to the company receiving the money.

This stage is very important. The choice of technical tools, system architecture design, and code writing style have all a huge impact on the future of the project. Poor architecture or convoluted code can lead to developers’ frustration, an increasing number of bugs over time, making changes more difficult, inefficient infrastructure costs, and in the worst-case scenario, even the inability to launch the product.

All of this is important enough to pay VERY careful attention to the selection of software developers and even a long-term partner (Makimo proves to be effective in both cases!).

Automated tests

Automatic tests ensure that no breaking changes have been introduced to the code, without third person work required.

Although it consumes developer time, it’s no-doubt an effort worth spending up there.

Tests significantly improve development work because thanks to them developers have more confidence that their changes did not introduce regressions in the code, and investors see that the work is moving steadily forward.

Gathering feedback constantly during development

It is important to continuously monitor the direction of the project’s development.

Showing the investor or third parties the current state of the project at specific intervals works quite well in order to possibly correct any discrepancies. In most cases, it’s done in a staging environment.

It would be an understatement to not mention SCRUM as a project management methodology in this subsection, but the description of this method goes beyond the scope of this article.

Minimum Viable Product

Great news, as at this stage the potential product is functioning and meets the investor’s expectations. 

This is what’s called a Minimum Viable Product (MVP), which means a version with just enough features to be usable by early customers, who can then provide feedback on their general feelings about the application and therefore also on future product development.

Additionally, if preparations for the project have been carried out properly and a product success metric referred to in paragraph 3 has been established, it will be possible to determine if the product satisfies the end-user.

Proof of Concept

In the realm of product development, Proof of Concept (PoC) might serve as a crucial step before diving into full-scale product development.

PoC always takes place before MVP and its purpose is to either confirm the project assumptions and technical aspects as well as validate design decisions, or present initial results to investors to confront them with expectations. It is extremely important especially in projects that carry a lot of risk, e.g. in the AI field, that needs to be minimized before more time is spent on further development.

It does not always happen, but in some cases might be really helpful for both sides.

Software documentation

Creating documentation depends on the investor’s requirements and the type of project, but it is indisputable that it must be created in order to transfer knowledge to other team members and persist it to increase the bus factor.

At the end of software development, it should be handed over to the code-owner along with all the credentials required to manage the product.

Monitoring and maintenance

In the case of MVP, implementing comprehensive monitoring solutions allows teams to track the application’s health, detect issues in real-time, and respond quickly to any anomalies detected. This proactive approach not only minimizes downtime but also provides valuable insights into the user experience, facilitating continuous improvement. By leveraging detailed metrics and logs, developers can fine-tune the application, enhancing its efficiency and ensuring it consistently meets the needs of its users and stakeholders.

In case of more mature projects, monitoring also plays a crucial role since it ensures that the deployed application meets performance expectations and remains reliable for end-users.

In other words, it’s worth at least considering introducing that in MVP.

A common tool for this purpose is DataDog or Prometheus.

Both of these solutions provide the feature to notify the team in real-time in the event of errors.

A fast reaction to potential issues significantly improves the end-user experience and prevents application discouragement.

Next steps

The next steps depend on funds obtained from investors or earned through MVP.

Nevertheless, it is recommended to go back to the drawing board and engage in the product design cycle to define the next product goals and adjust to feedback from end-customers, because ultimately, they must be satisfied with the final solution.

Conclusion

Starting a new project efficiently consists of a few steps, but with proper attitude and following the steps above, in most cases you should see a successful release where end-users are glad to use the product.

Shortcomings or sloppy execution of any of the steps will have impact on the final product, which can have lesser or greater consequences, ranging from temporary customer dissatisfaction caused by temporary inaccessibility, through difficulties in using the application, to complete lack of interest or unwillingness to use the product.