The thing about a framework is that as soon as you feel you’ve got a visual model nailed down, another idea or critique comes to mind and five minutes later you’ve got a newer version (case in point: I’ve updated this image six times since starting this blog post).
Well, this is me attempting to make a cut and release into the wild for feedback, thoughts, and with luck, possibly even helping you and your organisation out too.
So… what is this anyway?
Well, you might immediately recognise this as little more than a simplified, visual mashup of the Double Diamond design process followed by a Build-Measure-Learn development loop before going into an overly lightweight representation of delivering the solution to market with measurements that kick it all off once again - and, that’s pretty much what it is.
I’ll explain more about the diagram in a minute (as I’m sure the questions and concerns are reaching a boil already haha), but first, the context…
What I needed was a way to illustrate to our large transformation programme what a chunky initial discovery effort all the way to a delivery and release process might look like for squads taking on big pieces of work as we look to replace the old product and service experiences with the new. There are heaps of books, articles, and infographics already available that more thoroughly break down or propose similar approaches, but I felt that we needed something more abstract and easier to digest (with somewhat less jargon) to help us introduce our design and development teams the insights to outcomes flow we’re looking to run in practice.
And thus, here we are.
This diagram doesn’t sit alone on our programme’s “ways of working” pages either; it’s backed up with a collaboratively written guide of its own that breaks down the specific team activities and outputs expected in each stage.
So, while I am not going to copy and paste all that we’ve been sharing internally to guide our teams in our own context of work, what I can give you is more of the overview and intention behind this visual that might help inform one of your own.
First, a high-level view of the stages:
Discover - Despite being only appearing as one half of a ‘diverging’ diamond, the most generative and influential research begins here, especially when it’s a team’s first foray into less explored territory. Go broad to uncover pain points and opportunities not only from your customers, but from your frontline teams, competitors, on-going Voice of Customer sentiments, past research, and more.
If a team is coming back around to ‘Discovery’ after making a release, the up-front research is likely to be more targeted around what wasn’t working so well from that last release or may be focused on capturing more information needed to flesh out the next backlog item for the next release.
Define - With the problem and opportunity space now known, it’s time for the squads to narrow down and align on which problems they want to solve this go-round - since this is a cyclical, end-to-end process, this shouldn’t be their one and only time to do good work and improve the experience compared to what it is today. Consider early ideation and refinement here on what your end-to-end, target customer journey(s) and support services might look like for both the digital and non-digital channels as this will help guide the work in the following stages.
To note, it is OK to not pursue a problem or solution too, especially if the solution is at the expense of people not ‘seen’ nor desired (ie. capitalistic colonisation - which is not my place to speak on, only to learn from and share).
Design - Ahh the next meaty chunk where the real ‘solutioning’ begins. Experiment on and prototype out many different ways to enable the outcomes identified in the target customer journey(s) and service - reviewing, testing, and informing these designs along the way. Eventually teams will need to come to a decision of which direction to take the designs and service down, so begin narrowing in on what to bring into build and process definition. Bring in even more customers and stakeholders for participatory review and refinement.
Develop - Keeping in mind that “development and delivery is the most expensive way to test new ideas”, teams can start building out the actual customer or internal user touchpoints as soon as at least one component, screen, process, or ‘piece’ of the target experience once confidence is higher that the risk of avoidable design or development rework is low. Review and test whether each new piece ‘completed’ meets the success criteria previously defined (eg. is usable, is accessible, is desirable, is valuable, etc), reflect on what should be tweaked or discarded, and iteratively repeat until the end-to-end experience and supporting processes and platforms are ready for release.
Delivery - The final countdown begins as all of the go-to-market actions kick into gear, from change management execution to marketing campaigns - the end result being a product or service available in the market that’s supported by the business. But, this is not a one-and-done process by any means! Now that you’ve gone live, setup triggers and tests to identify what the next most important pain point or opportunity is, and restart the process!
Now that I’ve explained the model’s stages in far more words than I had set out to write (if this is your first time reading my work, welcome to the stream-of-conscious channel 😵), I want to call attention to the design-centric nature that this model tends to convey and acknowledge that this was intentional.
Too often have I myself seen teams rushed, for one reason or another, into churning out the first idea and iteration of a feature that comes to mind. My hope is that by reiterating the need for alignment, sense checking, and seeking influential feedback throughout the process, once your teams get into the heat of development, their questions and concerns will be more about how best to make something work for the customer rather than why they’re doing it or whether this is the thing needed at this time.
The more you understand at the beginning, the less you have to debate towards the end.
This isn’t a strictly linear process either; this diagram of mine merely intends to express the ebbs and flows of our understanding of the problems and implementation opportunities at hand through to production. Teams can start at whichever stage and stay in whichever stage as long as they need to achieve their objectives.
I do not expect this model to be a cut-and-dry framework that can be seamlessly lifted and shifted into any team’s lap; this conceptual flow was created for our programme in our current context of work - a week from now we might have already found a better way to communicate our intentions, but what matters is if it helps aligns teams today.
Each organisational culture and business strategy creates unique challenges and constraints that teams need to adapt to, but if you do happen to find yourself in a similar situation where you’re looking for a way to communicate a discovery to delivery process at scale, then start here and shape it to your needs.
…and let me know how it goes!
Addendums:
This conceptual flow model should not dictate that you follow an Agile, waterfall, or other approach - each of these stages can be as big or small as needed, run in parallel with multiple scrum teams each on their own track, you name it.
I also don't see a reason why you couldn't follow a 'Design Thinking' iterative approach either in some of these stages like Discover and Define if it helps you to think about it that way.
The overall point of the first half of this, and why I like the double diamond, is all about encouraging teams to not take the first idea or problem they see and run with it; expand out, think broader, look deeper, experiment more, and then get specific on what path you want to pursue.