Stooa, agile development of a fishbowl tool
In a time of pandemic, we felt it was essential to take this approach to the virtual environment to keep up the connection between runroomers and preserve our agile ecosystem. But were we the only ones with this need, and what was going on in other organisations?
The research and iteration process we tell you about in this case allowed us to turn an inkling into a reality. It’s the story of how Stooa, the first online fishbowl on the market, emerged blinking into the light.
Stooa is an outstanding tool which closely recreates the group dynamics you get in a fishbowl. Its user-friendly interface allows people to quickly jump in and out of the conversation and that adds pizzazz to the session. Much like a face-to-face fishbowl, you don’t need any facilitation or specific technical knowledge. It’s really handy for large groups looking to discuss a challenging topic.
In the wake of the pandemic and while entirely engaged in full remote work, we had to address the challenge of shifting our meeting and participation venues, the mainstays of Runroom’s collaborative culture, to online.
In particular, we needed an in-house communication tool which would automatically facilitate self-organised conversations between large groups of people.
After benchmarking, we found that there was no software for this purpose on the market and so we set out to investigate whether our concern was also a problem for others: Are online tools needed that allow seamless and orderly knowledge sharing? Are specific tools required for unconference approaches (self-organised collaborative discussions)?
These questions prompted the conceptualisation and creation of the MVP (Minimum Viable Product) for Stooa, the first online tool specifically for fishbowl dynamics.
To fashion Stooa we tapped into Lean methodology. It’s a method which kicked off in Japan in the 1970s with the TPS (Toyota Production System) and targets identifying and enhancing value creation by minimising time waste. Under this system, the success of a product, service or business model depends on how skilfully we iterate it in the light of the feedback we get from testing before we run out of resources. The key to minimising waste is to learn (as much and as fast as possible) about customers.
How did we begin this learning?
The first thing to do when unpacking an idea’s feasibility is to check whether the problem you’re trying to solve is a real problem for someone. In other words, whether you’ve come across a problem worth solving. In the Lean world, this stage is known as problem-solution fit or empathy.
Our experience when attending online unconference events is that it’s very hard to have an orderly, free-flowing and intelligible conversation if there are more than five people in the room. So we set out to validate the following problem: Do we need specific online tools for participatory and self-organised events? And is this a shared concern?
To find out, we drew on the theoretical framework proposed by Ash Maurya in Running Lean and followed the steps below:
1. We crafted a Lean Canvas
Lean Canvas (inspired by Alexander Osterwalder’s Business Model Canvas) is a tool intended to conceptualise business models for projects where there is a lot of uncertainty. On a single page, it provides a bird’s eye view of the key aspects involved and how they relate to each other. As it is a schematic and concise diagram, it allows changes to be introduced very easily and learning to be tracked as it is gained.
This is Stooa’s Lean Canvas, the original canvas on which we dumped all the learning that would follow:
2. We validated the problem in interviews (The Problem Interview)
Once we’d devised our Lean Canvas, we had to find out whether our business model was founded on a problem which is worth solving. We used problem interviews with potential customers as a way of checking whether the need we thought we had pinpointed really existed.
Following the script structure proposed in Running Lean designed to glean unbiased information from hypothetical customers, we conducted 10 interviews lasting about 30 minutes with stakeholders, like Miquel Rodríguez, Marc Mauri or Jose E. R. Huerta, to find out what their experiences and main pains were in online unconference events:
The conclusion of the interviews was that the problem did appear to exist and therefore it made sense to explore a potential solution!
3. We built a prototype for a potential solution
At this point, we already knew we needed specific tools to support online unconference dynamics. Out of the ones available (dot-voting, world café, speed dating, open space, etc.), we chose fishbowl because it is closely tied to Runroom’s culture.
We did a one-week Design Sprint in which we collaboratively shaped a prototype of what would become Stooa. And we took this first interface back to the same stakeholders we’d interviewed so that they could interact with it and give us feedback.
4. We validated the solution in interviews (The Solution Interview)
To gather their impressions about the Stooa prototype, we conducted what are known as solution interviews whose purpose is to confirm whether the proposed solution effectively solves the problem. As in the problem interviews, it’s crucial to draw up hypotheses and test them. After conducting the 10 interviews, we then gave them a quantitative survey to find out if they would be willing to pay for a product like Stooa.
Once we’d examined and summarised all the information from the interviews and surveys, there was something to celebrate: Stooa’s prototype appeared to be a good way to solve their problem and they would be willing to pay for it!
That was the green light to develop our MVP, i.e. the minimum features Stooa needed to successfully address the pains that online unconference approaches currently entail.
Stooa has enabled us to tap into a new way of conducting virtual discussions as part of the Barcelona Demà participatory process. Unlike one-way webinars, the fishbowl format delivers two key goals: making the conversation livelier and allowing a wider range of opinions to be heard.
Anchored in an agile standpoint of early and frequent delivery of value, we iteratively and incrementally developed Stooa by systematically prototyping and testing.
We developed the first Stooa MVP in six two-week sprints with user testing to validate its main features. To do that we set up a cross-functional team made up of multiple roles and profiles (business, frontends, backends, researchers, designers, etc.) that changed throughout the process without impacting the quality of the product or the delivery schedule.
On 12 February 2021 we presented Stooa at a fittingly appropriate event called “20 years of the Agile Manifesto”, three online fishbowls in which we talked about the evolution of agility and the various ways of addressing it.
Although its development is still ongoing, today Stooa is now a reality and some organisations such as the PEMB (Barcelona Metropolitan Strategic Plan) are using it at the heart of their participatory processes. Here at Runroom we couldn’t be happier to have developed a tool so in line with our values that allows open, seamless and self-managed conversation, connecting us with current and future friends.
Yet the ride doesn’t end here: more excited than ever, we now plan to validate Stooa’s market-solution fit and embark on the adherence stage of this long journey. With this goal, at the end of November 2021 we released the Stooa’s code and officially presented our new open source product on Product Hunt and on Hacker News. It was our opportunity for giving back to the international community of developers from whom we received so much during all these years!
We recommend you to read the newsletter dedicated by Product Hunt on the launch of: "The fishbowl method at work".
Our next steps are to raise Stooa’s profile in virtual communities, continue generating value and deliver an Open Source product aligned with Runroom’s collaborative culture. To be continued…!
The only way to launch a digital product’s MVP is by using the Agile methodology so you can validate your hypotheses as swiftly as possible, especially the wrong ones. Fail Fast, Fail Cheap, Fail Happy!