The topic of the Project vs Product mindset has been a long-standing discussion. However, given that many organisations are still trapped in the project driven delivery, one could argue that it has not received the attention it deserves. While embracing a product mindset involves a range of considerations, spanning cultural shifts, team structures, budgeting, roles, skills, technologies and tech practices, this blog will focus primarily on the tech bits and pieces to consider when transitioning from a project-oriented to a product-oriented mindset.
Product mindset and DevOps very well complement each other, therefore it is no wonder that one follows the other whenever people talk about modern day software delivery. If we include the Agile style delivery to the equation, we might then be sufficiently equipped to make a conscious move to the product style from the project style. Therefore, this blog will discuss the technical aspects of the product mindset, alongside the DevOps and Agile practices wherever applicable.
Project vs Product
A project has a fixed scope and usually an approved budget. It has boundaries, and a number of written documents and processes to keep the project team within these boundaries. Project has a starting date and an end date, consequently making the project team have the same starting and end dates. Projects are essentially temporary, very well-defined work.
“Overall, a project is a well-planned endeavour that follows a lifecycle with a definite beginning and end.”
Project Management Institute (PMI)
On the other hand, a product is something that has an identity which keeps evolving, serves a purpose in a business (e.g., being sold to an end user or offering a service to some party) and requires maintenance and continuous attention. This implicitly indicates that a product has a lifetime which ends when it is no longer useful for the business. In the case of IT, a product team will have the same lifetime of a product (usually longer than a project lifetime). A product also requires very specific team culture, way of working and technology aspects to maintain its ‘Product Nature’.
When to Make the Transition
Organisations that deliver software solutions following the project approach prefer short lived teams which can be re-assigned to the next project as soon as the current one ends. However, their anticipation of fixed project requirements and predictable issues within the project lifetime often does not align with reality. This can result in change requests that might impact the scope and the budget, or necessitate the addition of follow-up phases to the project to accommodate the changes. These activities may require further budget approvals and other administrative processes, which can considerably slow down the progress of the final software solution.
Furthermore, a project based solution delivery can cause major issues when it comes to the incident handling in a production environment, as the project team may not be readily available to participate in that process. These are some of the indicators to know that an organisation should consider transitioning from a project approach to product based delivery.
A Software Product
Going by the definition above, any given software product has an identity that distinguishes it from the other software products. This identity also evolves, typically through the addition of new feature upgrades. A software product serves a purpose in the business, such as enabling customers to put an online order of a book (Order app) or facilitating identity management internally within the organisation’s tech stack (IdM service). In addition, such a product requires continuous attention and monitoring to make sure that it is operational, as well as an incident management process to involve the product team to resolve any production issues.
Technical Considerations for the Product Mindset
Moving from a project-oriented working style to a product-oriented one requires changes in various aspects. Since this blog focuses specifically on the technical considerations in this transformation, let’s explore the following list of points. This list is by no means exhaustive but highlights some of the most practical and important things to consider.
Know Your Product
It is imperative for a product team to understand what defines the product from a technical perspective, as the team will maintain it throughout the product life cycle.
Repositories: This is where the software codes/configurations reside. The team will act as the custodians of their product repositories, and they will decide who gets access to these repositories. The team can choose between a mono-repo or multi-repo style of repository structure; however, these decisions should consider the possibility of alterations in the product scope, breakdown of the products in the future and possible changes to team custodianship of product components.
Software Build Artefacts: Here, software encompasses the entire application stack, spanning from the frontend to the backend and further into the infrastructure. The software build artefacts are the distribution packages generated, typically through the build pipelines. A software product’s evolution must be tracked through a proper build artefact versioning method (e.g., Semantic versioning). Those artefacts should also be pushed to and managed by a chosen artefact management tool.
Documentation: Product documents are a crucial part of the product and should be stored alongside the software code. For instance, the technical documentation of an application can be written down and continuously maintained in the README.md files. Furthermore, the documentation should be included in the acceptance criteria in the applicable user stories for the developers (e.g., in a SCRUM/Kanban setting)
Decide Your Product’s Architecture
Product architecture is a critical factor for a software product as it sets the technical boundaries for the team. This is why a massive monolithic architecture for a software product poses numerous challenges for the product mindset. A large monolithic software will have to be managed by multiple product teams, and the process is likely to result in troublesome circumstances, such as one team waiting for the other to proceed, or one team unknowingly impacting the other team’s work.
Microservices: Microservices have been widely praised for many years, making them a good solution to address the team boundary problem in monolithic architecture.
Microfrontend: This is equivalent to microservices, but in the frontend domain. A microfrontend implemented with a BFF (Backend for Frontend) will set a clear boundary for a front-facing application, allowing the APIs to be generic if required.
BFF: As mentioned above, BFF will decouple the tight relationship between the frontend components and the APIs. This will help the APIs to be more generic and also allow convenient use of external APIs belonging to other products.
Event Driven: When the triggers of your software components are events, it helps to decouple them with the event sources, which might be different software products. Once again, this architecture style sets clear boundaries between your product and the others.
Keep Your Product Alive
The requirement of a proper monitoring and alerting mechanism for a software is an obvious one, regardless of whether the software is built as a product or a project. However, when transitioning into the product mindset, it is important to understand the role the product team’s engineers play in this aspect.
Traditionally in the project oriented style, once the project is completed, it is handed over to a different team (operations/BAU team), which then takes primary responsibility for managing incidents. In the practical world, most of these incidents are triaged back to the same engineers who worked on the project or sometimes to others who have to learn the product behaviour from the start.
However in the product style, as the team is the custodian of the product, they should be actively involved in the support process. Ideally, this means the product team should have the correct access levels to investigate and address the production incidents captured through the alerting mechanism, as well as the ability to continuously monitor the operational metrics of the product.
Keep Your Product Healthy
As mentioned above, in contrast to a project that has a handover stage at the end, a software product will typically be maintained by the same team which developed it. This is one of the reasons why DevOps and the product mindset complement each other well.
DevOps infinity loop – jfrog.com
As shown in the DevOps infinity loop figure above, a software lifecycle doesn’t necessarily have a defined end date. In addition, the product team is expected to be actively involved throughout this product lifecycle which can be technically depicted as the DevOps infinity loop. This demands a key requirement of keeping the product healthy in order to maintain it with the least amount of issues.
A software product can be built with widely accepted non-functional requirements in place to keep it healthy in the long run. Some of these include having proper automated test coverage, linting, security scanning of code/modules/build artefacts etc, proper logging, good code readability etc.
Think About Your Product's Future
Another important aspect when developing a software product is to plan the product’s future. This will be quite different to the project style deliverables, as they have a defined and approved budget and a scope. Therefore in a project, any considerations for what the future holds for the software may be considered as out of scope and will be addressed when the requirements appear at a future date.
In contrast, a software product should have the ability to accommodate at least some level of non-functional and operational requirements that may not be present at the current time. While there can be many of these based on the product, some examples can be stated as:
- The ability to be reused without duplication
- Be elastic enough to accommodate varying traffic and computational requirements (e.g., cloud based product)
- Having generic APIs which can facilitate the future consumers
Upgrade Your Skills
Product teams are, by and large, cross functional teams that include people from different subject areas working towards the product. However, since this blog focuses on the technical aspects of the product mindset, it will mostly discuss the technical experts in a product team.
Traditionally, a software developer’s expertise is in a focused domain, which might be one of backend, frontend, infrastructure, etc, (I-Shaped skills). However, for a long-running product team, it is important to invest more on full-stack or T-Shaped skills, where the developers may have one focused area with the general and functional expertise on the others. This enables the product to be developed in vertical slices in an incremental fashion, consequently supporting the testing and feature release process. Therefore, it is important to build the product team with T-Shaped developers, either through new recruits or upskilling opportunities.
Conclusion
This blog explored the technical dimensions of transitioning from a project-oriented mindset to a product-oriented one in software development. While broader organisational and cultural shifts are pivotal, this exploration serves as a fundamental guide for the technical aspects. Implementing a product mindset, although not without its challenges, holds the promise of improving software delivery to meet the ever-evolving demands of today’s business landscape. By embracing this shift, both in terms of technical practices and cultural transformation, organisations can better position themselves for long-term success in the dynamic world of software development.
