In a recent community project at ERNI, we put ourselves to this task. This is the first article out of a series of four in which we explain how we shaped our idea into a product vision. The topic was presented at the Google Developers DevFest Switzerland 2018 conference. Watch the talk online.
ERNI is a software consultancy firm with a thriving community of technology experts. We were playing around with dust particle sensors when we got an idea. What if we could predict air quality to inform people on health risks? Sure, dust particle measurements have been made before around Switzerland and Slovakia. Our idea would go beyond that, though, to build a network of sensors combined with weather information to forecast pollution levels. We could connect our sensors with a public network (e.g., https://luftdaten.info) to contribute to open data initiatives.
Particle pollution occurs when airborne solid and liquid droplets exceed a threshold and becomes damaging to our health
Particle pollution occurs when particulate matter (PM), consisting of airborne solid and liquid droplets, exceeds a threshold and becomes damaging to our health. These particles come in different sizes and shapes, and include sand, dust and smoke. Construction sites, roads, traffic and industry are the main contributors. Weather and geography play an important role, with calm humid summer days in valleys seeing the most build-up of dust particles. Two sizes of particles are particularly important to human health. Fine particles with diameters of 2.5 µm or smaller (PM2.5) come from fires and dust sources. Coarse particles (PM10) with diameters between 2.5 and 10 µm come from combustion sources and are the primary contributor to pollution.
Spread out between countries and cities, we had planned to work separately and individually on the various parts of our application. We would come together once at a “hack & hike” weekend in the Swiss mountains where we would – apart from getting to know each other and enjoying mountain life – build the core components of the system. Afterwards, we would again scatter and work in isolation with a minimum required level of coordination.
We decided that to give shape to our idea and be efficient throughout the project, we would have to organise a workshop. We enlisted our innovation experts with the task to organise a Think Tank, during which we would work out our product vision and define the scope of our first release.
The double diamond describes an iterative process with significant upfront exploration focusing on one specific solution
The workshop design was inspired by the double diamond model, which is widely used in Design Thinking. It describes an iterative process with significant upfront exploration focusing on one specific solution. Each diamond consists of two phases: the opening phase (divergence) and the reduction phase (convergence).
The workshop focused on defining the product vision and plan (the first diamond). We did not adhere strictly to this process; instead we went through the discover and define phases twice. The focus of the first iteration was to build a common product vision and ensure that the team had a common level of understanding. In the second pass, we identified the end user and defined the MVP (Minimal Viable Product) scope.
The discovery phase is divergent as many alternative ideas and plans are proposed, typically through observation and enquiry of customer behaviour and business drivers
The purpose of the discovery phase is to conduct explorative research to understand the idea or problem statement. This process is divergent as many alternative ideas and plans are proposed, typically through observation and enquiry of customer behaviour and business drivers. In our workshop, we bypassed the discovery process as there wouldn’t have been enough time. Instead, the workshop participants were asked to study the topic ideas and shared their thoughts on the product vision in a first sharing session.
The gathered understanding was analysed and synthesised into insights during the define phase. The team structured the ideas into thematic clusters which represented product epics and helped to converge into a product vision that focussed on the most compelling business values.
In the second discover-and-define iteration, the team brainstormed about who would be using the product and what value it would bring them. The purpose of this exercise was to force the participants to take an end user perspective and help them formulate a fundamental understanding to ensure that the product truly fulfilled a real customer need. This was accomplished by letting the participants create simplified versions of personas using a set template.
Next, a Minimal Viable Product, or MVP, was defined. Defining an MVP is part of the lean innovation approach and impels the participants to create a solution that fulfils only the core requirements, thereby minimising time-to-market and reducing risks. This was also relevant in our project, as we would have limited time to create a working solution.
The participants were instructed to agree on one persona, which would form the basis of the product scope. The most important and best feasible product epics were selected and reduced to their essence before they were included in the MVP scope.
With these very consciously adopted divergence and convergence phases, we ensured that the team really focused on an MVP and not on a high-end solution.
We realised that our organisation would lend itself well to a holacratic experiment. Rather than installing traditional top-down leadership and governance to manage the project, we decided to organise ourselves as a community of equals. Self-organisation ensures that our limited time and energy is focused on what matters. The team is committed and purpose-driven, and everyone has roles and responsibilities that are transparent and dynamic (they may change over time). Collaboration rules ensure that expectations are explicit without hidden power dynamics.
The roles and work plan were defined through another divergence-and-convergence phase. The participants brainstormed together about the roles needed to accomplish the project. The roles were then further explored by small groups to determine the skillset required for each role and the associated tasks. Finally, the role, skill and task definitions were reduced to fulfil the MVP scope.
Self-organisation ensures that our limited time and energy is focused on what matters
Next, the available skills among the community were clarified to determine if the necessary expertise was present. The participants were free to choose a role. Responsibility and commitment ensured that the various teams had the critical expertise. Topic leaders (e.g., IoT, backend) were selected to give guidance to a part of the project, and teams evolved around these.
And with that, the community was ready to kick off the development of the dust measurement network.
Thanks to the following people for helping to make this project a reality: Adrian Beffa, Alain Zoja, Andreas Schöpfer, Angus Long, Barbora Feketeová, Caroline Jakob, Christian Schluep, David Krauer, Esther Studer, Gunther Dobratz, Halina Cardini, Isabelle Rüthemann, Ján Neščivera, Joel Sommer, Marek Linka, Marty Michael, Matej Pivarči, Michael Huber, Michal Dorner, Michel Meyer, Michel Meyer, Nathan Lauener, Nicolas Friberg, Ondrej Kollár, Reto Zumbühl, Režnák Ján, Simon Matter, Soňa Pochybová, Thomas Kägi, Dieter Niklaus