On Product Development Artifacts and Team Collaboration

In this article, I would like to share my observations about the challenges that development teams face today, as well as present developments based on my personal experience in managing high-tech projects and products in the oil and gas sector.

Why is this relevant? In the world of technology, we are in a situation of constantly changing needs and active competition. The success of our decisions and the effectiveness of interactions with each other directly affect our future. It is believed that in the future there will be two professions: those who monitor computers and those who are monitored by computers. Let's discuss how to adapt to these changes and stay one step ahead.

Disclaimer

Naturally, there is no universal solution, but I will try to follow the method of “progressive JPEG”. This is an approach in which the details may be blurred, but the general understanding is formed. Functionally, what is presented below helped the author and was tested in practice. Depending on the tasks, personal preferences and work style, some theses may seem controversial or intersect with existing methodologies. However, if the reader finds something useful, then my goal has been achieved.

Preamble

In 2016, the author took a management position and, while preparing for this step, came across a report by German Gref on the transformation of Sberbank into Agile. This material struck a chord with me: in 2011, in Peterhof, I encountered an electronic queue for the first time, which impressed me – there was no need to ask who was last. It is logical to assume that such a service was the result of a project and was packaged into a corresponding product. It is useful to distinguish between the terms “project” and “product” to understand what we are actually managing – this will be the first part of the article.

Since 2016, the author has gained experience managing projects and product teams in the oil and gas industry under a single leadership. If anyone has worked in a culture where project and product teams are separated, I'd be happy to hear your thoughts in the comments. By the way, according to ChatGPT, Alfa-Bank was the first Russian bank to implement electronic queues in 2008.

What are we working on?

Let's get down to specifics. Let's look at development from a project perspective. The diagram below may seem trivial to managers, but it is useful for developers. A project is an activity with a clear beginning and end, always with a customer. It goes through three stages: initiation, execution, and completion. At the initiation stage, iterations are conducted with the customer, the technical task and the calendar plan are formed. After the contracts are included in the thematic plan and project teams are formed, the execution stage begins under the guidance of project managers.

Project deliverables typically include intellectual property such as programs, code, calculations, methods and other artifacts, as well as technical and accounting reports. In classical project management, deliverables are expected to be delivered on time, with the required quality and within budget – this is checked at the acceptance stage. There are many project management methodologies, each offering its own approaches to risk mitigation; choose the one that best suits your needs. They all emphasize the importance of creating project artifacts that contribute to achieving goals. The ability to effectively fulfill contractual obligations is important for the sustainable development of many organizations. However, let's focus on the user: what are their expectations?

If you ask ChatGPT what general term can be used to describe the results of design work and software builds that users interact with, it would be finished software.

It is important to make sure that readiness comes in two forms – from the developer's perspective and from the user's perspective. By developer, I mean the software provider as a whole, which is not necessarily an individual programmer.

In the limit of IT product – This is ready-made software

Thus, ultimately, an IT product is a ready-made software that not only solves the user's problems, but also inspires confidence, responding to the challenges of the time. In this context, the project becomes an auxiliary tool and one of the sources of product development, during which we constantly check the readiness with the needs of users. I will demonstrate the connection between the project and the product using the diagram I developed.

Let's imagine that we are just starting to implement the project. At this stage, there are no requests from users yet, the project tasks are formalized, there is no technical debt, and the product hypotheses have already been formulated by the Customer. Moving to the right, we see the product backlog – a list of tasks for the current stage. Even further to the right is the release plan, for example, a calendar schedule. When we reach the assembly stage, it is necessary to check the readiness criteria. If we are lucky, the technical task clearly specifies the acceptance procedures. However, in practice, this is often not the case. The Customer may be busy and ask to demonstrate some history of approbation and testing with users. It is important to be able to use this situation to the benefit of the product. The question arises: how to prepare for this? This is necessary, since the process of receiving feedback must be manageable; otherwise, anti-patterns may arise, which we can call “rakes”. I will share my experience, talk about the difficulties I encountered, and how to avoid them.

Anti-patterns and patterns of software readiness verification

Let's consider a matrix where the Y axis represents your internal assessment of the product's readiness at the time when the update will be transferred for external use. The X axis represents the user's readiness for acceptance. Ready means the user is experienced in this class of software. At the same time, it is not at all necessary that he is interested in our implementation. Not ready means that he is very busy or this software is new to him.

So, the first rake in terms of damage to the image is to blindly send the experts raw software with a request for feedback. You know that it is raw, he does not, otherwise he would not undertake the examination, so he will test according to his own understanding. Get a negative conclusion, you will iterate and learn from your mistakes, perhaps, the deadlines will be missed.

The second rake is when an uninvolved user receives raw software, again it’s not good – either you will remain without an answer, or you will fail simple tests, since, unlike the previous case, advanced scenarios are unlikely to be tested

The third option is that the features are ready for testing. Independent expertise is less bad here than before, but “time to market” will be postponed again.

Finally, the last rake, your software can, the user potentially wants, but we don’t know about it and don’t do anything. So we lose the innovative potential of the product.

About product artifacts

Let's return to the picture above with product artifacts. If we managed to avoid the “rake”, then the user has already contacted the assembly, and requests will be received in the process of solving problems. They need to be collected in the request log and linked to project tasks. In a simple case, the next stage of the project can be focused on fulfilling these requests, in a more complex case – an increment of functionality is expected, and in an even more complex case – the launch of a related project using our version of the product.

In addition, there is always technical debt, both explicit and implicit, that needs to be managed. Ignoring this debt can lead to an increase in the cost of changes to the software code. For example, what distinguishes a successful product from an unsuccessful one? A successful product brings in more revenue than the cost of its development. In this context, such an artifact as a single product backlog is important. However, its creation is only the first step.

The first challenge is to identify metrics by which software readiness will increase, say, in a year. The second challenge is to use these metrics and a countdown to create a plan to achieve the goals. Artifacts such as a product roadmap, release plan, and event map will help here.

Product ≠ Project

• A product is impossible without formalization and tracking of target quality and implementation metrics; in a project, by default, this is an optional attribute

• The product is developed through projects, including internal ones, united by a common roadmap

• A product, like a project, can be financed from different contracts

• The product is not necessarily the result of the project

• In the product life cycle, project stage protection is one of the criteria for software readiness, but not the only one

• A product always has technical debt, explicit or implicit, that needs to be managed

What is important to note and this has been verified by personal experience is that, in the limit, a product team is able to independently synthesize and achieve development metrics, even in conditions of uncertainty, through empathy for the user (product thinking) and backward planning (product approach).

On the role of team interaction and product approach

In aviation, there is a job titled cargo balance dispatcher, who is responsible for distributing cargo on board an aircraft to ensure safety and fuel economy. During takeoff, the rear balance is critical, and during landing, the front balance is critical. Therefore, sometimes a dispatcher accompanies an aircraft in flight.

Is it possible to distinguish who is more important for cargo delivery: the flight crew or the dispatcher? In my opinion, this is impossible. The question often arises about who is responsible for issuing a release. This question is incorrect until there is a common understanding that:

• Responsibility and Risk: Responsibility for the result always carries risk.

• Risk justification: Risk must be justified, which requires regulations and agreements within the product approach system.

In a product approach, we must regularly synchronize with each other at all stages of development – from sprint planning to release, covering several areas (team calls, conditionally soft and hard cycles of product development):

To answer the question of why a software developer needs product thinking, you can do a separate exercise.

So, how can we “marry” project development and product development?

• Determine the portfolio of products, existing or being created, and place them in a single information field

• Move using the “progressive JPEG method” and create artifacts of the version products, place them in a single information field

• Conduct an experiment of product teams on the implementation of roadmaps under one mandatory condition – the implementation of the thematic plan of projects on time and with due quality

• Place external product artifacts in a single information field with users and customers

Bonus

Product Roadmap Template in Excel

In conclusion, I ask product development practitioners to speak out on cases of transition from the project development side.