Cross-team Product Development & Delivery Process: Intro & Definition. (Part 1)

7 min readJun 30, 2022

Have you ever observed a situation inside your company when the product is being delivered with constant delays? When the engineering department is rushing around like firefighters, spending 90% of their time attempting to cover never-ending and always urgent requests from product managers?

Or maybe when you’re always behind the schedule, missing documentation, briefs, specifications, or marketing materials? Confused people at cross-team meetups, not knowing what is going on?

The list of such situations is huge and quite individual to each separate business. And you may be one of the luckiest persons in the world if you have never faced those.

But if you do, don’t worry. This is quite a common pitfall for every company, that became large enough and hasn’t ever bothered establishing proper cross-team functioning rules.

Luckily, it is never too late to revisit the processes.

In the following series of posts, I’ll try to bring a bit of clarity on how the product development & delivery may be handled, how you can start applying it in your area, and what the benefits are. And will outline the consequences of ignoring the improper process setup from a long-term perspective.

NOTE: The strategic planning of the product development is intentionally sacrificed here in favor of an operations and execution level, as strategic planning itself is a whole separate topic to describe from a C-Level executive's perspective. I would like to concentrate more on the duties of department leads and heads of whole directions (product, development, testing, etc.)

The Definition of the Problem

The whole mess that often happens in product delivery has its roots in the fact that domain knowledge is separated. Product managers are taught their own processes, project managers mostly refer to PMBOK guides, and engineering leads are using SDLC processes… well, I guess you get the point.

The methodologies used in product development often concentrate on a specific area of operations, like the product definition, project and team management, software engineering lifecycle, quality assurance, releases, and so on. It is fine, in general, as each area needs its own standard.

But the more the company grows, the more things are crafted at the intersection between the teams and departments. Isolated domains inevitably become shared ones, and you need to handle them appropriately.

Naturally, small businesses often use simplified processes and direct communication between the parties to move forward. This approach has proven its efficiency, but it works only to a certain extent.

When the team starts to scale, communication gaps are popping up like mushrooms after the heavy rain, and isolation between departments becomes a huge pain. It may lead to a velocity slowdown, more time consumption, more uncertainty, and finally, result in poor product release.

So, how the organization should support its team scaling and avoid the disaster?

Possible Out-of-the-Box Solutions

Before jumping into details, I would also like to mention that there are industry standards and methodologies, of course, that aimed to handle the problem mentioned above. For example:

SAFe (Scaled Agile Framework)
LeSS (Large-Scale Scrum)

The list is incomplete, of course, it is just an outline of the most popular approaches.

But it is important to understand that they are pretty vague and designed as methodologies based on Scrum, which means that there is a large room for different interpretations upon the actual implementation of the latter. Not even mentioning that Scrum itself is not a silver bullet and there are companies that are not using it.

SAFe was designed to cover the needs of the enterprise businesses in the first place and is still one of the most popular frameworks. However, the important thing is that it is used for organization-wide migration to Agile methodology, which might not always be a great fit for a specific business.

LeSS is a much more lightweight methodology compared to SAFe and describes the process of scaling existing scrum methodology to multiple teams. Which again does not cover the whole development & delivery process. (Quite an arguable assumption, but you’ll see what I mean as you will keep reading the article).

Simple and natural scale of existing process

Both are great, and I would definitely advise starting with LeSS first, as it provides a quite obvious and natural way of scaling processes across the growing departments.

Integration of Different Processes is The Key

The intent of the following blog post series though is to show how all the industry-wide theories and methodologies are integrated into the product development and delivery process in practice.

Down the road, you will discover how PMBOK Guide helps us to structure the whole process, how certain product discovery techniques improve the quality of requirements definition, how iterative agile methodology comes into play at the intersection of product and development departments, and finally, how the SDLC takes its own place in what seems to be complete chaos at first.

I will take the LeSS framework as a foundation (or as a concept), but won’t limit the process to it, so you can apply it even if you’re not using agile methodology. And also will take a deeper dive into certain areas to unveil the important details that supplement the product development and delivery process.

Context

Let’s assume that you have a company that creates a SaaS platform, which includes different small sub-products (or sub-systems) placed under the same hood.

The company consists of the following departments, with multiple teams in each:

C-Level office (CTO with the internal team, CEO, CMO, and so on)
Product management department
Software engineering department (QA, DevOps, Software Developers)
Sales & Marketing department

The organization simultaneously works on several subsystems that form a single platform that serves the clients. So, the platform itself is a product we will be talking about, while each independent piece of it will be called a sub-product.

The sub-product is developed through definitions of scope, called initiatives.

The key actors in the process are the following:

A stakeholder. A person who initiates the context of work and is perceived as a target audience of the future feature release. Clients, C-level executives, and product managers are the ones who in most cases could be stakeholders of a specific feature. Their responsibility is to provide the description of a potential problem or opportunity to the underlying parties who will kick off the discovery & development process.
Product manager. A person who is assigned to the initiative and who takes a responsibility for the overall delivery of the latter. They are responsible for gathering initial requirements, scope definition, and success metrics, as well as acting as a source of knowledge of the initiative.
Project manager. A person, responsible for the correct execution of the development & delivery process of the initiative as a whole.
Development Lead. A person, responsible for the technical implementation of the initiative. Depending on the type of initiative, this could be a head of the engineering department, an architect, or a software development team lead.
Quality Assurance Lead. A person, responsible for designing and executing testing plans for the upcoming initiative. Usually, this is the head of the QA unit or the team lead.
Product Marketing Manager. A person assigned to be responsible for the go-to-market execution for the specific initiative.
Release Manager. A person responsible for the release planning and execution when the initiative is ready to be delivered to the stakeholder. Though it is not necessary to hold a separate person for the following role, I would still separate the responsibility of the implementation and release of the initiative, so the development lead can fully concentrate on the quality of the produced artifact.

Depending on the size of the company, the list above may be redundant, and it is a common practice when people execute several roles at once. For example, the product and project management roles. Or release management and development leadership roles. Also, some companies establish a Product Owner role, which is a mix of product, project, and even marketing roles.

Although the list is incomplete without the craftsmanship roles, that make implementation and release possible — UI/UX designer, software engineer, quality assurance person, development operations engineer, etc. — I have intentionally skipped the latter as they are not the key players in the cross-team process setup. But you have to value them, as they’re doing all the magic for features to happen and come to life. :)

The Game Plan

Now let’s assume that a new market opportunity arrives in someone's mind. How the setup should look like to turn an idea into something with an added value to the business and be shippable to the end-users?

Let’s start with common sense and outline a high-level pipeline of the process:

The high-level pipeline of development & delivery process

You may find similarities with the definition of phases and phase gates from the PMBOK Guide. Although we do not treat the process as project delivery management, I find it useful to link some terminology from different methodologies here.

This is a good starting point. At least we now have some sort of sequential pipeline that can serve the development & delivery process and shed some light on the responsibilities and expected outcomes from each phase.

But it is still isolated within each department’s area of responsibility, so we need to improve the pipeline with interconnected activities between the parties. Also, the phase-gate artifacts are not clear: neither the purpose of it nor the specific amount and types of the ones.

What’s next?

In the next part of the series, we will define the shared activities between the departments within the presented pipeline and will outline the key process qualitative parameters and artifacts needed to make it efficient.

Part 2