• Tomasz Soroka

The 10 significant challenges you may face when you develop a software product.


Developing a technological product is a challenge that requires a lot of work and knowledge, thanks to which you have control over our areas that have a direct impact on your success. Below I present challenges that very often arise during the development of technological products.

Challenge 1 - Vision, mission and strategy is not known or clear for a product development team

Defining the vision and mission is the starting point - no matter who is the end-user of your product. The basis is a vision - where you want the created product to be in a specific time. Mission - why your product exists ?. Simon Sinek described this issue wonderfully in the book "Start with Why".

I know from experience in the development of various products that the perception and perspective of working on a product change significantly when the product development team understands what you want to achieve and why they are building the product.

I recommend that you always think about the mission and vision at the very beginning and start conceptual work with them, and if you create a product and do not specify its vision and mission, then do it as soon as possible.

Challenge 2 - Goals which not clear for your development team

The lack of defined business goals for a product team often means that it does not work optimally. Usually, the focus is on creating next features without additional verification of the business value they bring. 

One of the good practices is to combine business goals with the goals of the product development team. I recommend you to use the OKR method, which Marty Cagan described excellently in the context of product development in the book Inspired.

Challenge 3 - Bad development methodology

The methodology you use to develop the product should help your development team to bring the most possible value to the product.  

In my experience, the SCRUM methodology works excellent, but only when you use it correctly. To make it happen, the SCRUM team must focus on supporting business goals.

I will not mention that the team needs also follow the SCRUM guide and good practices, which is a separate topic.

The already mentioned OKR methodology - Objectives and key results can help a lot. OKR was proposed by Andy Grove named "Father of OKRs", and Google is the best-known company for its use thanks to the initiative of John Doerr.

To understand Google's significant impact on OKRs, let's quote Larry Page's Wikipedia

"OKRs have helped lead us to 10x growth, many times over. They've helped make our crazily bold mission of 'organizing the world's information' perhaps even achievable. They've kept me and the rest of the company on time and on track when it mattered the most. "

For example: To the sprint backlog during planning, the scrum team should add those elements that currently provide the most significant business value. If the team works in this way and combines the delivered value with business goals and their measures, it is highly probable that the effects achieved during the sprint will directly affect the achievement of the objectives.

Challenge 4 - Team without required skills

It's a big challenge when you develop technology products. It usually manifests itself in poor product quality, not following good industry practices - which the team is not aware of. It often happens that the lack of competences will be revealed unexpectedly and result from the emerging new business requirements that force the addition of additional competencies to the team. Unfortunately, the team is not aware of this.

For example: We have a working product that users use intensively. In a very short time, the number of users increases a lot, and it turns out that the product architecture is designed in a way that it is impossible to serve such a big number of users. The team was informed before that it will happen, but they did not know how to prepare.

There are many solutions to the problem. One of them is the audit of the product development process by specialists who have experience in developing technological products.

I highly recommend that a person with extensive experience and a different point of view look at the product development process periodically.

Challenge 5 - Technical debt

Technical debt in software development in simple words means that the current software solution is not optimal. It means that after some refactoring team can save much time (money) during product development. 

In software development, we have the concept of code refactoring, which means rewriting part of the application to meet new business requirements to make the product better. 

Many people say that code refactoring is something bad, and that is a result of a lack of competence in the development team. Sometimes this is true - especially if the development team is not sufficiently competent. Even if your team has enough experience, then refactoring will be needed at some point. It results from the fact that product requirements are continually changing and evolving. Technologies and user needs are also changing. Currently, a highly recommended practice is continuous code refactoring, so that the technical debt is as low as possible.

Challenge 6 - No continuous integration

It would seem that continuous integration in 2020 is the standard when people are developing technology products. As it often turns out, not only is it not a standard, but many people do not know how much it can improve work.

Continuous integration means that from the moment the new version of the code is uploaded to the repository, the latest version of the application is built entirely automatically. Along the way, the building system is performing many operations such as automated tests, code verification, and many others. Savings for even small small products are counted in tens of hours per month.

Additionally, problems with code patches or regression errors are detected more quickly.

I recommend that you check whether your team uses continuous integration tools in your project.

Challenge 7 - Lack of automated tests

Software testing is a vast topic. Strategies and techniques should primarily be adapted to the expected quality. Quality is defined differently depending on the phase in which your product is. You should define other requirements for quality when you are in the MVP stage, and completely different if your team is developing a product that is used by thousands of users every minute.

We divide testing into automatic and manual. Manual testing is based on the fact that a person tests the application - usually QA engineer, which, depending on the type of testing, performs various kinds of operations on the app.

Automatic testing is based on the fact that tests are written in the form of code similar to the application code. Then are executed without the interference of the tester. If your product development team does not use automated testing, this will likely hurt product quality and delivery speed for subsequent versions. You should check it.

Challenge 8 - No metrics

The metrics contained in the product, which you can easily track, are the primary thing that your product should have.

You should add them to the product from the very beginning. It is essential to define the

goals, conversions that we want to measure - then we will know where the metrics should be and what we will get from them.

It would help if you combined metrics with the business goals that crucial for the product development team. If they are missing or you don't track them, it means that it is a lot to improve. 

You should remember that thanks to the right metrics, it's always easier to achieve goals or make pivots faster. 

Challenge 9 - No proper documentation

Proper product documentation is a kind of insurance policy for you. Ask yourself - what would happen if your development team would disappear today?

Do you have everything you need for another team to take over product development efficiently? If your team doesn't maintain proper documentation, it's worth looking at it.

Documentation doesn't mean describing every button screen and business logic on hundreds of Word pages. It does not make sense, and very quickly, this type of documentation becomes useless. Nowadays, the trend and good practice are to reach a stage where the code is also in the parallel product documentation. However, not everything can be documented in this way.

Therefore, it is worth maintaining documentation that allows comprehensive testing of the product or quick implementation of a new person into the team. Unit-testing or acceptance testing should also be part of the documentation. It is worth looking at, for example, BDD methodology.

Challenge 10 - Dividing support and maintenance from development

It often happens that the team that developed the first version of the product does not participate in its further maintenance. In this approach, we lose a precious thing - experience and product knowledge that the development team has developed.

It is good practice to manage product development over time so that the same team works on development and maintenance. Based on the actual amount of work, you can add additional people to your team, but the core of the team should be not changed over time.

The team should divide their work between new features and current support based on the current situation and priorities - as usual, combined with the biggest business value that the team provides. The ideal situation is the so-called continuous delivery - when every few days, we deliver a new version of the product, in which we simultaneously correct errors and provide new functionalities.


I hope that the article has provided you with tips on what to look for so that your product development runs optimally. If you have any questions regarding the development of your product, please contact me and look at product development solutions we offer in Leaware.

Need help with your IT project? Book free consultation with Tom: