Our Principal Solution Architect, Adam Jackson, provides insight into Zone’s “Accelerator” model — a rapid ideation and validation framework — for our consulting practices from diagnoses to delivery planning.
Today I wanted to give some insight into our rapid ideation and validation framework as part of our consulting practices at Zone. These are shorter engagements with a focused team that works closely with client stakeholders.
Over the last two years, I have worked on a wide range of topics and industries from applications supporting the conversion of diesel fleets to EV, customer voice programs, and new business propositions to developing devOps process monitoring tools. The variation in a project context and the opportunity to learn about new industries and practices make these very enjoyable engagements.
As an individual, you need to be comfortable with ambiguity, and that is something I relish because it gives you scope to impact an organisation with meaningful change. I have found that with each engagement, the whole team (including stakeholders) goes through a journey of discovery. We continually evolve and evaluate our understanding of the problem space and the suitable solutions. Turning this kind of inward lens on an organisation often leads to the discovery of items in addition to the original scope, that could positively impact an organisation and their products/services. This doesn’t necessarily mean major change or something new; often, small tweaks to existing implementations or processes can be just as impactful.
Our accelerators are a combination of customer-centric design principles, agnostic approach to ideation and solutionism, agile practice, and elements of a lean startup framework.
We have a wide range of MVE (minimum viable experiment) approaches, including interviews, workshops, analysis, journey mapping, service blueprints, etc. We emphasise value measurement through frameworks such as North star by starting with a vision statement, breaking that down into measurable components and levers, using these to help guide decision making and evaluation of success.
The accelerators tend to operate in distinct phases. Below I outline what to expect, the outputs and any strategies I have found helpful.
Phase 1: Diagnose
Ahead of the engagement, it’s recommended for a one-day workshop to flesh out the client’s knowledge of the problem and scope, then align on the goal of the accelerator. This helps us plan out a suitable multi-disciplinary team. Often, this phase continues beyond the workshop into the first few days of the engagement.
We want to start forming a relationship with a knowledgeable product owner asap; this is a key stakeholder and should be empowered to make decisions during the engagement. We try to identify all points of contact we are likely to work with, as early as possible, so we can start booking interviews/meetings/workshops.
It’s good to understand the internal awareness of a project, particularly if the topic in question might be sensitive to current roles or ways of working, and diplomatic and empathetic skills are key in this regard. We find it’s good to set up a one-pager describing our aims and objectives and sharing with points of contact. This enables us to keep interviews and workshops focused and as short as possible. Often people donate their time alongside existing duties, so we need to be respectful of this.
I also find that identifying key partners with the IT department is important. There may be onboarding or other processes with significant lead time if we need access to services or data. Any such requests need to be raised or actioned on day one. It’s a good idea to keep a risk log with any potential blockers raised, with clear ownership and expectations alongside impact. This is shared with the client and team.
At the end of this phase, all stakeholders should be known, time with decision makers planned, regular ceremonies booked and a good understanding of the current scope and problem definition.
Phase 2: Immersion, design & validation
Immersion
Immersion is all about understanding the current domain. During this phase we perform as-is mapping (experiences, data and technology), research industry standards, and perform competitor analysis. We use a variety of MVEs and focused user research approaches to help us gain deeper knowledge of a topic and validate any assumptions in the current problem definition. We like to collaborate as one team (including client members) in workshops and often use Miro to run sessions.
Everyone has something to contribute to most topics, whether that’s IT guiding the art of the possible or capabilities within the organisation (be that infrastructure or personnel), Design guiding the customer experience and best practices, Strategy keeping us laser-focused on delivering measurable value inline with the overall vision, or client stakeholders bringing their domain knowledge.
At the end of this phase, we should have deep knowledge of the topic, whether the problem definition is correct or not (i.e. is it evidence-based and has it identified potential levers for measuring the success of a solution). Throughout this process, we will have regular ceremonies with stakeholders so they can evolve their understanding alongside our own, get a window into our thinking and direction of travel. We usually review the outcomes at this point in case research and validation has thrown up alternative thinking and work with the client to refine where needed. It is possible (and likely from my experience) to pivot at this point, as more knowledge has been acquired, but any such change needs buy-in from everyone.
Design & validation
At this point, the team might be a bit more inward-focused, though, with regular sessions with the client to demonstrate current thinking and progression of ideas. We come up with a range of solutions, which are refined through testing and validation. Although rare, sometimes assumptions can only be validated with testing in the market for a more sustained period. If these occur, we may recommend creating a particular type of MVP (minimum viable product — wizard of oz, concierge, etc.) to validate market desirability before investing in building the new offering. For example, a client wanted to digitise part of their customer journey, but data was pointing to high usage of traditional channels. To help prove the assumption, we suggested using part of the journey on an existing marketing CMS (content management system) site to create an area to measure effectiveness. We want to ensure a longer-term solution is going to provide business value.
If there are technical or design concepts we want to test or gain confidence in, we often produce a design or coded prototypes or proof-of-concepts as outputs of this phase.
Phase 3: Delivery Planning
Coming into this phase, we have validated the problem space and built confidence in the solution through testing with users and technology investigations. Now the focus is on the delivery plan: team sizing and effort, including MVP backlog creation. We ensure that all research assets are finalised, as these are often used to guide the delivery team, and we present back our findings to the client in a final presentation with accompanying deck for them to take away.
Final thoughts…
As you can see, quite a lot is covered in a short amount of time; this makes phase 1 the most important, as that sets the team up for success. Working closely with stakeholders is a very rewarding part of this type of engagement. Clients get to see us in action and understand how we work and what we value as individuals and as an organisation. This helps us form new and rewarding relationships often becoming trusted advisors across a range of projects.
