Authors (alphabetical): Devyn Greenberg, Sahil Joshi, Medha Patki, Kathy Pham, Nagela Nukuna
CONTRIBUTE
Each section in the Product Management and Society Playbook includes an Overview, Key Considerations, and Resources. An Examples section includes stories and cases of Product Management and Society in Practice. Inspired to contribute an example? Email productsociety@hks.harvard.edu or fill out Contribution form.
INTRODUCTION
The Product Management and Society Playbook was designed as a reference guide for those building products in the public interest.
This playbook is inspired by the Harvard University course, “Product Management and Society: Building Technology in the Public Interest” (DPI-678M),” taught by Kathy Pham, and reflects a collaboration across public interest technologists who have built, invested in, and regulated technologies in service of the public interest. Public interest technology has been defined by the Ford Foundation and New America as a field “made up of technologists who work to ensure technology is created and used responsibly. These technologists call out where technology can improve for the public good, and sometimes question whether certain technologies should be created at all. Technologists are defined not only as engineers, but also include those individuals and organizations with strong perspectives and expertise on the creation, governance and application of technology—from designers to legal experts to artists, activists, and members of communities where technology is deployed.”
Highlights
While it is important to not be stuck in approaches that have not historically worked, it is critical to honor expertise. “Expertise” includes stakeholders’ lived experiences, wisdom from the humanities and social sectors, legacy technology experience, and much more.
Own the problem, not the product. Find the right problem to solve that will meet the needs of the users. This involves going where the user is and understanding the complexities of the community.
Create the list of stakeholders, and communicate goals, roadmap, and deliverables with them. Consider a model like RACI to determine who is responsible, accountable, consulted, and/or informed.
Never skip the discovery sprint. Spend time before building a new feature or a new product to understand the problem, the stakeholders, the users, the community, the impact on society, and build a better understanding of what should be built.
The words and content on the page is the best way to build trust with the users. Prioritize how content is communicated, especially when things go wrong. Guide users through using the product.
Work closely with design and engineering teams to build and ship features that solve real problems for users. At each step of the way, consider user needs as well as short and long term impacts on society. Continue to iterate in short sprint cycles of designing, building, and user experience testing. Repeat.
Measure the right thing. Be careful of vanity metrics like number of users, how many users per day, number of clicks, etc. Determine metrics that help understand the users and the community.
Continue to optimize and maintain. Shipping is fun. Optimizing and maintaining is not as glamorous. Continue to understand what users need and if the product solves the problem. Have a team ready when the system fails or the product does not meet the needs of the people.
Teams should be multidisciplinary, with members bringing a diverse set of perspectives and skills. This means taking steps to include: people with varied functional expertise, cross-agency teams, contractors and government employees alike, and members of affected communities.
