How to PM in a Mission-Driven Org
I recently wrote about five ways product management is different in a mission-driven organization. Since then I’ve been thinking about how to be most effective as a PM in these kinds of organizations. Below are a few strategies for bringing product- and design-thinking to social change efforts. Would love to hear other ideas.
1. Connect your product development team to the mission.
In my experience, engineers and designers who work for mission-driven organizations are doing it because they feel drawn to the mission. It’s often the case that they could all be making more money elsewhere, but they’re choosing to spend their time on work they find more meaningful. However, I’ve sometimes seen organizations treat their development team as if they are just workhorses, hired to implement the ideas of the program staff, who are perceived as the ones who know how to effect social change. Organizations do better when they involve their technical team in designing solutions to non-technical problems. The combination of different perspectives can lead to innovation as well as more comprehensive and realistic solutions.
2. Iterate rapidly on programs and services.
Software doesn’t have a monopoly on iterative development. Program staff and researchers at mission-driven organizations have long mastered the art of designing experiments to test hypotheses about solutions to social problems. Product Managers at mission-driven organizations can also design short experiments to quickly validate hypotheses about the product-y parts of the work. For example, you might design an A/B test around your website’s navigational structure to see if you can move the needle on small-dollar donations. You can also run A/B tests on “offline” product work — as an example, imagine running a few variations on your traditional training module for volunteers to see if you can increase the average duration of a volunteer’s tenure with your organization.
3. Don’t expect technology to solve human problems.
For obvious reasons, people with tech backgrounds often turn to technology to find solutions to problems. But not every problem is a technological one. Sometimes what’s needed is a new approach to program delivery, or a different outreach strategy, or a fresh look at your service design. Learn to recognize the difference. As a PM, you might be excited to apply product-thinking to human problems, but the risk of always turning to technology is that programmatic failures will be blamed on technological shortcomings.
4. Practice “co-design” with your constituents.
When you work in a mission-driven organization, your “users” might be constituents, clients, volunteers, donors, or beneficiaries of a service you provide. Whatever the relationship, consider them stakeholders and partners in product development. Devise ways to co-design solutions. Examples include card-sorting exercises to better understand your constituents’ mental models about your offerings, in-person observations of your clients’ daily experiences, or inviting them to design studios to collaborate directly on solutions. This feels especially important in mission-driven organizations that struggle to break out of internally-defined structures, vocabularies, and practices.
5. Don’t recreate the wheel.
Many nonprofit leaders fall into the trap of thinking their needs are specific to them and can’t be solved with existing technology. Plus, technologists get excited about the prospect of building something new. But it’s likely that many of the technology solutions you’re planning for your organization have been created or applied by other organizations already, and the mission should come before personal interests and shiny objects. You may have specific workflows or unusual terminology, but your ultimate aim may not be all that different from what others have done. Conduct a thorough review of existing resources before jumping into building something bespoke.
What would you add to this list?
