Cross-team Product Development & Delivery Process: Pipeline Success Indicators. (Part 2)

Table of Contents

• Intro & Definition
• Pipeline Success Metrics
• Context Initiation Phase
• Discovery Phase
• Development Phase
• Go-to-Market & Release Phase

Let’s recap where we were left in the previous part of the series:

We defined a high-level overview of the sequential development & delivery pipeline. Now, how do we know it works as expected?

Key Indicators

Every process you build should be based on a set of metrics and indicators that represent its efficacy. The one we are crafting here is not an exception to the rule. So let’s think of a couple of qualitative parameters that define the process:

• Ease of communication
• Transparency
• Bidirectional information flow
• Clear exit criteria and the definition of done
• Existence of a single source of truth
• Strict separation of responsibility

What is important to understand is that all the indicators above can be applied both to a process as a whole and to each phase separately. Let’s take a closer look into each of the indicators and see how it can be evaluated.

NOTE: You may automatically start thinking of such parameters as performance, velocity, integrity, added value, and so on. Although it might make sense to include these as well, I do believe that they are just a side effect of the quality of the development & delivery pipeline. If you take care of the indicators mentioned in this post, the rest of the supplemental parameters will automatically improve.

Ease of Communication

Communication is the key, basically, to everything. But it has to be efficient. This means setting just enough recurrent meetings, producing a meaningful agenda, and closing meetups with written outcomes and steps to proceed further.

But not only. You also have to establish and support communication channels in collaboration tools like Teams, JIRA, or whatever else you are using. The written form is easier to track in case of any confusion in the future and, of course, easier to share across the parties involved.

Some key communication points to consider:

• Initiation context. Make sure the stakeholder can dedicate enough time to iterative collaboration with a product manager assigned to the initiative.
• Discovery. Critical communication point — here product, project, and development leads to discuss and plan the future implementation plan.
• Development. It requires constant reporting and status updates, as, mostly, all the change requests appear here. There are tons of literature on how to establish proper communication during the development phase.
• Go to market. Make sure that the product marketing manager is aligned with key KPIs, metrics, and capabilities of the system and produces the correct marketing materials. Otherwise, you’ll end up rushing to fulfill the promises given to the end-user, but never intended to be delivered at that time.
• Release. Make sure that changelogs are clearly shared across the departments. Another important piece of information to deliver is: how the expected metrics are aligned with the actual ones after the release.

Also, you have to make sure that each department lead is joining the conversation at a right time. You would wonder, but it is still an issue in a huge number of companies.

Summary:

• Definition: being able to collaborate with key stakeholders of the process in a shared environment.
• How to track: By receiving feedback from key players. You have to ensure that they don’t have any issues with communication in cross-functional meetups.
• Dependencies: communication is totally up to the professional attitude of each player, as well as the proper configuration of the communication form and its frequency.
• Outcome: Improves everything. Simple as it is.

Transparency

What does it mean for the process to be transparent? And how does it affect the overall success of the product development?

Every key player in the process should be able to answer three questions at any time:

• What are we building?
• Why are we building it?
• How are we building it?

If the product manager or development lead cannot answer any of the above questions — how would you expect the desired outcome to be produced?

The key to establishing good transparency, of course, lies in efficient communication between departments and easy access to any of the produced artifacts such as exit criteria at each phase.

Summary:

• Definition: Being able to answer ‘what’, ‘why’, and ‘how’ at any time.
• How to track: By controlling the number of redundant discussions and meetups. Also, ensuring exit criteria from each phase are fulfilled. Or just ask people the questions above :)
• Dependencies: Ease of communication, and access to produced artifacts.
• Outcome: Increased engagement level, interchangeability, performance, and velocity.

Bidirectional information flow

This is a key indicator of proper change management. Each department delivers its own statements on estimates, costs, and expectations for the product being developed. But they are rarely correct right off the bat and will often require a couple of revisions before settling down to an acceptable level.

The process of shipping a product always comes with some level of uncertainty, so the more flexible the team is, the better you will conform to new challenges along the road.

However, to be ready to do so, you need the information to be moved back and forth across departments, contrary to a usual top-down flow, that is widely spread as a common practice across the companies.

The person, who oversees the whole process, has to ensure that there is constant feedback being provided from all departments and that the information is shared with every key stakeholder. The classic way of doing so — is the so-called, roll-up meetups, established once or twice a week, and keeping a single source of truth of the process always up to date.

Summary:

• Definition: Channels to declare the state of the product at any given point.
• How to track: Roll-up meetups, written summary status updates, making sure that ‘yes’ culture is not taking its place around the process and people are giving honest feedback.
• Dependencies: Ease of communication, and transparency
• Outcome: Increased flexibility and faster response time to any changes.

Clear exit criteria and the definition of done

Each phase of the process should result in producing either tangible or intangible artifacts. Basically, this is the whole point of having a process, right? You don’t want just to gather a ton of people in a cross-team meet-up just for a nice talk, then do some work and produce nothing.

Having a strict definition of the exit criteria is a must. Let's take a look at a couple of examples:

• Initiation context. This phase should end up with a product manager being able to present the potential solution to a problem or an opportunity to all the parties involved. Consider something like a high-level presentation with key success metrics and the purpose of the work to be done.
• Discovery. A lot of work goes on here. Designers draw wireframes, the project manager establishes a team structure, the product manager deals with requirements definition, architects depict possible solutions, and so on.
• Development. Well, that is just all about a working product, right? And documentation (APIs, configurations, etc.).
• Go to Market. The result of the following phase directly corresponds to a number of marketing materials produced to reach out, engage, teach and sell the product to the target audience.
• Release. Think of reporting materials and changelogs, KPI measurement results, and so on.

If that seems too vague to you, don’t worry, we’ll cover the exit criteria for each phase in the following series of posts. For now, I just want to make sure you get the sense of the importance and inevitability of producing artifacts during the process.

Summary:

• Definition: A list of tangible or intangible artifacts for each phase.
• How to track: Set up a minimum required list of artifacts to be produced after a phase is completed. But also remember, that overcomplicating will lead to increased bureaucracy and a slowdown in delivery. To find the right balance.
• Dependencies: Ease of communication. People need to understand what are the expectations for the exit stage.
• Outcome: Improved clarity of the process and transparency. Also, clear expectations of the outcome will keep people focused on the desired results, which will in its own turn lead to a much faster development process.

Existence of a single source of truth

This indicator is aimed to avoid misinterpretation errors at any stage of the development & delivery. There should be always a place to refer to in case any details were lost during the discussion or development iterations. That place should be treated accordingly, meaning kept up-to-date all the time and aligned with the concerns of the parties involved in the development.

Take JIRA as an example. It can be a single source of truth for all the requirements and constraints defined for a specific feature. You can expand the usage of JIRA to reflect the whole product state.

If you’re not a big fan of JIRA (who is, really?) — think of any other project management tool. Trello, Asana, and so on. It doesn’t matter.

Each phase of the product development & delivery process can possibly have its own source of truth tied to the context they’re operating in. The engineering department certainly should produce SRS (Software requirement specification documents) specs, work breakdown structure documents, design diagrams, etc. It doesn’t have to be 100-paged work, just enough by size to keep product managers, stakeholders, and engineers aligned on the expectations of the outcome of the development phase.

We’ll take a look at specific artifacts in detail in the following posts of this series.

Summary:

• Definition: A place to refer whenever any uncertainty or miscommunication arises. People have different interpretations of verbal messages, don’t fall into this trap.
• How to track: Pretty much the same as with exit criteria. Make sure each department has an agreeable list of documents that they should create and refer to during the development.
• Dependencies: Exit criteria, separation of responsibility, ease of communication, transparency.
• Outcome: Improved velocity of the development & delivery process, better quality results.

Strict separation of responsibility

You have to assign a separate person to be responsible for each phase. And let that person do the job. But somehow, you can often see that a product manager becomes responsible for the whole delivery, and then starts micromanaging each phase, leaving less space for department leads to… actually, lead. That is a direct way into a disaster.

Development leads should define the solution and provide their own estimates. Product managers should be busy with the product definition and upcoming changes. The marketing manager should produce its own set of artifacts. And they have to take responsibility and power to do it in the most efficient way. Otherwise, don’t call them leaders. They are your subordinates.

So, by assigning people to be responsible for something, you can delegate the context to them and concentrate on controlling and monitoring the process. Identify gaps, and miscommunications, provide feedback on produced artifacts, mitigate risks and keep the whole thing in a good shape in general.

Summary:

• Definition: Each department lead should have enough power and responsibility to handle the corresponding phase.
• How to track: Keep the environment shared only to a certain extent. Provide clear instructions on who is responsible for what. Don’t let product managers or stakeholders dictate the rules for other departments. They have other things to do.
• Dependencies: Ease of communication, transparency, clear exit criteria.
• Outcome: True leadership-driven environment that produces a lot of great side effects: people are engaged, motivated, and able to take an initiative when something goes wrong.

What’s next?

That was quite a significant number of symbols to read there. But now we have the pipeline supplemented with the qualitative expectations from it.

In the next chapters, we’ll start breaking down the process and dive a bit deeper into each phase in particular. We need to understand how key players interact with each inside a specific phase, what processes they can use to manage the “getting things done” routine, and what are the expectations and requirements of the exit criteria of each phase.

Part 3