Creating a Product Discovery Track: A Practical Guide

Lucas Fonseca Navarro
Product Coalition
Published in
8 min readJan 3, 2020

--

In the last decade we have evolved a lot in terms of agile development, Agility has become its own concept and we have lots of books and conferences for this subject. Despite this movement, when we look at the complete development cycle of a product, from conception of initial ideas and assumptions to final delivery, we have tremendous productivity bottlenecks. Agile methodology has matured a lot in the technology development phase — when software engineers get their hands dirty — but everything that comes before it continues to be done in a old-fashioned way in most companies.

Marty Cagan, one of the top names in the Product area has exposed these arguments in his masterpiece Inspired: how to create tech products customers love. To work around this problem, bringing agility to all stages of product development, he created a methodology called Dual-Track Agile: The proposal is that teams should create a track called Product Discovery running parallel to the development of the product (the delivery track).

Dual-Track Agile, by Jeff Patton.

In theory this track should run on the same agile principles used in software development, so we increase the reach of agility within the product life cycle. In recent years this model has been widespread in the midst of product development and is currently a reality for many companies. Although this is not yet a mature enough area, it is difficult to find examples of practical applications, success stories and cake recipes on how to apply in your business.

I had the opportunity to build a Product Discovery Trackfrom my experience at OLX Brazil and learned a lot from it. In this article I share my vision on how to deploy this methodology in a product-oriented technology company, as well as presenting my case at OLX and the results we have obtained from it.

Kicking it Off!

1) Prepare the ground with each member of your team

The main goal here is to help your team understand the importance of an additional Product Discovery Track. You need to explain why, explain where there are bottlenecks, and how this processes will help solve them. Remember, you are proposing that they participate in a whole additional process load in parallel to existing processes, at this time empathy can help you get the message across in the best way.

I recommend that you start by convincing people from areas closer to the product, such as designers and analysts. Next is the support of your team’s engineering manager and only then should you run after the engineers! Prior suggestions of articles for them to read on Product Discovery can also help a lot (I left some references in the appendix to the article).

It is important that this new track be built in conjunction with the entire team, so this step is critical. You need people to see value to get the support and participation you need for this adventure. Everyone must participate!

2) Create a manifest together

It is important that all team members understand clearly what you expect to achieve with this new load of processes and ceremonies to be introduced — this is crucial to ensure that everyone is on the same page, engaged and motivated to get their hands dirty. I recommend that you create a short manifesto — a paragraph of text — together describing the main points, what you hope to build and what this changes will be about. With my team at OLX we made the following manifesto about Product Discovery:

Constant cycle of product development, understanding what we should build, what our user needs, what market opportunities we can rely, how our competitors are advancing. Ensure that we are meeting our goals. Ensure that we are moving in the right direction in a hyper agile manner.

3) Structure the processes and meetings for the new track

Make the definition of at least one recurring meeting initially, to ensure that there is continuity and follow-up in the Discovery tasks and dissemination of the learning obtained through them. Another recommendation is to perform some form of joint planning — like engineering tasks, product discovery tasks need to be prioritized and discussed for higher quality of deliverables.

It is important that everything that happens on the Discovery track is visible and accessible at any time by any team member, and that there is openness for everyone to participate, perform tasks and bring in new ideas constantly. Try to do all this in the simplest and least bureaucratic way possible and use the tools preferred by most of your team members to run this track. If the team likes to work on Trello tasks but you prefer Jira, give up your preference — avoid any additional wear and tear that is not due to the Discovery track execution. Below I will present the structure developed with my teams at OLX Brasil.

Structure created with my teams at OLX

Idea Life Cycle

Initially we defined the stages of an idea until it becomes a project and finally is developed and launched for our users as a product:

Birth: The birth of the Idea always comes from one of the team’s Objectives/goals for the quarter (I won’t go into the details of how we set these goals — they came from a company-defined process). From the Objectives we create solution Hypothesis, we set success and risk metrics, all implications, impacts in other areas of the company, size of opportunities and any other relevant information about the hypothesis. From this we come up with one or more solution Ideas.

Research: At this stage the goal is to eliminate as much risk and uncertainty as possible and bring more information that helps to prioritize ideas. We need to understand the value it will bring to the our users, whether it is viable in our business model, whether the user will be able to use the proposed solution, and whether we can develop it. This information is important so that we can always prioritize the most cost-effective ideas for the next phase.

This phase is where we perform A/B testing, usability testing, POCs, spikes, talking to stakeholders, talking to users, doing quantitative analysis, whatever can bring us inputs and help mitigate all risks. This step is naturally multidisciplinary and it is very important to have multi-area pairing promoting constant exchanges between your team members. Engineers can participate in usability testing, designers can assist in quantitative analysis and so on, for example.

Build: At this stage, with the risks minimized and the idea prioritized, we go into development. Even with all the research done, there is always a risk that we will not catch something or even miss a development detail, so it’s important to have online validation — preferably through A/B testing with users. Having this validation done, the idea finally comes alive and can be launched for all users!

Meetings and Processes

At first we defined only a biweekly meeting lasting up to 1 hour and 30 minutes, where we dealt with the following topics:

  • Review advancement in team goals
  • Present task breakthroughs in Product Discovery Track
  • Presentation and discussion of new ideas
  • Prioritize the work next week and list responsibles for each task

We decided to operate using a Discovery Sprint, this meeting worked as a planning so we could define the scope to be prioritized together, and ensure greater commitment to deadlines. We tried running daily meetings but in the end we were left with only a 1 hour checkpoint in the middle of Sprint to present partial results and make modifications when needed.

We also created a board in JIRA to give visibility to the tasks of all areas. In addition we have made it clear what comes next and have made available an online environment so that all members can post ideas at any time that will be discussed at the next meeting (a point for more inclusion).

Additional Recommendations

Who Should Attend: Everyone Should Attend! We defined that we would at least need one representative from each of the areas, but if your team is small (up to 8 people) the ideal is that everyone always participates, be it designers, analysts, product managers and especially engineers. Sometimes a member of the Directors board attended the ceremony.

Discipline is key, you need to be an evangelist: Any new process requires commitment and time to mature and to get people into the habit. At the outset it is crucial that there is discipline and engagement from the creator of these processes to constantly call members, motivate them to continue until the force of habit is created and the process is mature and productive enough for its value to be obvious to all.

Evolution is essential: Watch and evolve processes constantly, there needs to be continuous improvement as with all processes, but when it comes to Product Discovery, everything gets even harder given the lack of maturity. There are no clear references on how to perform these processes, there are not enough cases yet so continuous observation and improvement is required to adapt to your team’s reality on a constant-basis.

Some of the results we gathered from these processes in our first semester

In the beginning we adjusted the shape of the meetings a lot, we tried different structures, we tried different tools and dates. After 4–5 months we had a good stabilization and the processes were running naturally, always with at least one participant from each area. Some benefits are listed below:We greatly increased the participation of the whole team in product discussions, leading to more accurate deliveries.

  • We greatly increased the participation of the whole team in product discussions, leading to more accurate deliveries.
  • We learn to better set team goals
  • The motivation increased a lot because everyone had an active voice and participated since the ideation of our deliveries
  • Greater inter-area exchange (Design / Product / Data / Engineering)
  • Everyone was much closer to our users, we had members from all areas participating in field surveys, interviews with users in the company and other indirect activities.

Overall, another layer of team integration was created, greatly strengthening the bond between all members — improving our relationship and greatly increasing our productivity!

Appendix: Read references to share with the your team

https://medium.com/@eugenesanu/7-principles-for-a-product-discovery-b2d9a44b98da

https://medium.com/productboard/the-age-of-product-discovery-part-i-27ab7fc02e54

https://medium.com/productboard/the-age-of-product-discovery-part-ii-aebc7f755223

https://medium.com/@romanpichler/product-discovery-tips-7c72da6323f1

https://uxplanet.org/product-discovery-techniques-1-inspiration-c393af948bc3

https://uxplanet.org/product-discovery-techniques-2-ideation-568835af34b4

https://uxplanet.org/product-discovery-techniques-3-prototyping-testing-b99f4d4f7163

--

--

Co-Founder & CEO at Já Vendeu, helping people sell their stuff without any effort