The future of crowd sourced global problem solving
A quick review of running multiple Remote Sprints at once
On February 19th we ran an experiment — what if we guide several teams at the same time through Deep Work Sprints, with each time working on a similar problem? In the following I will describe how we did it, what the results look like and how we can scale Deep Work Sprints into infinity, thus creating a structure for solving very high-stake problems in a short amount of time with very little resources.
The initial structure of a Deep Work Sprint is very simple — it’s basically a more structured GV’s Design Sprint, split into three four-hour days, with all participants working remotely.
It enables a team to align on a problem statement, build an MVP and test it with real users in 6 days. The result is always something entirely new, that has never existed before.
3 Deep Work Sprints at the same time
After advertising the event through our private channels we quickly gathered enough participants for 3 teams with different skillsets. The entire process would take 6 days in total — 3 days of remote workshops, 1 day for prototyping and 1 day for user testing, the final day being left for the presentation and some polish.
The actual structure in this experiment consisted of a more scalable version of the Deep Work Sprint. I ran the facilitation and provided an infrastructure for three teams to work the same time. They then organised themselves around their agreed on challenges and designed individual solutions.
For coordination we used Telegram groups and did video conferences in Zoom with breakout rooms where necessary. The collaborative process went through Miro.
There were no financial incentives and all team members worked in their spare time!
Diverse solution approaches to the same challenge
Our idea was to use the Ethereum community to provide the Ethereum community with open source design fragments for staking interfaces. Since last year, there is an increase in staking products and interfaces and with that a new set of unexplored user-behaviours. Because the problems are largely similar (how users can make sure that their money is transferred safely, where they need education and where reduced friction), exploring those and open up the results to the space would benefit everyone and speed up product development cycles.
With this problem statement, we guided three teams through the structured exploration of different interfaces, which turned out to be completely different.
Team 1 — On-boarding into ETH Staking
The first team had the most members and focused on creating a lightweight on-boarding interface, that would guide users through a “dry-run” for staking, while explaining key management and simplifying the complex parts. In the 6 days, they managed to build the entire MVP, do research, and create a highly detailed presentation.
The prototype design was done in about a day and can be viewed here:
And their presentation describes the results of a handful of user tests:
The result is a highly detailed prototype for staking, which educates users about the entire process while trying to simplify the experience.
Team 2 — A mobile staking experience
Currently, users prefer financial transactions to happen on a large (desktop) device. But over time and with more confidence in the technology, this will change. It is much more convenient to be able to control your finances from the pocket from a mobile device. The team did extensive research on existing staking mobile apps and tried to come up with a mobile staking dashboard.
As adoption increases, the result could be used as a fundamental part of staking interactions on smartphones.
They were the smallest team, but still managed to finish everything with novel ideas.
Team 3 — A DAO for staking and pooling
The third team (Stake Capital) started designing a brand new product for their DeFi suite. I can’t post screenshots of any results here because they want to present it at EthCC, but I will fill them in as soon as they are ready. For now, you can observe all the work they did when brainstorming and sketching concepts:
How can we apply this model to product development?
As mentioned before, all team team members worked out of personal interest to either learn about the process or to create something entirely novel and can help the community. It is infinitely scalable and the more teams participate, the higher will be the quality of the result.
Sponsorships
Several participants needed to juggle their paid work and the Hackathon sessions. This can be avoided with financial incentives (even smaller amounts) — which will motivate participants to put in even more work into the Sprints and reduce drop offs and passivity.
Community building
Before the Hackathon, none of the participants knew each other. They knew only that they are creating something valuable for a community they are part of. By applying this structure to any product, any team can make their community stronger while listening to their opinions and ideas, which in turn helps developing their product.
Super high stake challenges
The largest consulting companies like McKinsey, Bain&Co., etc. use competitions to find the best talent to hire. At the same time, they let a lot of potential employees work on high stake challenges, which would normally require months of work and a lot of (external) resources. The more people can work on those problems in a structured manner, the higher quality will be the end result. Extremely expensive product problems might not be solved by 10 people in 6 days. But the chances that they will be solved by 50 people in 5 teams, in 6 days, are much higher.
What’s next?
The crowdsourced problem solving approach isn’t new, Kaggle successfully improved many commercial algorithms with similar contests for data science. With the Deep Work Hackathon now have the structure and an important building block to do the same for design challenges.
So this experiment was only the beginning of something bigger, I haven’t even mentioned the ability to track votes and tokenise the challenge to distribute rewards by quality of outcomes.
This is a topic for another time, but for now, like and subscribe!
