Design sprint meets Dual Track
How we took ideas from the famous methodology from Jake Knapp and Jeff Patton and made something work for our team.
Back when I was at 11:FS Foundry, our team was very much focused on delivery. We were building a Banking-as-a-Service platform (BaaS), had a lot of competitors, and "feature parity" was a thing.
I was hired to help build out the product team and support in developing a strong product practice. This meant challenging the status quo.
As a startup within a startup, a lot of what you're trying to do is proving value early on. This means shipping things quickly. Things clients expect. They were very large banks with potentially sizeable contracts. Like in many companies, we had a lot of features to build and time was of the essence.
We get delivery pace. But what about pace of learning?
The one thing that bothered Ed (my Product Design peer) and I, was that we didn't have the confidence level we needed to move forward at pace. This was largely due to a critical mass of people assuming that financial products that existed were very well understood (everyone knows what a consumer loan is, right?) and that all we needed to do was replicate these.
We were lucky to have some of the most friendly and collaborative clients to work with. Ed and I would go to Oslo every 2-3 weeks to meet with them and flesh things out, both from a business and technical perspective.
Following each Norwegian trip, we would realise that the strategic and operational context shared with us was critical in helping our decision-making and prioritisation. But we were tackling huge problems with a lot of intricacies.
Building a complex product often means development cycles and feedback loops are long. We wanted to change that by breaking down problems into digestible chunks we could absorb in 2-week sprints.
Ingredients for learning at pace...
We realised we needed to make these learning cycles more of a habit and got together to develop an action plan.
At this point, Ed mentioned designed sprints and I recalled reading this article about Dual Track.
Organically, our stance was that we could take what we thought would work well from each methodology and make our own recipe for discovery cycles that were short and sweet. 🍰
So we pulled the team together and asked whether they thought this was possible.
Our position was that we wanted to try a new way of doing things and worst case we could always give it another try.
A recipe for weekly insights and robust product decisioning.
One workshop later, we had the early version of what our iteration cycle would look like.
Like James Clear effectively explains in his book Atomic Habits, a lot of performance can be gained if we practice on a regular basis.
A couple of iterations in, we developed the weekly schedule above.
Using the method and cadence outlined here means we are infusing all our day-to-day product decisions based on the reality of our customers.
Hypothesis planning & prioritisation - this was a key moment for us as a product team. We would come together and share things we wanted to uncover in the form of hypotheses, assumptions or riskiest assumption tests.
This event is led by the product manager who brings
User interview slots - we found that users will happily book time if they can balance availability, predictability.
These events are led by the product designer and/or a user researcher.
Analysis & synthesis - this can be entirely owned by the design or research team. However, if you're operating in a small bootstrapped.
This event is led by the product designer and/or a user researcher.
Weekly playback - a great team huddle where we get to share what we have learnt and also build upon the different experiences across the people involved.
This event is led by the product designer and/or a user researcher.
It can be daunting at first, specially as we have to plan for this new set of activities. However, I have found that prioritising tasks against customer-led initiatives is relatively easy. I would recommend you do the same: have a hard look at your calendar and start prioritising activities which are going to give you more confidence in your decision-making, i.e. activities where you learn from your customers and derive elements of proof you can rally your team and stakeholders around.
Mind the gap...in problem sizes.
One of the reasons why the approach described above worked was that the size of the problems we were trying to address worked out within a week's activities.
Of course you'll want to tackle larger problems, but my advice would be:
- Break down your problem into smaller chunks.
Using story mapping and assumption mapping can be very helpful here. - Larger, more complex and exploratory topics can be tackled in parallel on longer cycles.
It is important for the team to be intentional about how they impact their business and product outcomes through discovery activities and evidence gathered.