To engage people to come to g0v hackathons, some g0v participants –including me– may paint an illusion that anyone can pitch their ideas and find professionals to work on a civic tech project.

It is true but very hard to achieve. You need to engage the right people, know how to collaborate with people from diverse backgrounds, and keep the momentum strong enough to launch the project if it takes more than one day to build.

First challenge:

Even though there are proposal templates for g0v hackathon and open collaboration guidelines, many g0v first-comers fail in the 3 min pitch in the morning — other participants just can’t understand what problems they propose to solve and how they could contribute, so few show strong interests.

Second challenge:

Even if they successfully attract skilled talents to their table, few first-time project owners (坑主) don’t feel lost on how to initiate discussion and scope the project into feasible next actions.

I joined a new project discussion on developing a reporting platform in the initiative of conserving Taiwan Black Bear, an endangered species endemic to Taiwan.

In the hackathon, they had already given a great presentation, attracted good talents, and sketched the workflow of the website to build in the previous discussion. I sat down to help checking the workflow sketch — or at least others thought so.

They had done a great job. I just wanted to check if the product they planned could serve their advocacy or research goals and if there is any simpler prototyping or MVP.

I really liked the researcher, Diaoga, that pitched the idea was able to elaborate their advocacy and current problems. There were already needs and users: 1) people reported Taiwan Black Bear appearances, but the report quality was often low without clear location marks and 2) researchers archived them into datasets, which were separately saved offline in Excel files in each researcher’s computer without synchronization. They presented real scenarios and data, not an imagined problem.

However, the initial introduction was focusing only on how a new web interface could improve current data collection process.

Scoping: what do you want to solve and achieve?

“So what can the data do for your research purpose? Why do we need better data? What are the definition of qualified data?” I asked.

Diaoga answered that citizen science data collection could serve more data for Taiwan Black Bear researches and they suffered from terrible location positioning data reported by non-experts.

“Okay, so we want the location data to be more precise. However, how will those data contribute to academic research or advocacy?” I asked.

Diaoga had difficulties in answering this one with real examples.

I rephrased the question, “What is the title of an academic paper if we have abundant qualified data? What are the keywords?”

“Then we can analysis presence and absence of bears on landscape,” he answered, “So that we can know where they are, recognize core habitats, hot spots of human-bear conflicts, and estimate density and population trends of bears”.

“How will that research contribute to advocacy?” I asked, “Now we know more precisely where they have been, and then? What is the advocacy goal here? Is it to avoid the ‘human-bear conflict’ you mentioned? Or to engage the public in citizen science to raise awareness?”

“Yes, to prevent the human-bear conflicts,” he explained, “Most hostility comes from the bears eating or destroying human’s crops, poultry, and properties. If we can monitor their movements and homerange, then we can work with the locals to set up precaution such as removing food storage outside their houses.”

“So that we can reduce fatal attacks on Taiwan Black Bears and conserve their population?” I concluded.

It was a process to identify “what we want to build” in the following levels:

• Visions
• Impacts
• Goals
• Objectives
• Outcomes
• Strategies/Projects/Products

Next, before diving into product design discussion, I questioned the team:

• Why are the existing solutions not working?
• Any examples to consider or borrow? Have you surveyed any open source projects in order not to reinvent the wheel?
• Why do you believe a new tool, a new dataset, or a new app can solve the problem? What is the tool in the bigger picture?

They convinced me the necessity to develop a new digital platform. Then we moved to mapping stakeholders:

• NGO resources and strategies at different stages.
• Individual capability of academic researchers, NGO staffs and open source contributors.
• Government’s coming policies and attitudes of multiple government agencies on the subject.

The next step was to identify the details of target audience.

Who would be the target audience? What for? When would they use the platform? Where to find them? What would be the challenges to engage them? For instance, we identified two groups of users: data contributors and researchers. The early data contributors might be experienced mountaineers since Taiwan Black Bear mostly live in high mountain areas. We then considered when, how, and what information we wanted them to upload and realized that most mountaineers reported the Black Bear appearance after their trekking, so we didn’t have to be worried about the device and Internet accessibility in the mountains and focused on how to assist them mark the locations as precise as possible once they got home.

Lastly, I reminded them to prototype fast and focus on the minimum viable product they could build in three months.

Tips for product development after a hackathon

Scoping the project already consumed all the time we had, so I just grabbed a pen and paper writing down some keywords for upcoming product development besides MVP and agile, which the developers seemed to know very well already.

Milestones: to make the team see the progress and goals.

To let contributors estimate how much time they are going to commit, there are 3 timeframes to think about:

• What can be done in 1 day? (in the hackathon)
• What can be done in 2 weeks?(first sprint)
• What MVP can we build in 2–3 months?(one milestone)

What are the delivery for users at the end of each milestone? Be agile and iterate. Most of the time, user feedbacks will not be the same as what developers expect. Prototype and build a MVP. Cut the product into stages or parts, so that you don’t feel you are doing too little but feel more confident to achieve the whole product incrementally.

Get users first, worry low possibility abuses later. No ones will intentionally abuse a system with few users, especially a non-profit, non-sensitive project. Nevertheless, there may be some key features can’t be minimized and need proper preparation and testing — various for different projects, e.g. payment, digital security for high risk users, double booking, or legal violation. When you can’t do it all, make a priority and have a plan to react to those bad scenarios without overthinking.

Set up meetups: set the rhythm and dynamics

Meetups should be run by time not by deliverables. Otherwise, it would just only make open source contributors too much pressure to show up in a meetup. Be realistic on product development progress in milestone checking.

The span of one sprint or one milestone should be based on the project’s time sensitivity. My suggestion is no longer than bi-weekly because most people do their parts in the last two weeks even given a month. Take it as sprint for each meetup.

Meetup is a time allowing on-site working instead of a formal meeting evaluating performance. Be a team to help each other remove barriers.

The largest crisis would be that all team members are too exhausted to complete their works and never launch a MVP, so make the prototype/MVP look feasible in the time frame. (The truth is that it usually won’t. Nevertheless, seeing the North Star makes people not feel lost and seeing the finish line supports people running through the last exhausting mile. Endless marathon just makes everyone frustrated.)

Above all, having fun is one of the most important drives of any open source projects.

User Story: how to describe what features you want

For any beginners, user story is definitely helpful to describe what you want the features can serve in which scenarios for whom. Write clear user stories to let digital product professionals figure out possible solutions rather than directly say you want to build an AI or use blockchain. Trust your team can build better solutions than only you as long as they know the goals and scenarios of the product.

Write no more than 3 user stories to developers when you start your first prototype. Keep them concise.

A typical user story template:

• As a ______,
• I want to ________,
• So that I can ________.

Adding the scenario:

• As a ______,
• When ______,
• I want to ________,
• So that I can ________.

Besides using user story to communicate with developers and designers, I also suggest to make clear of

• Success criteria:
  What is the definition of being good enough? For instance, users can successfully upload a photo, which implies that the shorter uploading time is secondary consideration.
• Out of scope:
  Features that sound really cool, but we don’t have resources to build at the moment, e.g. social media log-in in the first prototype.

So that the team won’t overdo their work and the project can iterate faster without spending too much time on dead ends.

6 months later, their project #ohshown is in alpha and designed as a report system infrastructure not limited to Taiwan Black Bears. You can find them on g0v Slack in #ohshown channel.

Invite yourself to g0v Slack: https://join.g0v.tw

As for more information on Taiwan Black Bears:
https://www.taiwanbear.org.tw/

If I have more time, I would like to add real examples on the user story.