The day-to-day hands on work for organizations, especially ones that operate in the tech space, involves product discovery and product delivery. Before jumping into what that means, let’s explore the team types commonly seen in organizations.
Most organizations consist of three main team types:
- Delivery teams
- Feature teams
- Product teams
In delivery teams, the product manager is the backlog admin for a list of tasks the team needs to work on. This list of tasks or components is often provided to them as “requirements” from stakeholders and/or management. The teams, in this case, are just responsible for executing and delivering.
Feature teams look like a squad from the outside – they often have cross-functional skill sets in the team that sometimes work together. But these teams are measured by the number of features that were shipped. They are all about output, which is represented by a traditional roadmap/Gantt chart. The value and business viability of what is delivered are the responsibility of the stakeholder or executive that requested the feature on the roadmap. The product manager facilitates features being designed and delivered. The role is similar to that of a Project Manager. Feature teams may run an occasional survey to their customers but are unsure how the feature you helped develop connects to the net promoter score (NPS) results.
Product teams, on the other hand, themselves are accountable for the value and viability of what is produced. Product teams have true ownership of their product vision, mission, strategy, principles, goals, and they work with different parts of the business (regional teams, sales, marketing, etc) to coordinate their activities. Those departments and stakeholders don’t tell product teams what to build. Product teams use hypothesis-driven development to measure the impact of their outputs – what outcomes and goals they are contributing to. They are also actively and consistently validating new opportunities and solutions rather than working on a pre-defined list of features.
It’s important to understand which context you find yourself in. For delivery teams, the scope for product discovery is non-existent. For product teams, on the other hand, it could be highly beneficial to talk to their customers, understand their problems, and decide what to build. None of the teams are better than the other – they each serve their own purpose. Based on your context, it’s important to come up with your own processes and ways of working that help you achieve your goals.
Depending on the nature of work in your team, you may have more business-as-usual work (BAUs), rather than long-term goals, such as the accounts payable team in the example above. Product teams, on the other hand, tend to have fewer BAUs and more work that helps them achieve certain outcomes and goals. This is not to say that one approach is “more correct” or “more valuable” than the other. Although a team like Accounts Payable may have fewer goal-related tasks than a typical product team, if they don’t run the payroll every month then employees wouldn’t get paid. Their work is still important for the organization.
The goal of product discovery is to learn as quickly as possible. Learn what problems your customers have, what solutions might help them, and what sort of impact those potential solutions would have on your company’s business goals. Product discovery is often split up into two segments – the problem space and the solution space.
The problem space is where a group of people (team, department, company) gain clarity around customer problems and validate those problems to gain a better understanding of them. People should not start thinking about solutions here already to resolve those problems. The goal here is to gain a deeper understanding of what the customer’s pain points are.
In the solution space, the validated problems that fit the company/department/team goals are then taken and ideated around, to create low-fidelity prototypes that can be tested and (potentially) incrementally built up into a high-fidelity product to address the customer needs.
Product discovery helps answer the following two questions:
- Is this problem worth solving?
- Is this an idea worth pursuing?
There are lots of ways of doing product discovery but regardless of which practices and tools you use, it needs to be continuous. Meaning, you want to learn more about customer problems every week through practices like user interviews, while working on building prototypes or higher-fidelity versions in delivery. An ideal week for product teams should include some sort of touchpoint with the customer, some ideating and testing of product increments, and delivering the validated increments.
Organizations often have a mix of units, departments, and teams that use discovery approaches and others that have never heard of this concept. A good place to start for those new to this is to find a way to better understand who your customer is for your product/service and what their pain points are. Surveys, emails, and other indirect methods are not bad ways to do so, but the best way is to talk to them face-to-face. You can reach out to the design or UX teams in the organization to support you with setting up an interview flow and potential questions to ask the customer.
Once you have some pain points, you want to validate them against what goals you have as a team/department/unit. For customer needs that don’t match your goals, stick them into a backlog for something that you can refer to at a later point. For validated pain points that match your goals, go into the solution space and create prototypes to test with your customers. The dual track single flow (DTSF) mental model, seen below, illustrates this approach.
Teams are best able to work on discovery topics if the management hands them problems to solve rather than a list of activities (initiatives, projects, tasks, etc) to execute on. Teams also need to be mature enough and have the appropriate skills and authority to take a problem, validate it, and build solutions for it. This may not always be the case. Product Agility Coaches play a big role in helping teams and management get to this stage of maturity.
The goal of product delivery is to ship as fast as possible, with the highest quality. Here, teams take the tested low-fidelity concepts and prototypes from discovery activities and build them with higher functionality and quality.
The input for delivery is usually the product goal(s). Product goals are derived from the product strategy. Eventually, the tasks a team has decided to work on should be derived from a single backlog. For teams working with the Scrum framework, the backlog items are then brought into sprints, if they are expected to help achieve the sprint goal, which is a subset of the product goal.
A product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months. Sample goals might include acquiring users, increasing conversion, generating revenue, or reducing technical debt. Having one commonly agreed goal aligns the stakeholders and development teams to the same priority. Each product goal acts as the foundation for identifying helpful sprint goals.
Product goals help bring focus and prioritize the things that need to be included in the product backlog. Without a product goal, your product backlog just becomes a catch-all bucket for nice-to-have features, unvalidated stakeholder requests, and tasks that don’t help you move toward your goals. Only add an item to the product backlog if it helps meet the product goal. These product goals can then be captured as milestones in your roadmap.
A product backlog is a prioritized list of work that needs to be done by the team in order to achieve the product goal. The items at the top of the backlog are the most refined, valuable, and detailed. You are sure that these items can help you deliver an increment of value to your customers. The items towards the bottom are unrefined and may not have all the needed details yet. For the items at the bottom of the backlog, don’t worry about adding all the details to these items now, as the details will emerge from lessons learned via the experiments you run each sprint, and the user data and feedback that is generated. Adding details to items that you may work on weeks or months down the line, poses a high chance that those details will change based on new information. Therefore, it’s suggested to fill in the details as they emerge over the course of the next weeks in order to de-risk your approach, and build and test the product incrementally. The learnings from the tests are then used to refine the upcoming list of activities.
Helping a team adopt a continuous discovery and delivery approach can help them be effective in identifying the right problems to solve. The DTSF model encourages an empirical approach, based on identifying key business metrics, where the discovery and delivery activities feed into one another for effective customer and business value creation. Identifying assumptions and key business metrics, testing problems and solutions, building incrementally, working collaboratively, and incorporating constant customer feedback, all represent the pillars of the DTSF model that can be applied to any product or service that an organization may be building.
Discovery and delivery activities should happen continuously. It’s an antipattern to have a phasic approach where a unit or a team spends one week gathering information from surveys, and works the rest of the quarter/year based on that input. The idea is to continuously infuse little bits of customer feedback into the increments that are being delivered weekly.
This article brings an end to the Ingredients of a Successful Product series.
Rahul Bhattacharya 
1 thought on “Discovery and Delivery”