Cross-team Product Development & Delivery Process: Discovery Phase.(Part 4)

Table of Contents

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

In the previous article, we have defined goals, processes, and exit criteria for the context initiation phase. Now, when the product manager has all the information to proceed, it is time to do some heavy lifting. Let’s take a look at what happens during the discovery phase:

Discovery

This is where all the planning happens and the fundamentals of the quality are established. The product manager gathers an initiative group, consisting of department leaders, that will participate in further development and release process.

The primary goal of the phase is to provide development teams with all the necessary information (requirements, design, architecture, etc.) to be able to kick off the implementation.

So, how the discovery phase should be handled?

Firstly, the product manager should define the set of tools to be used for the requirement definition. The success of the following phase depends on tight and efficient collaboration between all the parties with different contexts: end-user requirements (product), user experience (design), technical capabilities (engineering & architecture), and quality assurance.

NOTE: It is important to understand, that the discovery phase is not only about what you are going to build, but also about what you are NOT going to do.

The discovery phase is all about narrowing the scope of the product to an acceptable level within time, costs, and resource limitations. And this is the main reason why the process should be handled within several iterations. Finding a proper balance rarely happens right off the high-level brief documentation of the product.

You may have noticed that the discovery phase itself is split into two iterative processes: definition & design.

Here’s how it may look in real life:

The product and project managers are responsible for the definition part of the phase, while the dev lead and designer are working on design documentation (UI/UX and architecture).

As the person who oversees the whole process, you have to ensure that each key player has enough information and time to produce the result during the discovery phase and that the communication between leaders is smooth and effective.

After a couple of iterations, the finalized product requirements documentation is produced. Now each department lead has to work on their own exit criteria from the phase.

Exit criteria

Here is a non-exhaustive list of artifacts that the discovery group should come up with at the end of the phase:

• Detailed product requirements (either brief documents or JIRA epics and stories (or any other structure, depending on which tool is used)).
• UI/UX wireframes (Figma, Photoshop files, etc.)
• Software requirements specification (non-functional requirements & high-level architecture design)
• Testing plan (use cases, automation, smoke, regression, etc.)

The better the documentation, the less change and schedule management will appear during the implementation. All the produced artifacts should be automatically treated as a single source of truth, each to its own department; hence the documentation has to be approved by key stakeholders.

Quality of Discovery Phase

The discovery phase can be marked as successful when the following pipeline indicators are met:

• Transparency: This means each department lead knows the answers to “what”, “why” and “how” the product will be built. If anyone has difficulty answering these questions, then either the vision of the product is unclear, or the requirements weren’t defined to an acceptable extent. You have to keep the iterations rolling until you have the answers.
• Single source of truth: Each department lead produced the necessary artifacts for their departments. The project lead completed the planning of scope, budget, and effort. The engineering lead composed diagrams and outlined non-functional requirements. The quality assurance lead has come up with the outlined testing plan. The designer produced the wireframes.
• Separation of responsibility: Each department lead knows exactly what they are responsible for during the product development
• Bidirectional information flow: Every department lead has their schedule prepared for constant information interchange between departments during the upcoming development phase.

You better not proceed with the development phase, unless you have the indicators above fulfilled.

What’s next?

All the information is now ready to be delivered to engineering team leads to kick off the development. Project managers have the initial backlog, epics are written, and the definition of done is set. You are ready to start the development phase.

In the next post, we’ll take a look at what should happen in the development phase of the process.

Part 5