When Dual-Track Agile and Product Discovery go wrong

This will be an article longer than usual because it comprises an overall understanding to anyone unfamiliar with Product Discovery and Dual Track. It also contains many ingredients I used in my talk at ITSpring Minsk this year with the title Dual-Track Agile:: Lessons from the trenches.

For a better-guided read, I’ve divided the content as follows:

1) When there is no Discovery

2) What Dual Track is

3) Setting the ground

4) Dual-Track, Different Problems

5) Helpers for better Discovery

6) Takeaways

1) When there is no Discovery

Peter, David and Scott started developing a new app 6 months ago. They were running steady sprints and doing occasional overnights to attend performance and security issues. 3 months after they launched their first release to a controlled environment of only 10 users. It was a solid app, performant and looking very modern. Unfortunately, the feedback they had was not the best – the users could not perceive any value out of it, they didn’t understand the given experience.

They went back to the board. They did some PoCs, Design Sessions, A/B testing and many refactorings. After a few months, a manager knocks at the door and asks the question: Why is this taking so long?

This is a very common scenario that I will shorten to:

  • They assumed the experience was right since the beginning – unconsciously or taking the risk.
  • Reacting to change when we are manoeuvring an Aircraft carrier is much slower and riskier than doing it in a small boat.

Learning essentially from the feedback we collect when releasing product leads often to technical waste, a misfit product and a demotivated team.

2) What Dual-Track is

Dual-Track is an approach in software development that assumes the existence of two key tracks: the Discovery Track and the Delivery Track

Please follow to Jeff Patton’s page, the co-creator and advocate of this approach that explained it far better what is and its characteristics. The key points are:

  • Development work focuses on predictability and quality
  • Discovery work focuses on fast learning and validation
  • Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking
  • Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
  • If we’re doing discovery right, we substantially change and kill lots of ideas.
  • While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.
  • Keep measuring and learning even after you ship.

Product Discovery is focused on answer questions, to test ideas, and to avoid wasting time over-investing in quality stuff we shouldn’t have built in the first place.

3) Setting the ground

Last year we had teams starting to work in Dual-Track, meaning, they had a specific plan and tasks for Discovery (running hypothesis, interviews, etc) and other specific tasks for coding and ship a potential release. During this period, we had coaching from Teresa Torres on how to run Continuous Discovery and using the Opportunity-Solution Tree to map all the experiments and opportunities to a desired and known outcome. If you don’t know this tree I strongly encourage you to follow to this ProductTalk link. But be careful, it might change the way you are visualising your workspace.

We changed our team’s composition to ensure they all were comprised with all the skill set they need to be autonomous in 1) finding the top problems 2) build a usable, performant, and secure solution and 3) releasing it to the customer. Since we were hypothesis-driven we also aimed to be outcome-oriented, instead of thinking first what features to build. For instance, 1) identify an outcome like Increase the Adoption rate from 100k to 200k in 6 months time and 2) discover what are features that will take us there.

Doing Product Discovery brings up three concepts.

1) We start by discovering and explicit our Assumption, something we believe is true without proof.

2) Then we formulate experiments to test assumptions or hypothesis. An experiment is a procedure designed to test a hypothesis composed by a success criteria and, sometimes, a time duration.

3) Opportunity is a problem we solve, a wish from the customer we satisfy that will lead us to achieve a certain outcome.

A simple example: I ran into a possible opportunity after 2 customers telling me they need the integration ABC on our platform. However, they are only few customers out of a universe of thousands. And the integration is quite expensive to do. My gut feeling tells me more customers would want it too, but only I have is an assumption that our customers want the integration ABC. Before start doing heavy technical research I will run a very simple experiment. I will put a small but engaging text on our homepage informing that by next year we may have it, together with a “More Info” button. If in 1 month time we count 1000 clicks that will mean the topic is relevant. Then I will have data that will tell me is safe to continue investing in this Opportunity. It not, I will put it on hold for now and go to the next Opportunity.

4) Dual-Track, Different Problems

The future looked bright and right. Mapping the problem space looking for problems, identify the features that generate the value we want to achieve, validating the assumptions prior to coding a single line of text brought us unforeseen problems though.

Hard and Slow Decision Making. Everything needed Discovery. The team started to over analysing almost everything before any development. Even the no-brainers. They wanted to have solid evidence to support all their decisions. This caused in having too many data pointers to analyse, process, debrief and act upon leading. Very frequently the development was on idle, waiting until a decision was made. There were cases of some teams writing their first line of code after months of Discovery. To worsen, the PX and PM were working together and when they decided what to tackle, they passed it to the Dev team for technical validation. It turned out to not be feasible and a new iteration was starting. We lost our ability to follow that gut feeling upon known territory.

Discovery insights were not actionable. It’s very frustrating to realize after weeks of work that our data is not representative or totally biased just by the way we run interviews.

Duel-Teams. The Dual-Track name itself may infer the existence of two teams that work separately and therefore, making hard the management of these two mindsets. Dual-Track induced an imaginary boundary in the team. There are “They, the PX and PM” that are responsible to find the problem and the “We, the developers” that only want to make it right. When things were not unfolding as expected, finger pointing happened and the team unity to fell apart. Managers and PMs were complaining coding was taking too long to be released and developers accused having the opportunities and requirements late.

The Problem Space was too big. When the initial problem or team’s mission is big everything next will multiply. The number of problems to consider, the number of possible solutions with all their pros and cons to be evaluated. Adding to this, the absence of a metric to anchor a decision caused a constant back and forth on a direction.

5) Helpers for better Discovery

We know the ultimate and best learning is when realising product – period. But we want to do that only when we have higher confidence on what to do. There are two scenarios. 1) If it’s a known territory with pieces of evidence we don’t need to invest hard in validating assumptions prior coding and 2) if we are starting to address a problem or a solution relatively new to the team, it’s recommended that we learn and fail fast and cheap – typically this happens not by coding.

Rather than following a single ready-to-adopt operational model – that by the way does not exist – I will share some behaviours that were collected from our learnings.

Identify the MVP. It’s very easy for a team to get lost in its discovery. It’s crucial to find what we want to validate as it will enforce every single thing the team is doing is aligned to a clear and specific goal. Race to build a minimum wow-working-product to put at the hands of your customer. The wow factor is important as you want to make it desirable for your customer to buy, to give something he may not be expecting. Make it small and containing the minimum working functionality for you to decide out of 1) reinforce the strategy in place 2) pivot the strategy but keeping the goal or 3) drop the initiative since the customer may want something else. Ideally, this cannot take more than 6 months.

Plan for uncertainty. Expect the plan will change as new information will be incorporated along with the project. Manage the expectations of everyone involved that what today’s is true, tomorrow may not be. Avoid having specific and detailed time-bounded projections for further than 3 months. It’s not only a waste of your time as you are putting an expectation on everyone’s head, even if they tell you otherwise.

Imagine that you estimate to deliver your MVP in 6 months time. You are starting from a white paper. Forecast 5 monthly outcomes or objectives to review your plan at the end of every month and sense and adapt from that point onwards.

Having a route in place with well-known checkpoints will allow you to evaluate progress, sense and adapt your strategy.

Have a right-to-left approach. Start with the end in mind, forces you to think first on the intended impact and then on the backlog and features. This ensures your work is meaningful and that every feature, experiment, learning and coding is mapped into a monthly outcome (if you are using those). This way you avoid creating much unwanted and useless backlog. Something almost magical happens when you organize and focus your creative power on a close and well-defined target. More details on Mike Burrows website.

Plan your work for a given cycle. A team should never lose an opportunity to launch small increments and keep their customers in the loop, making them craving on what will come at the end of the week. Everything a team does should be assigned to a known release. Especially the experiments so you ensure they are actionable, time bounded and under a feasible WIP.

We can’t afford to have to get feedback from a working-product after months. We need cadence with shorter feedback loops.

Having a cadence helps also in managing dependencies with other teams, control the project execution and avoid useless alignment meetings. Habituate your stakeholders for project execution and debriefs at the end of the month only. You will come to them if needed.

Have a good understanding of the problem before jumping into a solution. How many times did you fail to solve a problem that either didn’t exist or wasn’t the root cause? There was a case of a team that was improving the UX of a 3 years feature thinking that was the cause of low adoption. After the new revamp and an unchanged adoption rate they discovered the problem was on the low visibility of the shortcut on the homepage. Invest time knowing exactly what is the use-case you are solving, ideally seeing the customers operating it in the system. You will realize that the solution will be smaller.

Work a few experiments at a time. Since we cannot validate all our assumptions choose your experiments wise. Prioritize only the high-risk and hard to rollback. And then, find ways to validate things fast (hours, days) and cheap (mockups, conversations, focus group).

Everything a team does should follow an over-simplified circle of build+measure+learn. Time and resources are not elastic, and when we are dealing with many experiments we start to skip either the measure or the learning. We become a factory with a series of features that are not evolving, that we don’t know its impact and that most likely are increasing the load of stuff we need to handle. It takes courage to choose lesser features.

Take decisions with the best data you have. Many of us place equal value on almost every decision. Why? We don’t want to be wrong. Ever. Be good at recognizing patterns. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.

Be fast in deciding what is relatively easy to rollback. Being wrong is the opposite of failing. It moves an idea forward.

Build a team of grown-ups. ‘Grown-up’ is a shorthand for the kind of person, the kind of attitude that exhibit personal behaviours required to create high-performing such as self-discipline and accountability. This means that the team will be disciplined in adjusting their understanding, in managing the expectation of the stakeholders, in sensing and adapt the plan frequently. It’s very easy to disconnect the dots from what we a doing now with the overall picture. Doing recurrent revisions – integrated in the Planning sessions for instance – you will find a higher alignment while avoiding, again, useful meetings. To maintain everyone on the same page it’s key to have few but trustworthy artefacts, like a High-Level Delivery Plan, where we get answers to questions like a) what it’s planned to be released next, b) what is the high-level delivery plan or 3) what is the MVP question we want to answer.

It will mean also that you will scale whenever you are in a deadlock for making a decision. Whenever you need an unbiased facilitator because there is trouble solving a conflict. Whenever you think you are running an unfit process. Every time you feel you are not autonomous or have the ability to move forward something that it halted for some time.

Experiment with new ways of working together. Don’t assume what worked well with your team until today will work when adding Discovery Work. You need to understand if it works better a single planning, a single backlog or to have it separated for Discovery and Delivery. Don’t take it lightly. This decision will have a tremendous impact on the way the team will behave

Take decisions process-wise, experiment something new every working iteration, inspect and adapt. Keep practising, this is a muscle.

6) Takeaways

I’ve realized that I’m trying to avoid saying Dual-Track and instead remember people that all we want is to Build a Product while doing Fast Discovery so we mitigate the risk of delivering something that is wrong. Simple and away of the possible misuse of the designations.

It’s everyone responsibility to find the fastest and cheapest way possible to validate something before you at a point where is hard to react to change. It’s not a one person thing. However, it’s a utopia saying there is an equal level of responsibility within the team. It’s not and pretend there is leads often to frustration, no-decision making and no learning. There will be a time when someone needs to call off a decision. To scale. Everyone contributes but under clear governance of responsibility distributed between the PM, PX and Devs. If you don’t know it, take one hour with everyone to have it clear.

If there is something I would like you to keep is this.

  • Discovery is no longer optional. Validate the problem first, optimize later so you go to hard-coding with low risk of a misfit or taking too long.
  • Do Extensive Discovery when you don’t know anything. If you are working on a solid ground of understanding follow your gut feeling, find solid data in the knowledge you have.
  • Be intentional in your experiments. They should be actionable, time-boxed with a clear question to be answered. Less is more indeed.
  • MVP cannot be longer than 6 months. Discover only the information you need to gain confidence before developing code. If you are confident enough, start coding. We want to release a working Product, not doing mockups only. But we need the interviews and mockups to narrow down the options. Remember always that.
  • Work in Cadence. It’s crucial for keeping the customer interest, constant feedback flow-in, measure progress and have better alignments on tactical dependencies. Tie everything you do to a given Release Cycle.
  • Sense and Adapt your plan frequently. Have the best plan with today’s information and updated upon new findings. Working with uncertainty won’t discard planning. Do it light, smart so you tell a story from where you are today until the end of the project.
  • Be a team of grow-ups. Be disciplined in following your team’s agreements, be methodic in your continuous improvement, ensure everyone in the team knows to get the answer to key questions like What is the MVP question we want to answer.