Digital Product Development in Non-profits

Editor's Notes

• #2: About 17 months ago I was working as Product Manager in a small startup, with a team of 15 developers and 4 designers. Then one recruitment company started contacting me for product development positions that I thought were very boring, like product development for accounting software. Until one day, that recruiter posted this position on LinkedIn:
• #3: Site Project Manager to UNICEF, the description really focused project management and ordering digital things. So I wrote the recruiter saying I was interested in this position, and they were somewhat skeptical but they put me in contact with UNICEF. On my first two interviews the focus was pretty much the same: we discussed a lot why they don’t need a Site Project Manager, but a Product Manager. In fact, they probably needed MANY product managers.
• #4: PRODUCT MANAGERS. This is a very rare breed to find in non-profts. Most non-profits have digital teams whose main tasks are more related to communications, generating traffic and leads than to shape user experience and the offer. But Product Managers are the core of organizations with digital products or services. Spotify for instance has over 120 product managers. But it is still a fairly unformal profession, most Product Managers have either Design, Engineering or Business background..
• #5: So the first question that I got on the interviews with UNICEF was: what is the product? (NEXT) Be an apple of a software, a product is anything that can be offered to someone to satisfy a need. And UNICEF’s page is LOADED with products: monthly donor, fundraising etc. If all of these have real potential, then you might actually need many product managers to maximize them. A product has a life cycle. It’s conceived, developed, launched and managed, and finally retired when the need for a product diminishes. You can have many projects during the product lifetime, but what you want is a person who is in charge of maximizing the lifetime of the product, and not a project manager who is responsible for temporary projects without answering for the overall product. Regardless of campaigns and projects are happening, the product always needs to be managed to be maximized.
• #6: So then what I heard back at UNICEF was: alright, well we have some business area managers, taking care of donor segments, like one looking for all new monthly givers, one for retention, and they oversee all channels. So what does the PRODUCT manager do? A PROD MANAGER is like a CEO of the product. She will have a clear goal for the product, like revenue or new donors, and she will run after it. To reach the goal, the product manager has a blank canvas, and will use a lot of analytics to define if it is best to build new features, change features, remove features, change design, run tests, and so on. She will do the strategy and roadmap to reach it, talk to donors and internal stakeholders to gather requirements, make sure the programmers and designers have all they need to do their job while communicating with all so that everyone is aligned. The product manager asks “WHY” all the time. “Why do you want to do this instead of that?" That is because one of the main things for the PRoduct Manager is to keep focus, that is prioritize what is most important to reach the goal. Ultimately, the product manager wants to have a LOVABLE PRODUCT: EASY TO USE, and as LOW FRICTION as possible and that makes donors feel good.
• #7: So that was the intro. What we are actually going to talk about 3 things: First - The data-driven work process of a product manager, this is the biggest chunk of the presentaiton, which I hope will inspire you to work differently with data, a Then we will talk about- How this work process can collaborate to bring innovation to your organization and last - And what are the organizational requirements in terms of culture and structure to make this work So lets get started, with the work process
• #8: So, how does this work? In a conceptual level, we work with three disciplines. First, User Experience, that is Who's it that's using the product? private donors, organizations or colleagues using admin tools. The PM always has in mind who he's serving with his product, to make sure the experience is as smooth and low friction as possible and helps the product goal. This means not only a understanding of UX Design, but also actually talking to users, gathering requirements and collecting feedback. It's important to remember that it's not because you work with online marketing and visit websites everyday that you know UX. Your love for eating cake doesnt make you an excellent baker. (NEXT) Next, Technology: A product manager does not need to program herself, but she needs to understand how things are built, the level of effort required, so that she can make good decisions and prioritize according to effort. (NEXT) Last, Business. Product Management is above all a business function: you want to maximize the value of your product. (NEXT) So a product manager lives in this diagram. You have clear business goals (like increasing online donations) and since this is a digital product, the strategies and tactics to reach your goals will mostly require programming and design. The product manager can be very experienced in only of these three disciplines, but he has to be very interested in all and be able to talk to professionals in all of these. So yes, this is a very broad role.
• #9: So, now on a more tactical level, how do you do it? As said before, this is not a campaign or a project. It does not have a pre-defined end, technically you can say a product's never ready. It's always up and running, it just has different phases, where you watch different things, in an infinite loop. So first you build something, let’s say you build a donation form for emergencies. It is a one page form, with a thank you page and a thank you email. Then you put it up on your site, and set measurements in everything. You set form analytics to see what fields people are filling and what they are leaving empty. What error messages are people getting the most and so on. Are people opening the thank you email? What are your conversion rates and so forth. Then after some people have gone through the product, you get to learn by analyzing results, you draw conclusions and do changes, and then you just start the whole process all over again. Let’s say you have many users getting errors in one field. You can then rewrite the instructions and see if this reduces the amount of errors or not, if not, should you considering removing the field? And so forth. The best thing about a product being digital is exactly that you can collect feedback and see analytics instantaneously, and it is this data that allows you to have this infinite loop of improvements.
• #10: So as an example from UNICEF, we have the product Peer to Peer fundraising that we are always tweaking. So here for instance, to set up a Fundraise there used to be two steps and we lost many donors on this, so once we saw it we re-did it to have only one step.
• #11: Still on P2P Fundraising: this is an email we send to those who support a fundraiser. Part of the original requirements here that we got from corporates is to have some sort of cool visual receipt so that they can forward the email to their employees to show their support. We had higher priorities for our design resources but we still want to do the receipt. So what we did was we launched the email without the diploma anyway, so we can at least start talking to supporters and check email opening rates to improve it. So instead of building something that would take longer we launched a simple version of it first, so we could start communicating with supporters as fast as possible, instead of waiting for a design bottleneck to be ready.
• #12: Still on P2P: We still do not have a technical solution with Swish for Fundraisings, but we still wanted to get started with it, since our donors ask for it. What we do is for some of the biggest fundraisers we offer them a swish number and do manual work. This allow us to, in a controlled environment, learn more about what kind of internal processes we need to set up to make this work as we want later. Sometimes it is risky to make whole automatic systems right away without understanding all daily implications, so a first pilot with manual work actually helps that understand system requirements a lot. So all these three examples show how you can continuously improve different processes to maximize a specific product. A digital product is never fully ready.
• #13: Alright now let’s talk a bit more about DATA. By now you should understand that this is a very analytical, business-focused work. GREAT. You have clear business goals, KPIs, measurements. When we say this is a data-driven process, what it actually means, you need to be donor-focused to the core. Data is nothing but aggregation of donor behavior. Even before digital, there were focus groups and research. What is different now is that we have never had access to so much data in real time before. And many panic, and in their panic they end up ignoring data, by only using for reporting and not taking action based on it. So please, do not freak out, it will be fine. The best thing about this data, is that it is real behavior data, you can see what people are actually doing within your site and product, and not what they say that they would like or would do. Now, it is not because you have data about everything that you need to analyze everything all the time. A big part of the job should be in defining what are the few metrics that really matter and to watch out for. It's not about having a lot of data, it's about what we do with the data. In the end of the day its about our own behavior with data. A love hate relationship for many.
• #14: There are two important kinds of data sets. The first one is Reporting metrics, which are things we know we don’t know, facts we can easily go and find out: how many donations we got, visitors, shares. Things we use for accounting, the classic *admin* work we all have too much of for our own good. But we don’t really act on those metrics most of the time. Now Exploratory metrics are the things we don’t know we don’t know, that is what can actually disrupt how we work, because it shows what really matters to your organization. Exploratory metrics do not come to you when you open your GA account. They come when you ask a question like "who is more likely to become a monthly donor?" and go dig in deep to find the answer. If you dont have the answer, then the question will show you what kind of system you need to build. For instance, getting to know that a person who shares two blog posts is 70% more likely to become a monthly donor than a person who donated once. Many times you have questions that have no answer at the moment. We have many questions with no simple answer at UNICEF and these questions are for example requirements to the CRM system we are currently building. Even though in a way you should measure EVERYTHING so that you can answer exploratory questions when they come up, you cannot care about everything at once. You need priorities, and a lot of the work is finding out what really matters, and then running experiments and improving it until the metric is good enough so that you can focus on something else.
• #15: Let’s talk about one example of exploratory metrics: Twitter. When you go to twitter and create a new account, you get these pages asking you what you like and suggesting a bunch of accounts for you to follow. This is not there from day one, it is not random, and it is not something someone thought "how cool if we did it". That is in fact something they came up with after a lot of analysis and that they have been constantly improving. So what happened back in the days is that Twitter had many people creating accounts but not coming back, ghost accounts. So they needed to improve their activation, that is, actually logged in at least once a month. What they did was, they analyzed all people who were active together as a group, looking for things they had in common. What they found is that they started following many accounts really fast. Then they went to those who didnt active and guess what? They saw that they barely followed anyone right away. So what data showed them was: we need to make people follow more than 30 accounts fast. That is when this suggestions upon account creation appeared. But this wasnt an easy thing to come up with: To get there is a long commitment of different hypothesis, designs, improving suggestions algorithms, and so forth. You really need to trust the data that you have. What this means is: Once you find a factor that actually propels certain behavior, you can use it to accelerate the behavior you want to happen. This kind of understanding is called Growth hacking in startups, if you want to read more. Finding these metrics will mostly require a lot of statistics, it is not something anyone can conclude with a simple excel file, so you need an expert to help you here. And that will also give you a metric that you can actually trust.
• #16: So, taking one step back, how this actually work? This diagram is from a book called Lean Analytics, I highly recommend it to people who would like to be more analytical but are easily losing focus on what to pay attention to. Scary hum? Dont worry. (NEXT) I would like to just highlight a few of the first points about how to define what you are going to focus on your product development. First: you choose a KPI. That depends on what phase your organization and product is. Maybe you need new donors, maybe you need to work on retaining the ones you have, higher average ticket. Alright then Second step. You gotta Draw a line in the sand. What does that mean? That is how much are you willing to go to improve this KPI. Let’s say you want to improve retention from 92% after one year to 94%, but does that make sense? IS the effort for it going to pay it off? Can you talk to some competitors and check benchmarks to know what is realistic? REALITY CHECK. So Ok let’s say you would like to improve retention. The next step would be to study your donor base. What do the donors that have that behavior, that is, that are there with you after 12 months, have in common among themselves? Maybe it is a demographic information, maybe it is a specific behavior like having given to you at least 2 times before converting to monthly donor, etc. Do you see that factor missing from the donors who left you before 12 months? Now you can start setting up your strategy, be it what kind of people you will target, what kind of product you will develop, what kind of tests you will run and so forth. ONCE AGAIN you see the REPEAT Symbol here in the middle. Product management is a never-ending improvement process. That is until no one wants this product anymore or you got something better that they prefer.
• #17: So the most important thing is, you need to make sure you have good metrics. Number of unique visits or pages per visit are vanity metrics. Would you do anything if you saw that page views per visit went down by 12%? No, I wouldn’t, not really, not if I didn’t see something else going down, like revenue. Too many page views can also mean a confusing user experience. What is important is: are people finding what they are looking for? However, what if the bounce rate of your monthly donor acquisition page went up 16%? Well that I would look into. The point is we spend so much time with metrics that are useless, so take time to learn what is important to drive your organization.
• #18: So here are some key take away's from this first part - So keep in mind this is a continuous process of building, measuring and learning - ask yourself: what is it that really drives your organization? - make sure you have good metrics, the kind that you actually act on
• #19: So before we go to the next slide, I would like to ask you to take two minutes and think about this question: alright, hope that went super swell
• #20: So now we will talk a little about Innovation. The framework of a constant loop of building, measuring and testing, allows you to not have to create something super big and complicated before putting it in the market for testing. It is not like you have to do a whole movie to know whether people like it or not, you just do a trailer. Many times you might not need to do coding at all. You need an idea, and design of a user flow, so you can test using a prototype. But for this to happen, there is a mindset that needs to be in place: people working with product, digital fundraising and innovation need to have autonomy to make decisions. If every new idea becomes a big thing for discussion, not much will actually happen. The idea is to create a prototyping culture, which is what we are trying at the moment to create at UNICEF, so we are starting now a testing period where I will only work with new product development to see if that works within our culture. Hopefully it will. FINGERS CROSSED.
• #21: One great thing to do when you have a new idea is, instead of programming something and putting on your website, you can just do the design first without any coding. So first you can do some Low-Fi mockup and design it properly and put it in a prototyping tool like Invision. How many people here have used Invision? Invision is one of many prototyping tools out there. You can build clickable designs on it with entire user flows, without any coding, and ask some donors to go through it to gather feedback. So you can have an idea, build just the visual part of it and test it before building any code at all. This means a very tight feedback loop. So you link different design mock ups to each other, so that it knows that when you click here it goes there and so forth. So you can send it to some donors in a test group and do a usability test, see if they manage to go around it and like it. That is actually a strenght of non profits: consumers are not that keen to help companies,but donors are very willing to help you when you ask them. I send emails and get 20% back the next day.
• #22: Here is a simple test we have recently ran on unicef.se This is the regular page to become a monthly donor, which is a consumer product. We saw in our database that some people were registering themselves as a monthly donor as a company, even though as said, this is a consumer product. So we just duplicated the page, changed the url and the copy to fit companies and created a specific campaign in our database to see if there was interest in the market for this product. This is the very first step: we only want to know "is there enough people who want this?”We are not asking them “would you like?” we are telling them “become”. There is no point discussing more than that at first. We are still running this and there is no conclusion, but this is a very simple example of something that we saw actually initiated by the donors themselves and did something that did not take us much to test and if it works, that is, if there is a market for it, then we think about proper communication, database, website, pricing etc. "Is there a market for it?" is always the biggest question. Dont put time on things you dont even know if your donors want it.
• #23: So this was a very brief session, but main takeaway here is: be practical, don't put unnecessary requirements and steps. That is Innovate by building simple products, before anything just make sure there is even people out there who want it, that is, is there market fit? DO NOT OVERCOMPLICATE STUFF - Think simple, can you prototype before actually building something with code? - Allow yourself to act fast, do not get stuck in burocracy
• #24: So we are going to do another 2 min break, and this time I am going to ask you, can you think of 3 concepts you would like to test with your donors? Completely new or just changing existing ones, there is no rule, it is completely up to you, go wild. IGNORE CULTURAL ISSUES THAT COULD BE TROUBLESOME.
• #25: So last part of the presentation is: what are the impacts on the organizational structure and culture? The Organization needs to be open to learning and always evolving. What this means is: It will be hard to test things if processes are long. You need to be open to let people make important decisions and own their products. ‘Testing’, ‘prototyping’, ‘piloting’, need to be a category of their own, with shortcuts. Also accept that it is ok to fail. if you knew all the answers there would be no reason for you to test anything, and you would probably fundraise a lot more money than you do today. RIGHT? Every time your donors behave unexpectedly, it means you do not really understand them. Your results show you how they actually think and you get to learn more about them, and that is good, you can then create things that they would like more.
• #26: Second, bring product people to your team, or at least do stronger partnerships with your agency. Product Managers, designers and programmers are not something most non-profits have in their teams but if you want to be really digital these are the people you would like to have closer. You can start with a product manager, like UNICEF did. I would be worried about how digital you can go if you do not have product people and you do not work very strategically with your agency, that is if you don’t actually share and discuss analytics with them. Many people who work with online marketing do not really know much about programming and UX design. On the other side of the table, production companies focus on doing what is asked of them, and doing in a way that looks pretty, and of course they do it like that - they rarely have access to clients analytics, they rarely are evaluated on analytics and they rarely discuss analytics with their clients. If you want things to get better, you need to have a more data and donor behavior strategic way of working together and not just ordering things from them. UNICEF has only me inhouse. Designers and programmers sit in an agency, but it has been the same agency with the same professionals working with unicef for over 10 years. That is, they are super engaged. They know everything, the people who created the whole application are still there. I would still prefer them to actually sit with us, because I believe this would allow more people in our organization to get a more digital by osmosis, but it has been working quite well. We have been talking a lot about the product manager, the programmers and the designers but another important person is the data analyst. Data-driven decisions require clean data and data infrastructure. It is quite normal to not have the right setup on google analytics, to have dirty data, data from different places not communicating to each other, low know-how of statistics significance. All of these things have to be watched out for.
• #27: Last thing about your organization: it needs flat structures and with autonomous teams. This is a big thing in product development culture. It is rather uncommon that product managers would be someone’s supervisor, product is a team culture. Even though the product manager answers for all development and results, it is a rather informal lead. And this comes a bit from the culture of many programmers, where there is seldom hierarchy. Everybody gets to speak and contribute. It is a bit of the old hacker, anarchic culture, and you see a lot of such things as ‘open source’, ‘pair programming’, ‘reviewing each others’ code. A programming environment is a very inquisitive environment by definition and people will not do what you want them to do because you are telling them to do so. They are problem solvers, and they ask WHY all the time. The teams, informally led by the product manager, need to have a certain degree of autonomy.
• #28: So, key take aways from this last session: - Make sure you are open to simplify processes so that you can act fast - bring product people closer to your team, and dont forget about an analytics person, you cant outsource everything - provide teams with a good level of autonomy
• #29: I hope this presentation has helped you to think differently about data and what it means to be data and donor-driven as well as how to work with innovation. To conclude I would like to leave you with a list of questions that I hope make you reflect a bit more about how to improve your work processes.