Product Discovery in the Multitrack of Madness
Figuring out “Dual Track” with 3 layer Continuous Discovery
While building great products, how to balance Discovery and Delivery in a daily basis?
Every product team and every product organization I know is trying to figure this out. Some of them have some form of Continuous Discovery going on, a big part of them are looking for a way to start doing it and all of them are trying to find the perfect balance between Discovery and Delivery.
Why is everyone working on this? Because it is probably the one thing that can have most impact on your product’s chances of success. It is the key to being customer centric (efficiently). Considering you already have a product culture in place, this is where you find operational excellency and where products teams find their flow.
[Spoiler Alert] It’s a never ending quest, and that is a good thing! That perfect balance will shift while your product, your market and your team evolves. Personally I find this topic one of the most exciting parts of my job as a product leader.
Before we continue…
I’m assuming you are familiar with some concepts and that, somehow, you have already figured out Delivery with some flavor of Agile methodology. Delivery has matured over the last couple of decades and I think it is safe to consider it a standard. Even teams that are struggling to adopt these practices have a clear picture of what good delivery should look like.
I’m writing this article from a point where Delivery is no longer a problem and Continuous Discovery is either a reality or a goal. My focus will be on how to find balance between Discovery and Deliver on a daily basis.
There is a lot of good material available on these concepts, written by the top references in Product today. So if you’re new to Dual Track or Continuous Discovery I strongly suggest you to read what Marty Cagan, Jeff Patton, Teresa Torres and Melissa Perri say about this, before you continue.
Moving on…
As a visual person myself, I’m always trying to come up with representation models of concepts and processes adopted by our product teams. I find it’s very useful for alignment with everybody involved: product teams, c-level, engineering leaders, other areas directly impacted by the process - pretty much the whole organization.
I really like Marty Cagan’s model for Dual Track. It’s elegant in its purposeful simplicity, and it captures the overall concept: product teams must run discovery and delivery at the same time (in parallel) and continuously.
Jeff Patton also did a great job with his model, detailing a bit more what happens in each track.
But they (and all others I’ve seen) fail to express the real complexity of working Continuous Discovery and Delivery day by day. What happens in each track? How do tracks interact? When to validate each risk (value, usability, feasibility, business viability) associated with an idea? What to do when Discovery demands coding? How to avoid the trap of creating a sophisticated waterfall process?
Being such a visual person, I wanted a model that could explain to others the way I see Dual Track working on a daily basis. Among these attempts, I came up with this.
Basically, I see the Discovery track happening in 3 different layers (or sub-tracks). In essence, they are all discovery. But each one involves tasks of different natures that requires different skills from Product Managers, Product Designers and the rest of the product team (engineers included). They also differ in task frequency and investment (time). And the balance between them has direct impact on ROI (return over investments).
Opportunity layer
In this layer, the product team (mostly the PM) is constantly looking for opportunities to evolve the product and achieve the desired outcomes. An unsolved problem, a customer need, a colleague pain, a new way your product changed someones life. The possibilities are unlimited, and the opportunities will pop up if you look at the right places.
From the opportunities on, the product team comes up with ideas to evolve the product, in the form of hypothesis: if we build X (feature), people will do Y (behavior) and we will get Z (results), leading us to the desired outcomes.
I can’t stress well enough the fact that leaders and product teams should focus on results over features. For me, this is the number one principle of any product culture. If you haven’t already, I strongly recommend you to read Joshua Seiden’s book on that matter: Outcomes over Output. It has recently entered my list of mandatory books for product people.
I also recommend you to write down and present your ideas in the form of hypothesis, so that you make clear that your commitment is to the result and that the feature is merely a possible way of getting there.
Teresa Torres created a great framework to organize ideas and hypothesis: Opportunity Solution Tree. You should check it out.
For example: if one of your goals is to increase conversion rate and you’ve seen through data that people who read the product’s newsletter convert better, that’s an opportunity! An idea to act on that opportunity might be to create a hot site nudging people to sign up for the newsletter.
In this simple example, your hypothesis would be something like this:
We are going to build a hot site with a signup call to action (feature). By doing that, we believe 30% more people will receive and read our newsletter every week (desired behavior). Data shows people convert more when they read our newsletter, and so by building this hot site, we expect to get a 10% higher conversion rate (desired outcome).
Most ideas will be incremental - things you can do to promote improvements on the product. These can be small, medium or even big things to build, but they won’t change the course of the product or the organization. Don’t get me wrong, incremental ideas are crucial for sustaining and growing businesses. And frequently, it is worth to invest a lot in order to get a small increase in a KPI.
But the real gold are in those game changing ideas that appear every now and then. I believe you should always be looking for opportunities to evolve your product in ways that will make it 10x better. This kind of opportunity may come from customer feedback, from other areas of the organization, from new technologies (or new forms to apply old ones) or, more likely, from the product team while compiling all those inputs.
If you have clear objectives and the discipline to look constantly for opportunities, a lot of ideas will come up and they will fuel the other layers of Discovery.
Considering product teams know where they want to get to (clear objectives), I encourage them, especially PMs, to look for opportunities by doing these 5 things:
- Analyse usage data daily — how are customers interacting with your product? How are your latests ideas (hypothesis) performing?
- Talk to customers weekly (at least one customer per week) — find out how your product is impacting their lives. When and why do they use your product?
- Talk to people from different areas of the organization weekly (at least one area per week) — how do they see the product and the market you're in?
- Study your product’s market biweekly — what is the market share for the main players? Is there any new player? What are the differentials?
- Study the technologies your product uses biweekly — what is the adoption rate of the technology (are people jumping in or abandoning it)? Is it being used to solve problems in new ways you haven’t seen before?
I know some times it feels like the world is on fire (and some times it actually is) and you’re so focused on delivering the next big thing that you can’t just invest the time and look at data or talk to a customer. But if you put these activities in your schedule and have the discipline to do it, in a few months the evolution rate of your product will improve consistently and you’ll get better results. Think about it as brushing your teeth: no matter how crazy your day was, you will find some time to do it.
There is a common misconception about the way ideas come to us. We don’t just come up with an idea out of the blue, in an epiphany moment. Our unconscious processes information and emotions (in ways we can’t yet fully understand) and create thoughts that, after taking form, emerges to our consciousness as ideas.
In order to have good ideas and create meaningful hypothesis, you need to constantly feed your brain with the right info and give yourself time to make sense of all that.
Reflection time is also crucial for having ideas with high impact potential.
If you're interested, there are a lot of good books on this topic. I really like Leonard Mlodinow’s Subliminal, it is an accessible and fun reading.
Value and Business Viability layer
So now you’ve come up with an idea, a well formed hypothesis of changing the product so that it will produce the desired outcome. Let’s put it to test!
Perhaps the most straight forward approach would be to build it, ship it and see what happens, right? You did your discovery, now deliver it! Well, if only things were always that simple. At some point, this approach could shut down your organization, cause a massive abandon of your product, or have you spending a lot of time and money building something nobody will use.
Hypothesis are built on assumptions, and by nature they can be proved wrong. We expect users to behave in a certain way after we launch a feature, but we must think about other scenarios and things that could go wrong. Hope for the best and plan for the worse!
Before building and shipping a new feature, product teams must check if it has potential to hurt the business, if it fits business necessities (for financial, sales, marketing, legal, etc) and if users will see value on it, and actually use it and pay for it.
Validating business viability is usually the easy part. Most of the time, product teams have a good understanding of their business and can map the impacts and risks associated with an idea by themselves. So all they need to do is validate it with involved teams and stakeholders. Sometimes, a quick informal meeting is enough. Other times, it may take several interactions with other teams and even external stakeholders, such as business partners or suppliers.
A piece of advice: no matter how confident you are, always validate risks with involved teams and stakeholders. Small but meaningful risks sometimes can only be seen by specialists.
I always ask product teams to materialize the idea in some visual way. It makes things a lot easier for people who may not know the product that well, and increases the engagement of other teams. It can be a simple workflow, a service blueprint, a user story map or mockups. For more complex ideas or new products, I like to write a Press Release, as in the working backwards technique championed by Amazon.
The best tool to use in this phase is the one your colleagues will better understand. The goal here is to validate this as soon (and with less effort) as possible.
Now validating value, that's a whole 'nother story! Just because someone can use your product, it doesn't mean they will choose to use your product.
In order to test if people are willing to use it (and pay for it), you need to actually put something in front of them and see what happens. But that doesn't mean building the feature yet!
Presenting the new concept to a reference customer and inviting some users to talk about the problem you’re trying to solve are great ways of validating value. These conversations can bring a lot of insights on how people will perceive the new feature.
Sometimes it also makes sense to go with a more practical approach. You can put out a landing page, for example, collecting leads to test the demand for a new product. Or a fake button on a page to test the interest in a new feature. You can run a Concierge or a Wizard of Oz MVP. A lot of these tests can even be done without engineering effort, as I've written in the past in this article: 5 free tools to build your MVP/RAT without coding.
There are a lot of ways to validate value by talking to customers and prototyping, but sometimes it requires the product team to actually code something and ship it. Call it a functional prototype, a MVP or whatever your stakeholders can better understand. The fact is, sometimes, you’ll need to run a Delivery track inside your Discovery track.
Now this is where things get messy and it really becomes the multitrack of madness (just in case you didn’t get that geek reference).
So you need to ship some code, no big deal, right? The team knows how to run an efficient delivery track. The problem is this can’t be an ordinary delivery track. The focus here must be on learning (as fast and cheap as possible) rather than on scalability and sustainability. And I find a lot of engineers struggling to live with that duality: there are times for clean code and times for fast/cheap code.
I think by now you've already realized why would you want fast and cheap code, right?
This is the kill zone, where probably most ideas will be killed or significantly modified.
This means that the code delivered will bring learnings, but it will likely be thrown away afterwards.
The same goes for product designers. You want to invest as little as possible in order to validate value and business viability. It might require high fidelity prototypes, but it rarely requires sophisticated design or much usability tests.
The final and definitive test will always be shipping the actual feature and measuring results. But you can (and should) optimize your investments by testing assumptions before putting a lot of time and money on an idea.
You know that you will never be 100% sure about how things will roll out. So, how much time should you invest in validating this risks (value and business viability)? Just enough!
This fine tuning (of how much to invest in this layer) is directly related to the product team’s maturity. Teams that owns deep understanding of the product, the market and the consumers, get really efficient at this and consequently get better results.
I like to use the Cynefin Framework to help assessing the level of investment in discovery required for each idea.
The main idea of this framework is that not all situations are equal, so they require different responses. The model helps to categorize the situation, to have a sense of place and to define which response is required.
Obvious ideas requires little or no discovery at all. For example: implementing development best practices so a mobile web page loads in less than 3 seconds to reduce abandon rate in a navigation flow. There are plenty of evidence out there to support this cause and effect relationship.
Complicated ideas require some discovery, but a workflow, interviews and meetings might be enough. Complex and Chaotic ideas will probably require prototypes, experimentation and a MVP.
So once you have just enough evidence pointing that consumers will see value, and that this change won’t hurt the business, you’re clear to move on.
Usability layer
When other risks are addressed and the product team is confident this idea is worth building, they must walk that extra mile to help people figure out how to use it.
You’ve found the right thing to build, this is the first step on building it right.
I imagine you want a frictionless experience, with an intuitive interface (who doesn’t?), but what does that actually means to your target audience? This layer basically consists on prototyping and running usability tests as many times as needed.
You might have already done some of this in Value and Business Viability layer. A lot of times it’s necessary to validate value, but I believe you should postpone this investment as much as possible. This way, when you kill or significantly change an idea on that layer, you‘d have learned with less investment, improving ROI.
As in the previous layer, good enough is enough! You’ll never get it 100% right, the final usability test will always be with massive production usage, and you will iterate on it. So try to find the balance and adjust investments in this layer also. Do run at least a couple of usability tests, but do it as quickly as possible and know when to stop.
Ideations techniques from Design Thinking are a great place to start. If the materialization of the idea on Value and Business Viability layer didn’t got to this point, you can use Crazy 8, for example, to jump start this layer. There are a lot of fun ways to come up with the first version of your prototype and I’m sure your UX/Product Designer will love to tell you all about them.
With the first version of the prototype ready I usually recommend to product teams they do at least a Design Critique Session and two rounds of Guerrilla Usability Tests.
The Design Critique Session will help you leverage on learnings from other initiatives and make sure you’re respecting Design Principles. The first run of Guerrilla Usability Test usually reveals basic mistakes on the design, the ones you may feel a little ashamed they even came up. But that is totally ok! That’s what the test is for. The team works on the prototype and go for the second round. This time you should run into more difficult decisions and some ambiguous results. This is a good time to design A/B Tests and to set metrics to look out for when the new version goes live.
Whatever techniques you decide to use, the key thing here is to do it as quickly as possible! Learning velocity equals efficiency and ROI. This talk by Tom Chi about Rapid Prototyping gave me a lot of insights on this.
It goes without saying that engineers must participate actively in this phase of discovery! It is crucial that you validate feasibility along side with usability. To quote Marty Cagan: “If the first time your developers see an idea is at sprint planning, you have failed”.
Once again, a product team’s maturity can be defined by how efficient they are on this layer of discovery. How well they can evaluate usability risks and decide how much to invest in this phase. The best product teams know their stakeholders, their product and market so well that they’ll invest the exact amount of time and resources to get the best overall result.
Maintaining consistency and working with standards can save you some precious time in this layer. If you’re replicating patterns people already know how to use, you can safely invest less in usability testing. A design system seems to come in handy in this matter.
Quick recap
Break down Discovery in 3 layers to navigate the Multitrack of Madness and run continuous Discovery and Delivery on a daily basis!
Opportunity: Constantly look for incremental and game changing ideas by looking at data daily, talking to customers and other areas of the organization weekly, and studying your tech and your market biweekly.
Value and Business Viability: Validate if customers will see value in it and if it fits business necessities by materializing the idea, building MVPs and walking trough it with stakeholders to test yours riskiest assumptions (investing as little as possible).
Usability: Walk the extra mile to help people figure out how to use it by prototyping and running usability tests (as quickly as possible).
After going through these 3 layers of Discovery, the idea is ready to enter the Delivery track. I can easily see this working in teams running Scrum or any other Agile methodology. But in my experience, Kanban gives discovery more flexibility when there is need to build MVPs or ship some code focused on learning velocity.
So these are my thoughts on how to run Dual Track with continuous Discovery and Delivery on a daily basis. Thank you for reading and please contact me if you’d like to talk more about this. I enjoy the topic a lot and would love to hear other opinions on it.
