Our digital product process doesn’t follow a linear process. We utilise our burst and bloom approach to custom design each burst project by selecting what is required from our work clusters. Our work clusters are essentially the phases of a typical product design & build process.
The difference is that we allow for the fact that each organisation's digital product is at a different stage and doesn’t fit exactly into one phase. Rather each burst project might require and mix these phases with varying fidelity. For example an existing digital product may need a small bit of discovery, a large bit of research and a small bit of coding and releasing and a small bit of training and onboarding.
The work clusters we choose from can be described as follows:
Explore & discover
This cluster of work represents the activities required to identify particular opportunity or problem spaces. Typically we use this chunk when the work is not particularly well defined or when there is a new innovation that we are trying to figure out where it fits within the current digital solution. Examples of activities in this area include:
Service mapping
Goals and objective definition
Interviews
Competitor analysis
Research
This cluster of work represents activities where we delve deeper into understanding a particular topic area, user or customer group.
Examples of activities in this area include:
Behavioural research
User research
Market research
Scoping, prioritisation
This cluster of work represents the activities required to turn a high level set of objectives into a prioritised set of achievable steps
Roadmapping
User stories
Backlog management
Design, prototype and test
This cluster of work represents the activities required to visualise and communicate a digital solution to the team, stakeholders, users and the developers with minimum need for code. Examples of activities in this area include:
UX design
UI design
Clickable prototypes
Code and release
This cluster of work represents the activities required to code and release a version of the digital solution. Examples of activities in this area include:
Front-end coding
Back-end coding
Data analytics implementation
Unit testing
User Acceptance Testing (UAT)
Quality Assurance (QA) testing for performance, usability, and reliability
Measure and learn
This cluster of work represents the work that takes place while the digital product is live, gathering valuable data on user behaviour and feedback in order to inform future bursts of work to improve the value of the end users and organisation as whole.
Examples of activities in this area include:
Data analytics analysis
User satisfaction surveys
User interviews
Feedback and learning gathering and sorting
Maintain and fix
This cluster of work represents, ensuring that the digital product stays stable and usable post live.
Examples of activities in this area include:
Bug identification and fixing
Team education and process
This cluster of work represents the work that takes place to ensure that an organisation's current employees are able to effectively work with the digital product we have created.
Examples of activities in this area include:
Hiring and onboarding of digital experts
Training of existing staff
Company documentation
Defining processes of how to interact and maintain the digital product
Our project process steps
Each burst project involves specific steps aimed at fostering trust with us and our partners, collectively deepening our grasp of the digital solution, and enabling practical actions that consistently enhance user satisfaction and drive organisational success.
1. Onboarding working session
These working sessions serve as a platform to collectively unravel the challenges we face and pinpoint the most effective ways to identify and address them. Typically, our session focuses on discovery, ensuring that all pertinent questions are raised upfront. This approach allows us to gather and deliberate on crucial information as a team before delving into potential solutions. Moreover, these workshops foster an open, collaborative environment, enabling us to collaboratively shape and define the project together
2. Project definition
We use the logical model framework in order to define and scope the project and turn this into a statement of work. The Logical model framework provides an overview of a project's goal, activities and anticipated results. It provides a structure to help specify the components of a project and its activities and for relating them to one another.
3. Project definition, process, roles and responsibilities
From the project definition we align on the process for delivering the work, team setup, their roles responsibilities and agree on a set of project collaboration principles.
4. Kick off
We bring the whole team together in order to share the key parts of defining the project we have done in step 1 to 2 and align together on how we’ll work together.
5. Sprints and/or work packages
Exactly how the burst will run will depend on what work clusters have been defined in step 3. But typically we will use some kind of agile methodology to run sprints of prioritised tasks with short regular check-ins when the work involves some coding and design. If the project is more research focussed then we will skill manage our tasks using a method like Kanban, but utilise sprints much less.
6. Retrospectives
To ensure the smooth running of the team we will do regular retrospectives with the whole team. Learnings & actions from these sessions are collected over time and when required can be used to define actionable tasks as part of step five to ensure feedback is visibly actioned.
7. End of project reviews
As the project nears close, we will review the collected retrospective learnings alongside the statement of work to ensure we have achieved our aims set out at the beginning and to summarise what we have learnt to take into the next burst.
8. Signal to bloom workshop
The last step in a burst will be to define how the work we have done will continue to be measured after we leave the project. We facilitate a workshop where alongside our partner, we help to define how further learnings will be gathered, what are the aims with the learnings and then how often we should check-in.
