How is the development of a project different to the development of a product? In both cases, we’re trying to develop a software application, right? So shouldn’t it be the same?
As this thoughtful article by ThoughtWorks reviews, projects and products are anything but similar, yet the experiences gained by working on one can help you understand what to change when it comes to working in the other.
Now, I wouldn’t call myself an expert in product or project development, but even with limited experience it’s easy to understand that even the most basic requirements, like customer profile and pricing, should be necessarily different. In this post, I’d like to cover the differences between a project and a product and how we can adapt our mindsets to ensure our success.
Lets start with the projects.
Where to focus for PROJECT development
The first factor that typifies project development is the fact that you’re making customer-specific software. It needs to solve the demands of this one customer within the agreed time, budget and quality. Time and budget are especially important, because there won’t be a second chance to charge for the work done: after we complete this project, ideally we’ll start to work on a different project for a different customer. In most of cases, there will be no further changes on the source code (except for bug fixes) and we won’t be able to use it for any other project.
This gives us an opportunity to consider what does this means for:
- the requirement analysis process
- the importance of code quality
- the way we select technologies
- the required adaptability of the system
- the pricing of the software
|Customer variability||Low (only 1 customer)|
|Long-term strategic focus||Low|
|Price per customer||High|
Requirement Analysis Process
If we do the requirements analysis for a project, we have to collect and understand the requirements of a single customer, not a larger market of consumers. Therefore, we use our domain knowledge to talk with the stakeholders and key users. These discussions are the most important part of the requirements analysis process, and pre-existing domain knowledge is very useful to speed up the analysis process.
Poor code quality increases the risk of bugs and the amount of time required for every change. Code quality is important when we need to support and extend the source code for a longer period of time. This means it is not a top priority during project development because we have a short term focused strategy for it. The main priorities are to fulfill the requirements and deliver the project on time.
But what about change requests in the future? This is the main reason why we should not ignore code quality completely. Otherwise we will need too much time to fix bugs or implement new features. But we don’t know for sure if there will be any changes, which should be considered a new project with a new budget. So we need to be careful about how much time we spend to improve the quality of our code. It might be useful to do some extra work to improve it but it often adds little value. Our main focus remains on completing the project within time, budget and quality.
The freedom and flexibility of technology choices depends a lot on the type of project we are working on. If we are working on a completely new project (a.k.a. green field project), we are often free to choose any technology that fits the requirements. Since there is no legacy code that we need to take care of, every project provides the chance to choose a new technology stack for it.
That sounds great, but there are also some drawbacks. Most customers will not pay us to evaluate multiple technologies: they hired us because we are experts in this specific field. So we need to already know the selected technologies or we need to take the risk that the project will suffer because of bad technology decisions.
No pressure, just make your first try perfect ;-)
Now, the work on brown-field projects is different and more similar to legacy code product-related work. There we have existing systems that need to be extended or integrated. This limits the freedom and flexibility of the technology choices. We either have to choose something that enables us to integrate into the existing system, or we have to stick with the old technology decisions.
We do not need to think much about adaptability if we are working on a project. Most of the time there is no need to define a plugin mechanism or create an extensive amount of configuration parameters. Our software just needs to fulfill the requirements of one customer. So keep it as simple as possible. This saves time and avoids unnecessary complexity and risks.
Since we sell the project only once, we need to make sure that the price is higher than the sum of all our costs. This makes the development of specific software quite expensive.
Where to focus for PRODUCT development
Typical software products are more or less standard applications that are used by multiple customers, e.g. Eclipse IDE or Microsoft Office. They need to solve the demands of multiple customers and we need them to adapt to specific customer requirements, both now and in the future. If the product is successful, we’ll have to work with the existing source code for the foreseeable future.
Again, we’ll need to analyze the following factors for product development:
- the requirement analysis process
the importance of code quality
the way we select technologies
the required adaptability of the system
the pricing of the software
|Customer variability||High (many customers)|
|Long-term strategic focus||High|
|Price per customer||Low|
Requirement Analysis Process
The requirement analysis process of developing a product provides complex challenges for us. At first, we need to understand the requirements of a target group of customers. As a second step, we have to identify which requirements can be the same for all customers and which need to be different. The common requirements describe the required features of the product, and the different ones show us where the application needs to be customizable. The analysis process takes more time and requires a lot of experience and well-rounded domain knowledge.
In general, there are two different ways to gain the necessary domain knowledge and to identify the requirements:
Option 1: Implement multiple projects first and collect the product requirements based on these projects as a secondary step. The success of this approach depends heavily on the number of projects. The more projects we have worked on, the better is our knowledge about the domain and the customer requirements.
Option 2: Start from scratch and try to collect the requirements without any project experience in that specific domain. We can do this by analysing competitors and by doing a requirements analysis with a very small number of key users. This is far more risky than the other approach, because we most likely won’t have a broad enough sample of customers to get a good overview about the requirements for the whole customer group.
As we have seen, the requirement analysis process is quite complex and it is crucial for the success of our product. Therefore we need to take the time and make sure that we have enough domain knowledge to identify the most important customer requirements.
It is often useful to start with an early version of the product and extend it based on customer feedback.
As said before, the importance of code quality depends much on how long we need to support the code base and on how often we need to extend or adapt the application. This connection is what makes the code quality very important for products while less important for projects. A product needs to be maintained for years and we’ll probably want to change it over time to keep up with the competition. If we do not take care of code quality from the beginning, developer wisdoms states that we’ll pay for it with every change in future.
RebelLabs has an overview of several tools for static code analysis that help us to maintain a good quality. We just need to use them.
Product development has one huge drawback when it comes to technology choices: we have to stick with them for a long time.
We should be really careful to make the right decisions and choose technologies that we can use to fulfil our current and potential future requirements. Every choice you make, whether in development style or technology choice, creates legacy code that we’ll need to support and fit to our technology choices in the future. Often, replacing an old technology is so costly (time, money, etc.) that it’s nearly impossible to convince management to do it.
So take care when it comes to evaluating technologies and choose something that you’re going to like to keep for a long time. Easier said than done, but use your gut feeling.
Adaptability is very important for our product because it needs to be able to adapt to the requirements of many different users. This can be achieved by making parts of the logic configurable or by implementing a plugin mechanism. A good example for this is the Eclipse IDE and it’s plugin marketplace. It is used by lots of different developers and each one has their own custom configuration and set of plugins for adapting the IDE to their specific needs.
The problem is that both options increase the complexity of the system and require an additional amount of time to implement and test. This is a critical factor needed to ensure the long-term success of our product. So we need to make sure that we identify the required configuration and customization options during the requirement analysis and invest the additional time to implement them.
In general, we can calculate the price of our product based on the value that it provides to the customer and the amount they are willing to pay for it. This price is often much lower than our development costs, but because the software should be sold many millions of times (right?), this isn’t much of a problem since we don’t have to find one customer to pay for it all.
A good example for this is Microsoft Office. The costs for development and support of Microsoft Office are much higher than the amount that each customer pays for it. But it is sold often enough to create profit. Below, I’ve outlined the comparative priority levels for different factors involved in product development.
|Customer variability||Low (only 1 customer)||High (many customers)|
|Long-term strategic focus||Low||High|
|Price per customer||High||Low|
As we have seen, it’s probably not a good idea to approach a project and product in the same way. The goals for them are often completely different, and this requires different processes and decisions. To ensure the success of the project or product, we need to make sure that everyone involved in the creation process is aware of these differences.
For project development, you focus on one customer and, in general, orient things towards the short term. This results in a higher price for the customer and higher time pressure for the development team. But there are some things that lower the risks and costs of the development, such as a simpler requirements analysis process and less attention needed on code quality and adaptability. The selection of technologies to use is also easier to remain flexible, but you need to decide in a shorter period of time.
For product development, you target multiple customers and need to maintain a long-term focus. This means that decisions made by management and the development team need to fit to the long-term goals and take into account the requirements of millions of demanding customers. This results in a more complex requirements analysis process and puts a focus on good code quality and adaptability. Choosing technologies is also more complex because they have to fit the long-term strategy and also fit with the existing legacy code.
I hope you enjoyed my first article here on RebelLabs, and I look forward to your comments below or via Twitter at @thjanssen123.