Jun 20, 2017 · Anthony Boobier
There is a lot of talk right now about how agile product delivery teams should take ownership of customer discovery work, alongside their development activities. This is otherwise known as ‘dual-track development’ and is described in Jeff Patton’s excellent article
In this blog I want to talk through how we have explained and approached it with teams, by identifying categories of work.
Discovery and Development are two types of work that require two types of thinking. Jeff Patton visualizes them being carried out in parallel, as two tracks:
The pattern here is empiricism; rapid cycles of Build-Measure-Learn, by which we look to minimize the learning loop to deliver valuable outcomes to our customers. It’s important we make sure we build the right thing, rather than wasting our efforts efficiently building the wrong thing. To ensure that, we need to minimize the learning loop; but to do it should we build a feature, wireframe, data query or a customer questionnaire?
This is where experiments come in, to (in)validate our assumptions on what the customer actually wants, or needs. Discovery’ and Development tracks both follow this empirical feedback loop and happen in parallel. The key focus of Discovery work is to maximize the speed of learning to test those assumptions.
To help work out what these experiments might look like, and whether they are focused more ‘Discovery’ or ‘Development’, I have found it useful to split them into the following 4 high level categories:
- Talk to a customer (or a user) - This is probably the simplest thing you can do, so simple that all too often we don’t bother. This still requires structure and for us to build a questionnaire or survey.
- Prototype something - That could be a lo or Hi fidelity prototype; a paper prototype or maybe some working software and screen flow. It also includes technical spikes, to reduce doubt and risk.
- Gather some data - Maybe it’s getting hold of some data we already collect, but slicing and dicing it in a way to get us some new information of insights. It could be that we don’t collect that data yet, so maybe we need to release to production, so we can start to collate it. It could also be that we review an existing process, e.g. walk through a registration flow as if we were the customer.
- Put it in production - This is the core of ‘Development’, with an emphasis on production quality. It therefore (generally) the riskiest and most expensive approach, so we want to make sure it’s worth the punt. There are exceptions, small minimum experiments we can deploy to production in a timely fashion, and then learn from.
These 4 categories also help determine who on the product delivery team may be leading, or involved, in an experiment. For instance, if it’s ‘Talk to a customer’ we might want to engage a UX researcher to help formulate a survey.
Speed of Learning vs Value to the customer
The trick is working out which of these categories to use when; whether you want to focus more on speed of learning, or focus on delivering value to a customer
Delivery work although bringing value and outcomes to the customer, has a higher associated cost of learning. That’s why it important to undertake Discovery work, to ensure our assumptions are (in)validated before we invest in Development. These categories map out as below, (although it is anything but an exact science!):
It’s about knowing when to pick a category of work which may focus more on (It’s important to caveat the second axis of ‘Value to customer’, because there is a higher cost associated with delivering it):
Speed of Learning
Value to Customer (and higher cost of learning)
Dual track development is more about the type of work and experiments you are undertaking as a team. These experiments all follow an empirical feedback loop, the only difference is the time taken to complete the loop. The objective is to maximize learning and delivery velocity. Dual track is about doing these things in tandem. It is about selecting (and balancing) work that maximizes the speed of learning, with the speed of delivering value to our customers.
Categories: Product Development.
Tags: Lean UX.