Integrating Discovery & Delivery – Common Challenges

Most organizations that I meet in my work are struggling to integrate product discovery and agile delivery in a simple practical way that works.

I will illustrate what I mean by giving you examples of a couple of very common issues.

Agile implementation overcompensated towards delivery

Most organizations are in practice using agile to excel at delivery, not product development.

Almost every organization has experienced the challenges and pains with delivery. To many, agile held the promise to be the solution to this problem. So when agile was adopted, it was done with the intent to fix delivery as the primary objective and not necessarily to put the customer in the center.

The transparent belief that remained was – and may still be – that we know what we need to build, we just need to get it into the customers hands faster and cheaper and this is our main challenge. This succeeded. The memory of the pains of delivery still echoes from those years however. What also remains and that are still being chipped away at are some islands of technical debt left over from the big purge we had to do to get our heads above water enough to fix delivery.

As a result, most organizations still have software or IT departments set up for delivery, often with product leadership silo:ed off somewhere else. Agile teams are managed for, focused on and staffed with competency for delivery – building things right. You can feel that this is where the attention is when you walk into the room. Most people in these organizations unconsciously view agile as a means for delivery excellence, including – I would argue – a large chunk of agile coaches.

The main problem I see here is a misrepresentation of the agile roots and as a result most organizations have stopped at a partial implementation that only solves some of the problems that agile evolved to address.

To go beyond delivery and succeed with product development the agile values of customer interaction and satisfying our customer as our highest priority need to be taken much more seriously.

Teams disconnected from real customers

At its core agile is a radically customer centered approach. In reality, the majority of agile teams I see in the field have never met a real customer, don’t know what customers actually have said about their product or can’t explain what problems real customers have because they have not had any opportunities to connect with them.

This creates a mercenary culture of agile teams who become over-focused on technical implementation because they have no choice but to adopt a “tell us what to do and we will focus on how” mentality.

Most software developers are excellent problem solvers. Not giving them direct access to problem knowledge is a waste of talent. In contrast, the pattern I often see is that the organization and the agile implementation – seemingly by design – disconnects these problem solvers from first hand knowledge about customers’ problems.

It is as if the transparent belief is that engineers are too technical to be asked to understand real customers and their needs. Or alternatively, if developers spend time on that, we will lose efficiency in delivery. By shielding them from customers’ problems we are protecting our delivery efficiency which we are held accountable for much more than product success.

I see two problems here if this is how your organization is set up.

• You are going to build the wrong thing slower.
• You are also missing out on one of the biggest sources of product innovation – engineers who really understand your customers’ problem.

Discovery work is disjointed and out of rhythm from delivery

Many organizations have realized that product discovery can bring key value to their efforts. Some are already doing some form of discovery in terms of either what problems customers have or what type of solutions that these customers may desire to use to solve those problems.

In the field however, I normally see that the people who do this type of work are organized in one of two ways.

Either they are embedded into the agile teams, and in this case they are typically user experience experts tasked with designing wireframes and user interaction. What should the user interface flow of views, view design and the rest of the user interaction be so it can be built and delivered. The organizational problem that is solved here is “how” the user interface should implement the feature that product leadership has decided should be built. That is, they are working inside the box of “designing the UI and user flow for a given feature”. Rarely are they asked to give their input on the end to end customer experience, what features should be developed, find out more about the actual problems that customers have or asked to evaluate the importance of those problems.

The other common way to employ discovery is outside the agile teams that build and deliver the products in a way that is also outside the product decision making process. In this setup I often see two ways to use discovery competency. The first is similar to an in-house research agency where they are asked to research a specific thing for your product decision making person or team. This is customer research on demand, often in the form of customer interviews that leads to insights. The end result is a presentation of what those insights are and this is the deliverable that is handed back to the product decision making person or team, at which point the engagement ends. The percentage of these insights that are actually acted on tend to be very low and when they are the lead time until they make it into the product is very high. The second type of interaction is to delegate user interface design. Meaning, in this case they fill a similar need to the embedded version above but they are used as shared specialists over multiple agile teams and sometimes multiple products.

I see two major problems with these setups.

• You are using people who are professional experts at finding out what is real about customer problems and verifying solutions that solve those problems, but you are not giving them a real say in what actually gets built.
• You are also not allowing them to participate in the whole product development cycle of research, validation, delivery and follow up to ensure customer success. Instead, you are viewing them as specialists and limiting them to transactional work in smaller compartments to solve pieces in isolation, rather than becoming a highly involved partner in solving the whole puzzle end-to-end.

The consequence is missing out on product impact and your path to customer success and product earnings is lengthened. You also run the risk that your best product discovery talent will become demotivated by the limited opportunities to create customer impact that matters.

Large stakeholder driven roadmaps with unvalidated features

With discovery work at arms length from the product decision making process most organizations that I see tend to have large roadmaps of features that have not been validated with customers.

One product organization had a situation similar to this before I and my colleagues started working with them. After we integrated both discovery and delivery for the first product and teams the situation was reversed about six months later. At that point, almost everything that was actively worked on had been validated with real customers. The reason? The ideas that were validated successfully got both product leadership and development teams so excited to build because they were certain that they would solve real problems they knew customers had and valued. Gradually, the team started viewing unvalidated features on the roadmap as candidates for discovery and validation rather than things they had to put into the product and deliver.

In contrast, the most common situation is that what gets put into the roadmap are things that people in senior leadership believe are the right things to build combined with what sales people believe are things that will help them sell the product. This often leads to “check all the boxes” type feature lists and a product that needs to do everything that the old product did, but also ten more things that senior leadership believes is a good idea.

I see three major problems with the above situation.

• You are looking inside your own organization to find the answer to what the right thing to build is. The error here is that you are giving too much power over the product to people who are not going to pay for the product.
• Your setup has no effective filter on what ideas will create real impact. This will lengthen your path to earnings and increase the size of your investment.
• You are not trying to build a product that solves the most important problems that customers are actually having right now and in the emerging future. Instead, you are looking to the past (your people’s old reference points) and at competitor’s (older) offers with a scarcity mindset to determine what your product needs to have to compete on equal footing. This will result in a new product that solves yesterday’s problems and is trying to compete with mature products that already have solved those older problems. From a business view, this is entering a market where margins are already under pressure and declining.

Product development today is more about being faster at understanding what real customers actually need, are willing to pay for and use, then act on that to deliver something that works for them. Usually, these are also the problems that customers are willing to pay more for.

Product Managers with low understanding of product discovery

It is not easy to find good product managers. It is a difficult job, sometimes almost impossible.

Perhaps because it is so hard it is important to have a good source of advice and knowledge while growing your experience. Many of the product managers I meet in the field know very little about product discovery. It is often the case that the organizations they work for do not offer any guidance or training on what they need to learn to become good product managers.

The challenge here is for organizations and senior leadership to do two things.

• Change your selection criteria for product managers to include product discovery competencies.
• Start offering clear guidance on what product managers need to learn to develop and excel at their craft.

More coming…

In my next article we will look at how to resolve these problems to fully integrate both discovery and delivery in your own process, in a way that is customizable to your organization and product.