Integrating Discovery & Delivery – Patterns that work

This is the second article in my series on integrating discovery and delivery. In the first article I outlined some common challenges I have seen holding organizations back from benefiting fully from both.

In this article I will introduce some patterns that will help you integrate product discovery and product delivery in a way that works. These patterns have all been field tested in practice.

Main theme – On equal footing

The overarching objective of the changes and patterns I offer below is to put discovery and delivery on equal footing in all areas of your product effort through clarity, teamwork and process. Your goal should be to establish a balance where both are effective together.

Align on vision – Clear mandate on problems and solutions

This is a precondition to good product management in general. It is also specifically a necessity to drive the direction of a product using product discovery.

To be more specific, the product vision needs to be aligned with the rest of the organization including various stakeholders. This alignment also needs to establish a clear boundary where the product manager and the rest of the product team has the freedom of action to prioritize customer problems and select solutions.

You want your product manager and the product team to be accountable for making these decisions and to make these decisions in a way where they are informed about what is real about the customer segments you are targeting.

Your goal here is to ensure that the product team has ownership of all product decisions beyond alignment on vision.

One cross functional product team approach

All personnel and teams that contribute to the product need to work as one product team and share accountability for product success. This is implemented through a shared way of working, clear customer centered outcome oriented goals, shared responsibility and opportunity to contribute and through actually working side by side on work items across multiple disciplines.

Your goal here is to create a shared sense of “we”. You want a sense of ownership for your mission and the journey that feels like there is “skin in the game” for all people who are part of it.

Customer development through direct customer contact

Your product team will need direct access to real customers that are good representatives of the customer segments you intend to target. The right thing to build will be discovered by the product team through research and validation with potential or actual real customers.

Note that the intent here is product development, researching and validating problems and solutions. You’re not trying to sell the finished product. The purpose here is developing the product and if you succeed, the by-product will be the development of an early customer.

Anybody in the organization, especially sales teams, can of course help find these customers and the right people to contact. However, it is the responsibility of the product manager and the rest of the product team to decide what customers would be most valuable to contact to be researched and to take the initiative to do so.

If there are any obstacles in your organization to giving your product team direct access to potential customers it is the responsibility of senior leadership to overcome these obstacles.

Your goal is to put it inside the product team’s own area of influence to contact customers and use product discovery to find out the right thing to build, then deliver early versions of that product to these customers to validate if this leads to customer success in a way that is viable for you long term as a business.

If this succeeds, you will not just have a product that has been field tested to be viable in your segment, but you will also have your first reference customers.

Discovery backlog & Delivery backlog

The product manager maintains at the product level two backlogs.

A conventional delivery backlog with delivery items that have or enable customer value. These items are all intended to be built and delivered to production. The other backlog is a discovery backlog of items that consists of insights and questions that we need to research and learn more about.

Items in both of these backlogs need to be clarified and prepared before planning. The product manager has the final say on priorities. In the best of worlds prioritization develops over time to become a joint decision within the product team where the product manager on occasion breaks any tie.

Shared tactical rhythm for both discovery & delivery

Both discovery and delivery work uses the same ritual for planning on the tactical level.

Decide on your timebox for this rhythm. For one organization that I and my colleagues worked with we decided that six weeks was an optimal rhythm. This was short enough to be tangible and create a sense of urgency while also being long enough to realistically create customer impact given their product and organization. It also aligned well with the two week rhythm that their agile development teams already had established.

Use a product team room planning day for the actual planning itself. All personnel and teams that actively contribute to the product participates. This is similar to a big room planning, but for both discovery and delivery work items and for all personnel and disciplines that contribute to the product.

During the later half of this planning activity when agile development teams pull work items off the discovery and delivery backlogs, to break down their own work, there is one constraint – they have to pull minimum one discovery item. Meaning, each development team will be actively involved in at least one discovery item per tactical product period.

For each discovery item that gets pulled by a development team, at least one product discovery professional will participate (most commonly a designer). That person will support or lead through all phases of planning, research and insights working side by side with product leadership and engineers. After completing the discovery item the learnings are presented to the product team in the form of a team pitch at the next tactical planning session, at the latest.

Simple process for discovery items – Unknown problem vs Known problem

A discovery item in its simplest – and least refined – form is a key customer insight and something specific about that which we believe would be valuable to learn more about. If you write down those two things you can prioritize its importance in your discovery backlog. If you find this too hard it is likely that you need to do more work on your product vision. How to develop your product vision into clarity is a separate subject outside the scope of this article.

There are tons of tools and approaches out there to act on a discovery item. To offer an overarching structure that still allows any tool and your favorite method to be used the following simple process works in practice. With this approach you apply one of two different playbooks, depending on what type of discovery work you need to do.

Is this an unknown problem or a known problem?

Depending on your answer to that question, use the appropriate sequence of activities below. These are the activities that are to be broken down and planned together by the people who will be working on the discovery item.

Unknown problem -> Phrase your research questions -> Do your research (customers) -> Cross functional design sprint (including phrasing/selecting problems) -> Team pitch

Known problem -> Phrase a clear hypothesis about the problem -> Prototype solutions (design studio) -> User test your prototypes (customers) -> Team pitch

The rule of thumb here is that if you can’t phrase a clear hypothesis about the problem then you most likely are dealing with an Unknown problem, and should proceed accordingly. Team pitch here means presenting what you have learned or concluded to the rest of the whole product team.

If you want to know more about how to apply this simple process for discovery items I highly recommend this article on the subject by my colleague Marcus Castenfors.

Please note that this is not a silver bullet. This pattern is best seen as a solid step to get started with structured cross functional, end-to-end discovery and delivery. As your product team develops you may find yourself changing your own playbook.

Summary

There is much to be said about how to approach the challenge of integrating both discovery and delivery in a way that works in practice.

The patterns I have outlined above synergize well and I view them as some of the most powerful and simple that I have seen make a real difference. I also believe they can all be tailored to your product and organization, given that you and your organization are determined enough to succeed with modern customer centered product development.

I would recommend any organization that wants to excel at product development to give them serious consideration.