For the past year, I have been overseeing the scaling of five civic tech products from country to country as part of the TransparenCEE project, this has made me think about what civic tech product management looks like in practice. There are a lot of bad practices, some resulting from inefficient resources, but most caused by the lack of or insufficient focus on the planning phases of projects and the organizational structure behind it. In the Civic Tech Product Management series of articles, I want to focus on a practical approach to the subject. Today, I will start with some of our experiences of how to structure a project’s management team.
Product vs Project Manager
Most civic tech projects involve building a technology product. How should such a project be managed? I tend to agree with Lucy Chambers who argues that a project should be parallely managed by two people. Apart from a Project Manager, a term and role widely used and understood, we should invest in also having a Product Manager. How do these roles differ? In her latest article, “5 years in 5 posts. Part 5: Product Management,” Lucy Chambers sums it up perfectly:
In a highly oversimplified form, the difference between the two is as follows:
- A product manager is the translation layer between a team of developers and stakeholders (often external clients, but can also be managers and other internal “clients” at the organisation). They define criteria for what needs to be built and why.
- A project manager defines the how and when: e.g. how much money can be spent, when certain things need to be delivered and often staffing.
While these two roles may be combined, they often require different skillsets. In civic tech projects, project managers quite often have to manage grants (communicate with the donor, fill invoices, compute taxes, write reports), conduct communications, organize events or hire external contractors (a product manager can be one of them). It’s good to acknowledge these two distinct roles even if you’re forced to compromise and combine them in the end.
Since reading Lucy’s article, I’ve put “Product Manager at TransparenCEE.org” in my email footer, because I’ve realized that product management is what I’ve been mostly doing during the past year (cooperating closely with Anka Kuliberda – a project manager).
Civic vs Tech Component
In planning the TransparenCEE initiative, our team has subconsciously taken into account one additional distinction, which has become quite important during the project’s implementation. That distinction is between civic and tech. There’s no contradiction, you might say, it’s all about mixing the two. However, we believe that in civic tech projects, not enough emphasis is put on bridging the civic & tech gap that comes from the human nature of the people implementing these projects. We’ve seen the geeks argue over this or that programming language or redesigning websites which are ‘good enough’ while forgetting to ask the users/beneficiaries/citizens if they actually want/need it and ‘forgetting’ to conduct the campaigns needed to have their project actually reach an audience. Of course, we’ve also seen civic activists over-excited by hackathons and apps, or focused on other means-to-an-end while forgetting the ultimate goal they want to reach. We’ve mentioned an exaggerated version of this gap during our Personal Democracy Forum Ukraine 2016 talk:
During the project implementation phase, I’ve done my best to see the big picture, but I was comfortable concentrating on the projects’ tech side knowing that Anka would raise any issue on the civic side (such as impact, an organization’s culture or political considerations). At the same time, Anka could ask any technical question, without feeling silly, knowing that she would get a translation from tech to human. This collaboration helped us make the five scaled products work, but also during the whole project.
On a more philosophical level, to think about civic tech work more critically, I highly recommend Kentaro Toyama’s Geek Heresy: Rescuing Social Change from the Cult of Technology. William Easterly, Professor of Economics at New York University, wrote about the book: “[..] Technology does not solve problems; people do, Toyama reminds us. He balances his refreshing skepticism about technological utopias with inspiring faith in the motivation and creativity of human beings.” I have see this at work both in CEE and elsewhere: change doesn’t come from using the tech, it comes from highly committed people, no matter what tools they are using.
On a practical level, I will continue to release articles focusing on the practice of product management and product documentation to help reuse the solutions we developed.